Azimutt sur GKE Autopilot

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 GKE Autopilot en s'appuyant sur le socle App_GKE, qui provisionne et gère l'infrastructure Google Cloud et Kubernetes 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 GKE — Workload Identity, ingress, autoscaling, 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_GKE plutôt que de les répéter ici.

1. Vue d'ensemble

Azimutt s'exécute comme une unique charge de travail web Elixir/Phoenix à l'écoute sur le port 4000. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	GKE Autopilot	Pods Phoenix, autoscaling horizontal ; facturation du CPU et de la mémoire demandés
Base de données	Cloud SQL for PostgreSQL 15	Obligatoire — Azimutt ne prend pas en charge MySQL ni d'autres moteurs
Stockage de fichiers	Cloud Filestore (NFS)	`enable_nfs = true` par défaut, mais Azimutt écrit toujours les téléversements dans son propre répertoire de travail éphémère plutôt que sur ce montage (voir ci-dessous)
Stockage d'objets	Cloud Storage	Un bucket est provisionné (disponible pour un adaptateur de fichiers compatible S3)
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	Cloud Load Balancing	LoadBalancer externe, domaine personnalisé et certificat géré 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 résident dans Postgres.
Azimutt se connecte à Postgres via l'interface loopback de l'Auth Proxy (sans SSL). Ecto ne sait pas analyser le DSN de socket Cloud SQL ; sur GKE, le point d'entrée construit donc DATABASE_URL sur 127.0.0.1 (le sidecar Cloud SQL Auth Proxy, qui termine le TLS) avec DATABASE_ENABLE_SSL=false. enable_cloudsql_volume = true est obligatoire.
container_port et les sondes doivent valoir 4000. Sur GKE, la plateforme n'injecte pas automatiquement PORT ; le point d'entrée définit donc PORT=4000 par défaut ; le port du Service et les sondes doivent correspondre, sinon le pod ne devient jamais Ready alors même que l'application est saine.
NFS est activé par défaut (enable_nfs = true), mais il n'est pas actuellement relié au chemin de stockage d'Azimutt — FILE_STORAGE_ADAPTER reste à local ; les téléversements arrivent donc toujours sur le disque éphémère du pod plutôt que sur le montage NFS. Les données de projet elles-mêmes (schémas, diagrammes, dispositions, utilisateurs) résident dans Postgres et ne sont pas affectées.
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.
Un minimum de 1 réplica est maintenu (min_instance_count = 1) — GKE ne prend pas en charge la mise à l'échelle jusqu'à zéro, ce qui garde Azimutt toujours joignable.
Les migrations s'exécutent automatiquement à chaque démarrage (/app/bin/migrate && /app/bin/server) ; prévoyez du temps supplémentaire au premier démarrage.
application_version = "latest" correspond au tag main d'Azimutt. Épinglez une version précise en production.
L'inscription est ouverte par défaut. Restreignez l'accès après avoir créé votre premier compte.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que vous avez exécuté gcloud container clusters get-credentials <cluster> --region <region> --project <project> et que PROJECT, REGION et NAMESPACE sont définis. L'espace de noms et les autres identifiants figurent dans les sorties du déploiement.

A. GKE Autopilot — la charge de travail Azimutt

Les pods Azimutt sont planifiés sur Autopilot, qui facture le CPU et la mémoire réellement demandés par les pods. L'autoscaling horizontal des pods dimensionne le déploiement entre le nombre minimal et maximal de réplicas.

Console : Kubernetes Engine → Workloads → sélectionnez la charge de travail Azimutt pour voir les pods, les révisions et les événements. Kubernetes Engine → Services & Ingress affiche l'IP externe.

CLI :

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
kubectl logs -n "$NAMESPACE" deploy/<service-name> | grep cloud-entrypoint  # resolved DB wiring

Consultez App_GKE pour la gestion d'Autopilot, de la mise à l'échelle et du type de charge de travail (Deployment ou StatefulSet).

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. Les pods l'atteignent via le sidecar Cloud SQL Auth Proxy sur 127.0.0.1 (TLS terminé par le proxy, d'où DATABASE_ENABLE_SSL=false). 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 tous dans les sorties. Pour le modèle de connexion, les sauvegardes et la rotation des mots de passe, consultez App_GKE.

C. Cloud Filestore (NFS) et Cloud Storage

NFS est activé par défaut (enable_nfs = true) et monté sur nfs_mount_path, mais il n'est pas actuellement relié au chemin de stockage d'Azimutt — avec la valeur par défaut FILE_STORAGE_ADAPTER = local, Azimutt écrit toujours les téléversements dans son propre répertoire de travail éphémère plutôt que sur ce montage. Un bucket Cloud Storage est également provisionné (disponible si vous basculez Azimutt vers un adaptateur de fichiers compatible S3). Les données de projet elles-mêmes (schémas, diagrammes, dispositions, utilisateurs) résident dans Postgres et ne sont affectées dans aucun des deux cas.

Console : Filestore → Instances ; Cloud Storage → Buckets.

CLI :

gcloud filestore instances list --project "$PROJECT"
gcloud storage buckets list --project "$PROJECT"
kubectl get pvc -n "$NAMESPACE"

Consultez App_GKE pour le provisionnement NFS, les options CMEK et les montages GCS Fuse.

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_GKE pour l'intégration Secret Store CSI et la 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). Comme il s'agit d'une image reconstruite/mise en miroir, App_GKE définit imagePullPolicy = Always afin que les nœuds ne servent jamais une couche en cache obsolète.

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

Par défaut, la charge de travail est exposée via une IP Cloud Load Balancing externe (service_type = LoadBalancer). Un domaine personnalisé avec un certificat géré par Google peut être activé, et une IP statique peut être réservée afin que l'adresse survive aux redéploiements. session_affinity = ClientIP maintient un client sur un même pod.

Console : Network services → Load balancing ; VPC network → IP addresses.

CLI :

kubectl get ingress,svc -n "$NAMESPACE"
gcloud compute addresses list --project "$PROJECT"

Consultez App_GKE pour les domaines personnalisés, Cloud CDN et les détails de l'IP statique.

G. Cloud Logging et Monitoring

Le stdout/stderr des pods arrive dans Cloud Logging ; les métriques de GKE et de Cloud SQL arrivent dans Cloud Monitoring. Des tests de disponibilité et des règles d'alerte facultatifs sont disponibles. Les lignes cloud-entrypoint indiquent le chemin DATABASE_URL résolu, PHX_HOST et PORT.

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

CLI :

gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
  --project "$PROJECT" --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 signale ensuite au sidecar Auth Proxy de s'arrêter (/quitquitquit) afin que le pod du job se termine. Réexécutable 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.
Le câblage de la base de données à l'exécution est composé par le point d'entrée. Sur GKE, DATABASE_URL est construite sur l'interface loopback de l'Auth Proxy (127.0.0.1) avec DATABASE_ENABLE_SSL=false, et PORT vaut 4000 par défaut (GKE ne l'injecte pas automatiquement). PHX_HOST est dérivé de l'URL du service injectée.
SECRET_KEY_BASE est stable et, en pratique, immuable. 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 vivacité ciblent la racine Phoenix / avec un délai initial de 60 secondes. Les sondes et container_port doivent tous deux valoir 4000, sinon le pod ne devient jamais Ready.
Configuration initiale. Atteignez le service via son IP LoadBalancer externe (ou votre domaine personnalisé) 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 :

kubectl get jobs -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" job/<job-name>

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_GKE avec leur comportement et leurs valeurs par défaut standard.