Plane sur Google Cloud Run

Plane est une plateforme open source de gestion de projets — une alternative à Jira / Linear pour les tickets, les cycles, les modules et les feuilles de route. Ce module déploie Plane sur Cloud Run v2 au-dessus du socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud qu'utilise Plane 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 à toute application 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

La pile auto-hébergée amont de Plane comporte plusieurs services : web / space / admin (frontends), api (Django/gunicorn), worker + beat (Celery), live (collaboration en temps réel) et un job migrator, plus PostgreSQL, Redis, RabbitMQ et un stockage objet compatible S3. Ce module déploie l'image communautaire tout-en-un publiée par Plane (makeplane/plane-aio-community), qui regroupe tous les sous-services derrière un reverse proxy Caddy interne sur le port 80 via supervisord — un seul service Cloud Run expose donc toute l'application. Le déploiement assemble :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Conteneur tout-en-un (api + workers + frontends + migrator), 2 vCPU / 4 GiB par défaut
Courtier de messages	RabbitMQ en sidecar dans le pod	`rabbitmq:3.13-management-alpine` sur `127.0.0.1:5672` — obligatoire pour Celery
Base de données	Cloud SQL for PostgreSQL 15	PostgreSQL standard, aucune extension requise
Cache / backend de file de tâches	Redis	Activé par défaut ; hébergé sur la VM du serveur NFS si aucun hôte externe n'est indiqué
Fichiers partagés	Filestore / NFS autogéré	Nécessaire à la colocalisation de Redis (environnement d'exécution gen2)
Stockage objet	Cloud Storage	Un bucket `storage` dédié est provisionné — le câblage des téléversements S3 est un TODO documenté
Secrets	Secret Manager	`SECRET_KEY`, `LIVE_SERVER_SECRET_KEY` et le mot de passe de la base de données gérés automatiquement
Entrée	URL Cloud Run / Cloud Load Balancing	URL `run.app` par défaut, équilibreur de charge HTTPS externe et domaine personnalisé facultatifs

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

PostgreSQL 15 est le moteur imposé. Plane est une application Django ; database_type = "POSTGRES_15" et aucun autre moteur ne fonctionne.
RabbitMQ est obligatoire et s'exécute en sidecar dans le pod. Le start.sh de Plane se termine avec un code non nul si AMQP_URL est vide. AMQP (TCP 5672) est un protocole non HTTP que le réseau de service à service de Cloud Run ne peut pas acheminer ; le courtier partage donc le pod sur 127.0.0.1:5672. L'état du courtier est éphémère (la durabilité des files est un TODO documenté).
Build personnalisé. Un Dockerfile wrapper minimal ajoute un point d'entrée de la plateforme à l'image AIO ; ce point d'entrée compose les chaînes de connexion DATABASE_URL / REDIS_URL / AMQP_URL attendues par Plane à partir des valeurs distinctes DB_* / REDIS_* / RABBITMQ_* injectées par le socle.
application_version vaut stable par défaut. L'image amont n'a pas de tag latest — une entrée latest est automatiquement convertie en stable au moment du build.
Démarrage à froid par défaut. cpu_always_allocated = false et min_instance_count = 0 (facturation à la requête, mise à zéro). Les notifications, webhooks et exports Celery sont différés jusqu'à ce que la requête suivante réveille une instance — définissez cpu_always_allocated = true et min_instance_count = 1 pour un traitement en arrière-plan continu.
Deux secrets applicatifs sont générés automatiquement dans Secret Manager : le SECRET_KEY Django (50 caractères) et LIVE_SERVER_SECRET_KEY (40 caractères, authentification de la collaboration en temps réel).
Un job db-init s'exécute à chaque apply pour créer de façon idempotente la base de données et l'utilisateur Plane ; les migrations de schéma sont exécutées au démarrage par l'étape migrator propre à l'image AIO.
Les téléversements de fichiers sont un TODO. Plane a besoin d'un point de terminaison compatible S3 ; le bucket GCS storage existe, mais les clés HMAC d'interopérabilité S3 de GCS ne sont pas encore câblées. Les tickets, projets et cycles fonctionnent sans lui — les pièces jointes et les avatars, non.
Les sondes de santé ciblent /health via le proxy Caddy interne sur le port 80.

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 Plane (avec le sidecar RabbitMQ)

Plane s'exécute comme un service Cloud Run v2 unique. Le conteneur principal est l'image tout-en-un (supervisord exécute migrator → api / frontends / live + worker/beat Celery derrière Caddy sur :80) ; un second conteneur sidecar mq exécute RabbitMQ. Le démarrage du conteneur principal attend la sonde TCP 5672 du sidecar.

Console : Cloud Run → sélectionnez le service pour voir les révisions, le trafic, les journaux et les métriques. Le sidecar apparaît dans l'onglet Conteneurs de la révision.

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

Plane stocke les espaces de travail, projets, tickets, cycles et utilisateurs dans une instance gérée Cloud SQL for PostgreSQL 15. Au premier déploiement, un Job db-init crée la base de données et l'utilisateur de l'application ; l'étape migrator de l'image AIO applique ensuite les migrations Django à chaque démarrage du conteneur. Le point d'entrée de la plateforme se connecte via l'IP privée en TCP avec sslmode=require (le volume de socket Cloud SQL est monté, mais Django/psycopg de Plane utilise le DATABASE_URL composé).

Console : SQL → sélectionnez l'instance pour voir 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. Redis (backend Celery et cache)

Redis sert de cache à Plane et de stockage des résultats Celery. Lorsqu'aucun redis_host externe n'est configuré, la VM du serveur NFS héberge Redis et son IP est résolue à l'exécution (le point d'entrée substitue l'espace réservé $(NFS_SERVER_IP) avant de composer REDIS_URL).

Console : Memorystore → Redis (si vous utilisez une instance gérée) ; Compute Engine → Instances de VM (VM NFS/Redis).

CLI :

redis-cli -h <redis-host> ping
gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50 | grep "Composed REDIS_URL"

D. Cloud Storage

Un bucket storage dédié (gcs-<service-name>-storage) est provisionné pour les téléversements de fichiers de Plane. Le câblage des téléversements est un TODO : Plane exige un point de terminaison compatible S3, et bien que AWS_S3_ENDPOINT_URL pointe vers https://storage.googleapis.com, les clés HMAC d'interopérabilité S3 de GCS ne sont pas provisionnées — fournissez AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY via environment_variables (ou utilisez un bucket S3 externe) pour activer les pièces jointes.

Console : Cloud Storage → Buckets.

CLI :

gcloud storage buckets list --project "$PROJECT" --filter="name~plane"
gcloud storage ls gs://<storage-bucket>/

E. Secret Manager

Trois secrets sont gérés automatiquement : le SECRET_KEY Django, le LIVE_SERVER_SECRET_KEY (authentification de la collaboration en temps réel) et le mot de passe Cloud SQL. Tous sont injectés à l'exécution ; le texte en clair n'apparaît jamais dans la configuration.

Console : Security → Secret Manager.

CLI :

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

Consultez App_CloudRun pour le détail de l'injection et de la rotation.

F. Réseau et entrée

Le service est joignable par défaut à son URL run.app ; l'URL prévue est injectée en tant que WEB_URL / DOMAIN_NAME / CORS_ALLOWED_ORIGINS afin que les redirections OAuth, CORS et les liens des e-mails fonctionnent d'emblée. Un équilibreur de charge HTTPS externe avec domaine personnalisé, Cloud CDN et Cloud Armor peut être ajouté — dans ce cas, le domaine doit correspondre à ces variables d'URL.

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 (y compris la sortie supervisord de chaque sous-service intégré et du sidecar mq) sont envoyés vers Cloud Logging ; les métriques Cloud Run et Cloud SQL vers Cloud Monitoring, avec un test de disponibilité facultatif sur /health (désactivé par défaut) et des règles d'alerte facultatives.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Tests de disponibilité.

CLI :

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

3. Comportement de l'application Plane

Configuration de la base de données au premier déploiement. Un Job db-init (postgres:15-alpine) crée de façon idempotente la base de données et l'utilisateur Plane, accorde les privilèges (dont GRANT <user> TO postgres afin que la propriété puisse être définie) et arrête proprement son sidecar Cloud SQL Proxy. Il s'exécute à chaque apply et peut être relancé sans risque.
Les migrations s'exécutent au démarrage, pas dans un job d'initialisation. Le supervisord de l'image AIO exécute un programme migrator (manage.py migrate) avant le démarrage de l'api et des frontends. La sonde de démarrage accorde jusqu'à ~5 minutes (délai initial de 30 s + 30 échecs × 10 s) pour un premier démarrage à froid.
Les URL de connexion sont composées par le point d'entrée. Le point d'entrée de la plateforme construit DATABASE_URL (TCP sur IP privée, sslmode=require ; loopback avec sslmode=disable sur GKE), REDIS_URL (en résolvant $(NFS_SERVER_IP)) et AMQP_URL (à partir de l'hôte injecté du sidecar), puis exécute le /app/start.sh intégré de Plane. Recherchez les lignes de journal Composed DATABASE_URL / REDIS_URL / AMQP_URL lors du débogage.
RabbitMQ est obligatoire. Le start.sh de Plane valide AMQP_URL et se termine s'il est vide. L'état du courtier du sidecar est éphémère — les tâches Celery en file sont perdues lors du recyclage d'une instance (TODO de durcissement documenté).
Configuration initiale — God Mode. Ouvrez <web_url>/god-mode/ pour créer l'administrateur de l'instance et configurer celle-ci (le point d'entrée modifie le Caddyfile interne avec une redirection 308 de /god-mode vers /god-mode/, pour contourner un problème de basename de la SPA Remix). Inscrivez-vous ensuite à l'URL racine et créez votre premier espace de travail.
Les téléversements de fichiers échouent tant que le stockage S3 n'est pas câblé. Tout le reste (tickets, projets, cycles, modules) fonctionne ; les pièces jointes et les avatars nécessitent de vrais identifiants S3 (voir §2D).
Compromis du démarrage à froid. Avec la configuration par défaut cpu_always_allocated = false + min = 0, le travail Celery en arrière-plan (notifications, webhooks, exports) ne s'exécute que lorsqu'une instance est active. Pour les équipes qui dépendent de notifications rapides, passez à cpu_always_allocated = true + min_instance_count = 1.
Chemin de santé. Les sondes de démarrage et de vivacité ainsi que le test de disponibilité ciblent /health sur le port 80 (le proxy Caddy interne).

Vérification :

curl -s -o /dev/null -w "%{http_code}\n" "$SERVICE_URL/health"
gcloud run services logs read <service-name> --region "$REGION" --limit 100 | grep -E "Composed|Starting Plane"

4. Variables de configuration

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