Plateforme de déploiement GitOps multi-applications

Contexte

Plusieurs applications clientes, de technologies différentes, doivent tourner sur un même cluster Kubernetes auto-hébergé, avec la même rigueur de déploiement pour chacune.

Problème et contraintes

• Éviter un jeu de manifestes écrit à la main par application, qui dérive avec le temps.
• Aucun déploiement manuel en production : chaque changement doit être revu et traçable.
• Des bases de données, des sauvegardes et des secrets à gérer sans les exposer dans Git en clair.

Décisions d'architecture et compromis

Dix-sept décisions d'architecture structurent la plateforme, notamment :

• Un chart Helm générique unique, alimenté par un profil par application : le rendu est généré puis validé avant d'être commité, plutôt que des charts dupliqués.
• Argo CD lit un dépôt GitOps dédié : l'état du cluster est celui de Git, et la promotion d'une version est une modification revue.
• PostgreSQL opéré par CloudNativePG en production, avec une stratégie de stockage et de sauvegarde décidée en amont.
• Un hôte canonique par application, et une stratégie explicite de namespaces, d'ingress et de TLS.

Sécurité et livraison

• Secrets chiffrés avec SOPS dans Git : le dépôt peut être lu sans exposer de valeur.
• Pipeline Jenkins de promotion : une nouvelle image est épinglée dans le profil, le rendu est validé, puis Argo CD synchronise.
• Un point d'entrée unique pour valider localement avant toute promotion.

Résultats et état actuel

• En production : la plateforme déploie aujourd'hui plusieurs applications (dont l'ONG médicale et la plateforme EdTech présentées ici).
• Le portail utilisateur prévu au-dessus de la plateforme n'est pas encore construit.