Coder sur Google Cloud Run

Coder est une plateforme open source auto-hébergée qui provisionne des environnements de développement distants (espaces de travail) définis sous forme de code avec Terraform — les développeurs disposent d'environnements cohérents et prêts à l'emploi, tandis que les équipes plateforme conservent le code source et les dépendances sur leur propre infrastructure. Ce module déploie le plan de contrôle Coder 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 utilisés par Coder 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, entrée 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

Coder s'exécute sous forme d'un binaire Go unique (coder server) dans un conteneur sur Cloud Run v2. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Service de plan de contrôle Go, 2 vCPU / 4 GiB par défaut, CPU toujours allouée
Base de données	Cloud SQL for PostgreSQL 15	Obligatoire — Coder exige PostgreSQL 13+ ; MySQL est rejeté au moment du plan
Stockage d'objets	Cloud Storage	Un bucket `storage` provisionné automatiquement (à la disposition de l'opérateur)
Build d'image	Cloud Build + Artifact Registry	Fine surcouche personnalisée construite FROM `ghcr.io/coder/coder`
Secrets	Secret Manager	Mot de passe de la base de données géré automatiquement — Coder n'a besoin d'aucun secret applicatif propre
Entrée	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut ; équilibreur de charge HTTPS externe + domaine personnalisé en option

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

PostgreSQL 15 est obligatoire. Coder exige PostgreSQL 13+ ; une validation au moment du plan rejette les moteurs MySQL.
Le plan de contrôle est sans état. Tout l'état — modèles, espaces de travail, utilisateurs, sessions, file d'attente des builds et clés de signature auto-générées par Coder — réside dans PostgreSQL. Pas de NFS, pas de Redis, pas de secret applicatif géré par Common.
cpu_always_allocated = true et min_instance_count = 1. coder server exécute dans son processus des démons de provisionnement intégrés qui interrogent en continu la base de données pour détecter les builds d'espaces de travail en attente et terminent les connexions des agents d'espace de travail — ce travail en arrière-plan se bloque avec la limitation de CPU basée sur les requêtes ou la mise à l'échelle à zéro.
L'URL de connexion est assemblée à l'exécution. Le point d'entrée personnalisé construit CODER_PG_CONNECTION_URL (une URL postgres:// avec un mot de passe encodé pour URL) à partir des variables DB_* injectées par le socle, en privilégiant le chemin TCP par IP privée avec sslmode=require sur Cloud Run.
CODER_ACCESS_URL est défini automatiquement à partir de l'URL du service Cloud Run injectée, de sorte que les URL de connexion des espaces de travail et des agents ainsi que les URI de redirection OAuth sont correctes d'emblée.
Un job db-init s'exécute à chaque apply pour créer de manière idempotente la base de données et le rôle Coder ; Coder exécute ses propres migrations de schéma au démarrage du serveur.
Les sondes de santé ciblent /healthz (non authentifié) avec un délai initial de 60 secondes pour la migration de schéma du premier démarrage.
Le mot de passe de la base de données est généré automatiquement et stocké dans Secret Manager.
application_version = "latest" correspond à un tag épinglé (v2.24.1) via l'ARG de build propre à l'application CODER_VERSION — les tags GHCR de Coder sont préfixés selon semver.

Ce module déploie le plan de contrôle de Coder. Provisionner de véritables espaces de travail nécessite en outre un provisionneur configuré et une cible de calcul (par exemple un cluster Kubernetes ou un modèle de VM cloud), mis en place après le déploiement via le système de modèles de Coder.

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 Coder

Coder s'exécute comme un service Cloud Run v2 avec une CPU toujours allouée et une instance minimale maintenue active, de sorte que les démons de provisionnement intégrés continuent d'interroger les builds d'espaces de travail même en l'absence de requêtes entrantes. 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 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"

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

Coder stocke tout — utilisateurs, organisations, modèles, état des espaces de travail, file d'attente des jobs de provisionnement et ses clés de signature — dans une instance gérée Cloud SQL for PostgreSQL 15. Le service s'y connecte par IP privée avec sslmode=require (le DSN sous forme d'URL de Coder ne peut pas contenir le chemin du socket Unix) ; le Job db-init crée la base de données et le rôle de l'application au premier déploiement.

Console : SQL → sélectionnez l'instance pour les connexions, les sauvegardes, les flags et les 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> --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 du mot de passe.

C. Cloud Storage

Un bucket Cloud Storage dédié (suffixe storage) est provisionné automatiquement. Coder n'en a pas besoin pour le fonctionnement du plan de contrôle — celui-ci ne conserve aucun fichier sur disque — mais il reste disponible pour les ressources des modèles ou l'usage de l'opérateur.

Console : Cloud Storage → Buckets.

CLI :

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

D. Cloud Build et Artifact Registry

container_image_source = "custom" déclenche un Cloud Build qui encapsule ghcr.io/coder/coder:<version> avec le point d'entrée cloud et pousse le résultat vers Artifact Registry (l'image de base est d'abord mise en miroir, enable_image_mirroring = true).

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> --limit 5

E. Secret Manager

Le mot de passe de la base de données est le seul secret du déploiement — stocké dans Secret Manager et injecté à l'exécution sous la forme DB_PASSWORD, puis encodé pour URL dans l'URL de connexion par le point d'entrée. Coder génère lui-même ses clés de signature et les conserve dans PostgreSQL ; il n'existe donc aucun secret de session ou applicatif à gérer.

Console : Security → Secret Manager.

CLI :

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

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

F. Réseau et entrée

Le service est accessible par défaut à son URL run.app ; le point d'entrée exporte cette URL sous la forme CODER_ACCESS_URL, à partir de laquelle Coder construit les URL de connexion des espaces de travail et des agents. Un équilibreur de charge HTTPS externe avec un domaine personnalisé, Cloud CDN et Cloud Armor peuvent être ajoutés ; les paramètres d'entrée et la sortie VPC contrôlent la connectivité.

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 (structurés, vers STDOUT) sont envoyés à Cloud Logging ; les métriques de Cloud Run et de Cloud SQL sont envoyées à Cloud Monitoring, avec des tests de disponibilité et des règles d'alerte en option.

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 Coder

Configuration de la base de données au premier déploiement. Un Job db-init (postgres:15-alpine) se connecte en tant que super-utilisateur postgres et, de manière idempotente, crée le rôle Coder (LOGIN CREATEDB), crée la base de données, accorde tous les privilèges et réattribue la propriété du schéma public au rôle de l'application (les migrations de Coder y créent tous les objets). Le job s'exécute à chaque apply et peut être relancé sans risque.
Les migrations s'exécutent au démarrage. Coder applique ses propres migrations de schéma à chaque démarrage de coder server — les mises à niveau de version ne nécessitent aucune étape de migration manuelle. Le premier démarrage sur une base de données vierge prend plus de temps ; la sonde de démarrage accorde jusqu'à ~8 minutes avant d'abandonner.
Assemblage du DSN à l'exécution. Le point d'entrée cloud construit CODER_PG_CONNECTION_URL à partir de DB_HOST/DB_IP/DB_USER/DB_PASSWORD/DB_NAME : sur Cloud Run, il privilégie l'IP privée avec sslmode=require (le chemin du socket Cloud SQL ne peut pas figurer dans la partie autorité d'une URL) ; le mot de passe est encodé en pourcentage afin que les caractères spéciaux ne cassent jamais l'URL. Un CODER_PG_CONNECTION_URL fourni explicitement a la priorité.
URL d'accès. CODER_ACCESS_URL est défini à partir de CLOUDRUN_SERVICE_URL injecté. Coder en dérive les URL de connexion des espaces de travail et des agents ainsi que les URI de redirection OAuth — si vous placez un domaine personnalisé devant le service, définissez CODER_ACCESS_URL sur ce domaine dans environment_variables.
Aucun secret applicatif. Coder génère ses clés de signature et les conserve dans PostgreSQL. La recréation des conteneurs, la mise à l'échelle et les redéploiements sont sans risque ; rien ne se désynchronise.
Configuration initiale. La première visite de l'URL du service vous invite à créer le compte administrateur initial (propriétaire) — faites-le rapidement, car le point de terminaison reste accessible publiquement jusque-là (ingress_settings = "all" par défaut).
Le provisionnement des espaces de travail est une étape post-déploiement. Le plan de contrôle seul n'exécute aucun espace de travail. Créez un modèle (Terraform) pointant vers une cible de calcul — par exemple un cluster GKE ou des VM GCE — et assurez-vous que le provisionneur dispose d'identifiants pour celle-ci.
Chemin de santé. Les sondes de démarrage, de vivacité et de disponibilité (readiness) ciblent /healthz, que Coder sert sans authentification avec un HTTP 200 dès que le serveur est opérationnel.

Vérification :

SERVICE_URL=$(gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)')
curl -s -o /dev/null -w "%{http_code}\n" "$SERVICE_URL/healthz"     # expect 200
curl -s "$SERVICE_URL/api/v2/buildinfo"                             # Coder version info

4. Variables de configuration

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