Aller au contenu

Plane — pilotage projet

Decision du 11/10/2026 : retrait B2. Les sauvegardes/PITR B2 ci-dessous sont historiques et retirees du rendu actif.

Élément Valeur
Namespace plane
Version Plane Community Edition v1.4.2, images épinglées par digest
URL https://plane.lab.djayzone.com
Authentification Authentification native Plane ; aucun proxy SSO GitHub devant l'application
Base de données Cluster CloudNativePG dédié plane-postgresql, 1 instance
Cache / file Valkey (cache), RabbitMQ (file de travail)
Stockage objet MinIO local plane-minio pour les uploads runtime ; Backblaze B2 backups-lab/plane-postgresql/ pour les backups PostgreSQL
Criticité non critique — Plane n'est jamais une dépendance runtime d'un produit

Exploitation sans IA

Les procédures de diagnostic, reprise et exploitation manuelle sont regroupées dans le manuel opérateur. Elles restent utilisables si le Gateway MCP ou les agents sont indisponibles.

Rôle

Plane est la source de vérité du pilotage : roadmap, modules, Work Items, états, dépendances et blocages. GitHub reste la source de vérité de l'implémentation : code, branches, Pull Requests, reviews et checks.

Les agents passent par le domaine plane.* du MCP Gateway pour les lectures comme pour les écritures. L'API Plane est appelée directement.

Composants

La topologie suit celle du déploiement amont :

Workload Rôle Port
plane-web, plane-admin frontends nginx 3000
plane-space frontend node 3000
plane-live collaboration temps réel 3000
plane-api API Django 8000
plane-worker, plane-beat-worker traitements asynchrones / scheduler —
plane-migrator migrations de schéma —
plane-proxy entrée interne unique 8080
plane-valkey cache / présence / pub-sub 6379
plane-rabbitmq file de travail 5672
plane-minio stockage objet runtime pour les uploads Plane 9000
plane-postgresql base métier 5432

Le proxy amont est conservé plutôt que de réimplémenter ses règles de routage dans l'Ingress. L'Ingress cible plane-proxy, qui résout ensuite les Services courts web, space, admin, live et api.

Stockage objet — MinIO runtime, B2 pour les backups PostgreSQL

L'état courant a changé après le cutover initial vers Backblaze B2. Plane CE v1.4.2 utilise des uploads navigateur basés sur des formulaires S3 pré-signés qui ne sont pas compatibles avec le chemin B2 retenu ici. Le runtime a donc été rebasculé vers MinIO local pour les pièces jointes et objets applicatifs.

Configuration déclarative actuelle :

USE_MINIO=1
AWS_S3_ENDPOINT_URL=http://plane-minio.plane.svc.cluster.local:9000
AWS_S3_BUCKET_NAME=uploads
BUCKET_NAME=uploads
MINIO_ENDPOINT_SSL=0

Les workloads Plane consomment les credentials du Secret plane-minio, créé hors Git. Le Deployment et le Service plane-minio sont actifs ; le job plane-b2-to-minio-v1 matérialise le retour contrôlé du stockage runtime vers MinIO. Au 21/09/2026, le pod MinIO est 1/1 Running sans restart.

Backblaze B2 reste utilisé pour la protection PostgreSQL, via le préfixe distinct s3://backups-lab/plane-postgresql/ et le plugin CloudNativePG/Barman. Le stockage objet runtime et le catalogue de backup ne doivent pas être confondus.

Chaîne d'accès

Navigateur -> Traefik (TLS cert-manager)
           -> plane-proxy
           -> web / space / admin / live / api
                         |
                         +-> PostgreSQL / Valkey / RabbitMQ
                         +-> MinIO plane-minio (S3 interne)
PostgreSQL/CNPG -------> Backblaze B2 backups-lab (HTTPS/S3)

Il n'y a pas de couche OAuth2 Proxy devant Plane. L'authentification est gérée par Plane lui-même.

Réseau

Le namespace applique un default-deny. Les ouvertures sont ciblées :

  • Traefik → plane-proxy:8080 ;
  • proxy → frontends / API ;
  • API / worker / beat-worker → PostgreSQL, RabbitMQ, Valkey selon besoin ;
  • backend Plane → plane-minio:9000 pour les objets runtime ;
  • sidecar Barman de PostgreSQL → HTTPS 443 vers Backblaze B2 pour les backups/WAL ;
  • DNS vers CoreDNS ;
  • aucun accès public direct à MinIO : le Service reste interne au namespace.

Les règles temporaires utilisées pour les jobs de preflight ou de migration ne constituent pas une dépendance runtime de Plane.

Migrations de schéma

Le migrator est un Job, pas un init container. Son nom porte la version et une révision (plane-migrator-v1-4-2-r2) car le PodTemplate d'un Job est immuable. Un Job échoué ne doit pas être rejoué implicitement : une nouvelle révision crée explicitement un nouveau Job.

manage.py wait_for_migrations attend réellement la base. En revanche, manage.py wait_for_db ne constitue pas un vrai probe réseau fiable ; les Deployments peuvent redémarrer jusqu'au retour de PostgreSQL, tandis que le Job de migration doit conserver un budget de reprise suffisant.

Secrets

Secrets principaux :

Secret Usage
plane-secrets SECRET_KEY, LIVE_SERVER_SECRET_KEY
plane-rabbitmq credentials RabbitMQ
plane-postgresql-app généré par CloudNativePG ; URI PostgreSQL
plane-minio credentials S3 du stockage objet runtime MinIO
backblaze-b2-backups-lab credentials B2 du catalogue PostgreSQL backups-lab/plane-postgresql/

Le Secret plane-minio est de nouveau utilisé par les workloads Plane pour les uploads runtime. Les credentials B2 de sauvegarde PostgreSQL restent séparés dans backblaze-b2-backups-lab.

Sauvegarde et restauration

MinIO est le stockage objet runtime actif pour les pièces jointes. La donnée métier Plane reste principalement dans PostgreSQL ; Backblaze B2 backups-lab sert séparément aux backups/WAL PostgreSQL.

Les backups PostgreSQL/WAL sont désormais déclarés séparément vers backups-lab/plane-postgresql/ via CNPG/Barman (30 jours). Cette protection n'est qualifiée qu'après un backup Completed et un restore isolé réussi.

La stratégie de reprise distingue donc :

  • PostgreSQL / CNPG : projets, modules, work items, utilisateurs et métadonnées ;
  • MinIO plane-minio : pièces jointes et objets runtime ;
  • Backblaze B2 backups-lab/plane-postgresql/ : backups complets et WAL PostgreSQL ;
  • Git : manifests Kubernetes et configuration déclarative ;
  • Valkey / RabbitMQ : état de cache / file transitoire, non autoritaire.

Voir Plane — sauvegarde, restauration et exploitation pour le runbook détaillé.

Surveillance

Plane est un outil de pilotage non critique. Les contrôles utiles sont :

  • route HTTPS disponible ;
  • certificat valide ;
  • plane-api Ready ;
  • PostgreSQL primaire Ready ;
  • absence d'erreurs S3/MinIO dans l'API et le worker ;
  • ContinuousArchiving=True et dernier backup CNPG réussi ;
  • test fonctionnel d'upload si un doute existe sur CORS ou les URLs pré-signées.

Une panne Plane ne doit pas bloquer la CI, GitOps ou les produits applicatifs.

Données

Plane contient des métadonnées projet et techniques. Les secrets applicatifs ne doivent pas être copiés dans les Work Items, descriptions ou commentaires.