Azimutt sur Google Cloud Run

Azimutt est un explorateur de schémas de bases de données de nouvelle génération et un outil d'ERD (diagramme entité-relation) open source pour les bases de données réelles, construit avec Elixir/Phoenix. Il permet aux équipes d'explorer, de documenter et de concevoir de grands schémas (des milliers de tables), de rechercher parmi les colonnes et les relations, et de partager des diagrammes. Ce module déploie Azimutt sur Cloud Run v2 en s'appuyant sur le socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud qu'utilise Azimutt et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toutes les applications Cloud Run — identité du service, ingress et équilibrage de charge, mise à l'échelle et concurrence, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_CloudRun plutôt que de les répéter ici.

1. Vue d'ensemble

Azimutt s'exécute comme un unique conteneur Elixir/Phoenix sur Cloud Run v2, à l'écoute sur le port 4000. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Conteneur Phoenix, 2 vCPU / 4 GiB par défaut, autoscaling serverless ; mise à l'échelle jusqu'à zéro activée
Base de données	Cloud SQL for PostgreSQL 15	Obligatoire — Azimutt ne prend pas en charge MySQL ni d'autres moteurs
Stockage d'objets	Cloud Storage	Un bucket est provisionné ; les téléversements vont par défaut sur le disque local éphémère (`FILE_STORAGE_ADAPTER = local`)
Secrets	Secret Manager	`SECRET_KEY_BASE` de Phoenix généré automatiquement ; mot de passe de la base de données
Build d'image	Cloud Build + Artifact Registry	Enveloppe légère FROM `ghcr.io/azimuttapp/azimutt`, mise en miroir dans Artifact Registry
Ingress	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut ; équilibreur de charge HTTPS externe et domaine personnalisé en option

Valeurs par défaut judicieuses à connaître d'emblée :

PostgreSQL 15 est obligatoire. Le moteur de base de données est fixé par la couche applicative partagée ; choisir tout autre moteur empêche le démarrage. Toutes les données de projet d'Azimutt (schémas, diagrammes, dispositions, utilisateurs) résident dans Postgres.
Azimutt se connecte à Postgres en TCP sur IP privée avec SSL, et non via le socket. Ecto/postgrex ne sait pas analyser le DSN de socket Unix de Cloud SQL ; le point d'entrée cloud construit donc DATABASE_URL sur DB_IP et définit DATABASE_ENABLE_SSL=true. Le socket Cloud SQL reste monté (enable_cloudsql_volume = true) uniquement pour que le job db-init puisse créer le rôle et la base de données sans SSL.
SECRET_KEY_BASE est généré automatiquement et stocké dans Secret Manager. Le renouveler après le premier démarrage déconnecte toutes les sessions actives ; ne le renouvelez que pendant une fenêtre de maintenance.
La mise à l'échelle jusqu'à zéro est activée par défaut (min_instance_count = 0, cpu_always_allocated = false). Azimutt est une application de type requête/réponse et un démarrage à froid se reconnecte proprement à Postgres. Les démarrages à froid ajoutent quelques secondes de latence après une période d'inactivité ; définissez min_instance_count = 1 pour les éviter.
Les migrations s'exécutent automatiquement à chaque démarrage. La commande du conteneur est /app/bin/migrate && /app/bin/server ; une montée de version applique donc ses modifications de schéma au démarrage — prévoyez du temps supplémentaire au premier démarrage.
application_version = "latest" correspond au tag main d'Azimutt. Azimutt ne publie aucun tag :latest ; épinglez une version précise en production.
L'inscription est ouverte par défaut. Azimutt permet à toute personne disposant de l'URL de créer un compte. Restreignez l'accès après avoir créé votre premier compte (domaine personnalisé + IAP, ou paramètres d'authentification propres à Azimutt via environment_variables).

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que PROJECT et REGION sont définis. Les noms des services et des ressources figurent dans les sorties du déploiement.

A. Cloud Run — le service Azimutt

Azimutt s'exécute comme un service Cloud Run v2 qui s'adapte automatiquement à la charge des requêtes entre le nombre minimal et maximal d'instances. Chaque déploiement crée une révision immuable ; le trafic peut être réparti entre les révisions pour des déploiements progressifs sûrs.

Console : Cloud Run → sélectionnez le service pour voir les révisions, le trafic, les journaux et les métriques.

CLI :

gcloud run services list --project "$PROJECT" --region "$REGION"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"
# Confirm the composed DB wiring the entrypoint logged at boot:
gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" \
  --limit 50 | grep cloud-entrypoint

Consultez App_CloudRun pour la mise à l'échelle, la concurrence, l'environnement d'exécution et la répartition du trafic.

B. Cloud SQL for PostgreSQL 15

Azimutt stocke toutes les données applicatives (schémas, diagrammes, dispositions, utilisateurs, sources) dans une instance gérée Cloud SQL for PostgreSQL 15. Sur Cloud Run, le service se connecte via l'IP privée de l'instance avec SSL (DATABASE_ENABLE_SSL=true) — Ecto ne sait pas analyser le DSN de socket. Lors du premier déploiement, un job d'initialisation crée la base de données applicative et le rôle ; Azimutt exécute ensuite ses propres migrations Ecto au démarrage.

Console : SQL → sélectionnez l'instance pour les connexions, sauvegardes, flags et métriques.

CLI :

gcloud sql instances list --project "$PROJECT"
gcloud sql instances describe <instance-name> --project "$PROJECT"
gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

Le nom de l'instance, la base de données, l'utilisateur et le secret du mot de passe figurent dans les sorties. Consultez App_CloudRun pour le modèle de connexion, les sauvegardes et la rotation des mots de passe.

C. Cloud Storage

Un bucket Cloud Storage est provisionné pour Azimutt. Avec la valeur par défaut FILE_STORAGE_ADAPTER = "local", Azimutt écrit les fichiers téléversés sur le disque local éphémère du conteneur plutôt que dans ce bucket ; le bucket existe pour les opérateurs qui basculent Azimutt vers un adaptateur de fichiers compatible S3. Les données de projet elles-mêmes résident dans Postgres.

Console : Cloud Storage → Buckets.

CLI :

gcloud storage buckets list --project "$PROJECT"
gcloud storage ls gs://<bucket-name>/          # bucket name is in the Outputs

Consultez App_CloudRun pour les options GCS Fuse et CMEK.

D. Secret Manager

Le SECRET_KEY_BASE de Phoenix est généré automatiquement et stocké dans Secret Manager (il sert à signer et chiffrer les cookies de session). Le mot de passe de la base de données est géré séparément par le socle.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~secret-key-base"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Consultez App_CloudRun pour les détails d'injection et de rotation.

E. Cloud Build et Artifact Registry

L'image d'Azimutt est une enveloppe légère construite FROM ghcr.io/azimuttapp/azimutt ; Cloud Build produit l'image enveloppée, qui est mise en miroir dans Artifact Registry (enable_image_mirroring = true). Le tag de base provient de l'argument de build AZIMUTT_VERSION (latest étant mappé sur main).

Console : Cloud Build → History ; Artifact Registry → Repositories.

CLI :

gcloud builds list --project "$PROJECT" --limit 5
gcloud artifacts docker images list <region>-docker.pkg.dev/$PROJECT/<repo> --include-tags

F. Réseau et entrée

Le service est joignable par défaut via son URL run.app. Un équilibreur de charge HTTPS externe avec un domaine personnalisé, Cloud CDN et Cloud Armor peut être ajouté ; les paramètres d'ingress et l'egress VPC contrôlent la connectivité. L'egress VPC est nécessaire pour qu'Azimutt puisse atteindre l'IP privée de Cloud SQL.

Console : Cloud Run (URL du service) ; Network services → Load balancing.

CLI :

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

Consultez App_CloudRun.

G. Cloud Logging et Monitoring

Les journaux du conteneur arrivent dans Cloud Logging ; les métriques de Cloud Run et de Cloud SQL arrivent dans Cloud Monitoring, avec des tests de disponibilité et des règles d'alerte facultatifs. Les lignes cloud-entrypoint indiquent le chemin DATABASE_URL résolu, PHX_HOST et PORT.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Comportement de l'application Azimutt

Configuration de la base de données au premier déploiement. Un job d'initialisation exécute db-init.sh avec postgres:15-alpine. Il crée de manière idempotente le rôle applicatif (LOGIN CREATEDB) et la base de données, accorde ALL sur la base de données et le schéma public, et modifie (ALTER) le propriétaire du schéma — Azimutt a besoin de droits DDL complets car il exécute ses propres migrations. Le job peut être réexécuté sans risque.
Les migrations s'exécutent au démarrage. La commande du conteneur est /app/bin/migrate && /app/bin/server ; Ecto applique donc les migrations en attente à chaque démarrage avant que le point de terminaison Phoenix ne se lie au port. Mettre à niveau application_version applique automatiquement les modifications de schéma — aucune étape de migration distincte.
Le câblage de la base de données à l'exécution est composé par le point d'entrée. DATABASE_URL est construite à partir des variables DB_* injectées, le mot de passe est encodé pour URL et, sur Cloud Run, la connexion utilise l'IP privée (DB_IP) avec DATABASE_ENABLE_SSL=true. PHX_HOST est dérivé de l'URL du service injectée (sans le schéma).
SECRET_KEY_BASE est stable et, en pratique, immuable. Il est généré une seule fois et écrit dans Secret Manager. Le renouveler invalide tous les cookies de session actifs — tous les utilisateurs sont déconnectés. Ne le renouvelez que pendant une fenêtre de maintenance.
Chemin de santé. Les sondes de démarrage et de disponibilité (readiness) ciblent la racine Phoenix / — le premier point de terminaison qui renvoie 200 une fois que le serveur a démarré et s'est connecté à Postgres. Prévoyez environ 1–2 minutes au premier démarrage pour les migrations (la sonde de démarrage fournit un délai initial de 60 secondes plus une fenêtre de nouvelles tentatives).
Configuration initiale. Ouvrez l'URL du service et créez le premier compte Azimutt via la page d'inscription. L'inscription est ouverte par défaut — restreignez l'accès ensuite.

Inspecter l'exécution du job d'initialisation :

gcloud run jobs list --project "$PROJECT" --region "$REGION"
gcloud run jobs executions list --job <job-name> --project "$PROJECT" --region "$REGION"

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à Azimutt ou notables pour lui sont listés ; toutes les autres entrées sont héritées d' App_CloudRun avec leur comportement standard.