Ressources gérées et DNS interne avec versions

Les services gérés Postgres, MySQL, MongoDB, Redis et RabbitMQ reçoivent un nom d’hôte privé stable. Votre application peut l’utiliser pour la version actuelle promue ou ajouter un libellé de version pour atteindre un déploiement précis sain.

Définir les ressources avec l'application

Le resources conserve la configuration du service et sa liaison à l’application dans un même fichier adios.yaml :

name: aor-api
region: de

resources:
  - name: db
    template: postgres:16
    database: aor
    username: aor_api
    password: secret://POSTGRES_PASSWORD
  - name: redis
    template: redis:7
    database: "0"
    password: secret://REDIS_PASSWORD
  - name: rabbitmq
    template: rabbitmq:3
    database: aor
    username: aor_api
    password: secret://RABBITMQ_PASSWORD

Adios attribue un App ID unique à chaque ressource gérée. Dans l’exemple ci-dessus, la ressource Postgres aura normalement un ID similaire à aor-api-db, même si son nom court de ressource est db. Le DNS interne utilise l’App ID unique, ce qui permet à une autre application d’avoir aussi une ressource nommée db sans partager sa cible.

ID de l'équipe et ID VPC

team_id identifie l'équipe qui possède l'application, les ressources, les secrets et les dossiers de déploiement. vpc_id identifie le réseau privé dans lequel les workloads reçoivent leurs adresses et résolvent les services internes.

Ce sont des champs séparés, mais vpc_id utilise par défaut team_id lorsque vous n’en définissez pas :

name: aor-api
team_id: team-a
# vpc_id defaults to team-a

Cette valeur par défaut produit un nom de ressource actuel tel que :

aor-api-db.de.team-a.svc.internal

Si l'application utilise explicitement vpc_id: production, le nom correspondant est aor-api-db.de.production.svc.internal. Les libellés DNS sont normalisés en minuscules : un ID d’équipe ou de VPC en majuscules ou à casse mixte apparaît donc en minuscules dans un nom d’hôte généré.

Utiliser les paramètres de connexion injectés

adios up ajoute les paramètres de connexion natifs du moteur à l’application. Pour une ressource Postgres nommée db, l’environnement d’exécution reçoit des valeurs comme celles-ci :

DB_HOST=aor-api-db.de.<vpc-id>.svc.internal
DB_PORT=5432
DB_DATABASE=aor
DB_USER=aor_api
DB_PASSWORD=<secret reference>
DB_DATABASE_URL=secret://ADIOS_AOR_API_DB_DB_DATABASE_URL
DATABASE_URL=secret://ADIOS_AOR_API_DB_DATABASE_URL

Les références aux secrets sont résolues pour l’exécution. Le mot de passe et l’URL dérivée ne sont ni inscrits dans la gestion de versions ni renvoyés au navigateur.

Chaque moteur reçoit aussi une URL globale conventionnelle lorsque l’application n’a pas fourni sa propre valeur :

Modèle	URL globale	Port natif
Postgres / pgvector	`DATABASE_URL`	`5432`
MySQL	`DATABASE_URL`	`3306`
MongoDB	`MONGODB_URL`	`27017`
Redis	`REDIS_URL`	`6379`
RabbitMQ	`AMQP_URL`	`5672`

Les variables préfixées par les ressources demeurent disponibles lorsqu'une application a plus d'un service du même moteur. Une ressource nommée sessions, par exemple, obtient SESSIONS_HOST, SESSIONS_PORT, et SESSIONS_REDIS_URL.

Les noms courts tels que `DB_HOST=db`

Les environnements d’exécution Adios reçoivent des domaines de recherche DNS pour leur région et leur VPC. Un résolveur système standard peut donc développer le nom court db à des noms tels que db.de.team-a.svc.internal et db.team-a.svc.internal.

Ce nom court est un alias de service lisible, pas l’App ID unique de la ressource gérée. Il peut être ambigu si deux applications du même VPC possèdent toutes deux une ressource nommée db, et les clients DNS personnalisés ne respectent pas toujours les domaines de recherche système. Ne l’utilisez pas comme point de terminaison de la base de données gérée.

Quand une ressource gérée est nommée db, Adios remplace normalement une valeur simple telle que DB_HOST=db par le nom d’hôte App-ID généré lors du déploiement. Utilisez les paramètres injectés DB_HOST ou DATABASE_URL. Si vous avez besoin d'écrire explicitement l'hôte, utilisez aor-api-db.de.team-a.svc.internal pour la version actuelle ou aor-api-db.v1.de.team-a.svc.internal pour une version exacte. Une expression secret:// reste sous votre contrôle et n’est pas remplacée.

Noms de version actuelle et de version exacte

Les formes qualifiées par région sont les plus claires et celles qu’utilisent les connexions aux ressources gérées générées :

Cible	Nom DNS interne
Version actuelle promue	`<app-id>.<region>.<vpc-id>.svc.internal`
Version exacte	`<app-id>.<version>.<region>.<vpc-id>.svc.internal`

Pour une ressource ayant l’App ID aor-api-db dans la région de et VPC team-a:

# Promoted current release
aor-api-db.de.team-a.svc.internal

# Exact healthy versions
aor-api-db.v1.de.team-a.svc.internal
aor-api-db.v2.de.team-a.svc.internal

current désigne la version enregistrée dans la mise en ligne promue, pas la chaîne de version la plus élevée. Si v2 a été déployée sans être promue, le nom sans version continue de pointer vers v1. Après v2 est promue, les nouvelles connexions utilisant le nom sans version atteignent v2.

Le nom DNS se résout vers une VIP de service stable. Le proxy interne choisit un réplica sain pour l’App ID, la version, la région, le VPC, le port natif et le protocole sélectionnés. Une connexion établie à une base de données ou une file d’attente n’est pas transférée en place ; les clients doivent se reconnecter pour utiliser une cible nouvellement promue.

Fixer une version de ressource dans le manifeste

Définissez version lorsqu’une application doit se lier à un déploiement précis d’une ressource gérée :

resources:
  - name: db
    template: postgres:16
    version: v1
    database: aor
    username: aor_api
    password: secret://POSTGRES_PASSWORD

L'hôte généré comprend .v1. au lieu de suivre le nom courant sans version. Lors d’un déploiement qui promeut les ressources gérées, la version sélectionnée de la ressource peut aussi devenir actuelle. Considérez cela comme un choix explicite de version ou un retour arrière, et non comme une option d’inspection en lecture seule.

Pour un workload de diagnostic qui compare les versions sans modifier le pointeur actuel, gardez ses identifiants habituels dans Secret Manager et connectez-vous directement au nom d’hôte de version explicite.

Ce qu'une version de ressource représente

Un nom DNS avec version sélectionne un déploiement d’exécution. Ce n’est pas un instantané de base de données et il ne reconstitue pas les données historiques. Le nom de version exacte ne renvoie une cible que si cette version possède un réplica sain en cours d’exécution.

Les services persistants sont aussi soumis à la propriété des volumes et à une protection garantissant un seul processus d’écriture. Un ancien environnement d’exécution peut être arrêté ou ne pas pouvoir fonctionner à côté de celui qui écrit actuellement. Utilisez les instantanés gérés et la procédure de restauration documentée pour obtenir des données historiques, plutôt que de supposer que v1 est une copie à un instant donné.

Limites des réseaux et de la sécurité

svc.internal sont accessibles aux workloads déployés sur le réseau VPC privé autorisé. Ce ne sont pas des points de terminaison publics de bases de données, et ils ne sont normalement pas résolus depuis l’ordinateur portable d’un développeur.
Le DNS tenant compte de la source empêche un workload de résoudre le nom de service interne d’un autre VPC.
Le nom d’hôte n’est pas un identifiant d’accès. Gardez les mots de passe et les URL de connexion complètes dans Secret Manager.
Un déploiement de développement Docker local peut utiliser host.docker.internal et un port publié au lieu de svc.internal.
Une ressource explicitement configurée pour un réseau externe ne reçoit pas de nom d'hôte de service interne.

Dépannage

Le nom actuel n'a pas d'enregistrement. Confirmez que la ressource possède une version actuelle promue et au moins un réplica sain dans la région demandée. Un déploiement peut exister sans être la version actuelle.

Une version exacte n'a pas d'enregistrement. Vérifiez le libellé complet de la version et assurez-vous qu’elle fonctionne toujours et qu’elle est saine. Les métadonnées conservées ne suffisent pas à créer une cible DNS.

Le nom est résolu, mais la connexion échoue. Utilisez le port natif du moteur, vérifiez la disponibilité de la cible et confirmez que l’application et la ressource sont dans le même VPC. Les pools de connexions existants peuvent devoir se reconnecter après une promotion.

L'application atteint la mauvaise version. Vérifiez la version promue plutôt que de comparer les chaînes de versions. Utilisez la forme de nom avec version explicite pour tester un déploiement précis.

Deux ressources sont toutes les deux nommées db. Utilisez les App ID générés des ressources. Le nom court sert aux variables du manifeste ; l’App ID est la clé DNS unique du service.

Consultez les guides des moteurs pour la configuration propre aux modèles : PostgreSQL, MySQL, MongoDB, Redis, et RabbitMQ.