Connect Databases, Caches and Queues to a Rapids Container

What's changed

• Open a Rapids container's new Connections tab, choose Connect service and pick a running database (PostgreSQL, MySQL or MariaDB), cache (Redis, Valkey or Dragonfly) or RabbitMQ queue from the same project, review the variables it will add, then choose Connect & deploy. A new revision is deployed with them, without rebuilding your image, and the tab shows your services as a map or a list.
• Connection URL only adds just the URL. Without it, a database gets DATABASE_URL plus DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD (the database's admin user); a cache gets REDIS_URL plus REDIS_HOST, REDIS_PORT, REDIS_USERNAME and REDIS_PASSWORD; a queue gets AMQP_URL plus AMQP_HOST, AMQP_PORT, AMQP_USERNAME, AMQP_PASSWORD and AMQP_VHOST. They point at the service's private address inside your project.
• An optional prefix such as ANALYTICS_ lets one application use several services of the same type. A variable you added by hand is replaced only if you confirm it, a variable that belongs to another connection is never overwritten, and passwords and URLs stay masked in the preview and in the tab.
• Choose Create new to provision the service from the same flow: you go through the normal create page, which shows the engine, plan, storage and price, return to the container, and the connection is filled in once both the service and the container image are ready; if that takes more than an hour, the connection shows an error and you disconnect and try again. A container deployed from Git or a ZIP file needs its first build to finish before an existing service can be connected.
• Applied means the variables are in a confirmed active revision; on a stopped container they are saved and take effect at the next start. Disconnect service keeps the service and its data and removes only the variables you have not changed. A rotated password is not copied into an existing connection: disconnect and reconnect to pick it up.
• If the service's firewall lists specific sources for its port, add the container under Sources, or its connections are refused.
• Through the API, a container response now carries environment_snapshot. Send it back with environment_variables when you update the environment of a container that has a connected service: a missing or stale snapshot is refused with HTTP 422. Requests that leave out environment_variables are unaffected, and connections themselves are made in the console only. Clients that do not send it yet, including danube CLI 1.8, cannot change the variables of such a container: use the console or the API directly.