Cas avances¶

GitOps, self-service platforms, environnements éphémères et migration vers l'IaC.

GitOps — principes¶

GitOps etend les principes de l'IaC en faisant de Git la source de vérité unique pour l'ensemble de l'infrastructure et des applications. Tout changement passe par Git — pas de modification directe des systèmes.

Les quatre principes GitOps (OpenGitOps)¶

1. Declaratif : l'état desire est exprime de façon declarative
2. Versionne et immutable : l'état desire est stocke dans Git, avec un historique complet
3. Tire automatiquement : des agents surveillent Git et appliquent les changements automatiquement
4. Reconciliation continue : des agents detectent et corrigent les ecarts en permanence

Flux GitOps¶

graph LR
    DEV["Developpeur"] -->|"Push / MR"| GIT["Git Repository"]
    GIT -->|"Webhook ou polling"| CI["Pipeline CI<br/>(lint, test, policy)"]
    CI -->|"Merge apres approbation"| GIT
    GIT --> AGENT["Agent GitOps<br/>(ArgoCD / Flux)"]
    AGENT -->|"Pull & reconcile"| INFRA["Infrastructure / Cluster"]
    INFRA -->|"Etat reel"| AGENT
    AGENT -->|"Drift detecte → alerte"| OPS["Ops / Alerting"]

La différence fondamentale avec le CI/CD classique : l'agent tire la configuration depuis Git, il ne la reçoit pas en push. Cela élimine le besoin de credentials de déploiement dans le pipeline.

ArgoCD vs Flux¶

ArgoCD convient aux équipes qui veulent une UI et un écosystème intégré. Flux convient aux équipes qui préfèrent une approche GitOps pure, declarative et moins opaque.

Self-service platforms¶

Une plateforme self-service permet aux équipes de developement de provisionner des environnements, des composants d'infrastructure ou des services sans passer par l'équipe ops pour chaque demande.

Principes¶

• Les ops définissent des templates (modules Terraform, charts Helm, blueprints)
• Les devs choisissent et parametrent depuis un catalogue
• La plateforme provisionne via le pipeline IaC, sans intervention manuelle

Outils¶

• Backstage (Spotify) : portail développeur open source avec catalogue de composants et templates
• Humanitec : plateforme commerciale de developer self-service
• Crossplane : provisioning Kubernetes-native via CRDs — les devs créent des ressources cloud comme des objets Kubernetes

Environnements éphémères¶

Un environnement éphémère est créé automatiquement pour une merge request et détruit après le merge ou la fermeture.

Avantages¶

• Chaque MR dispose de son propre environnement de validation — pas de conflit entre branches
• Validation en conditions réelles avant le merge
• Coût limite : l'environnement n'existe que pendant la durée de la MR

Implémentation¶

1. La CI crée un workspace Terraform nomme preview-<mr-id> sur l'ouverture d'une MR
2. L'environnement est provisionne avec les ressources minimales nécessaires
3. L'URL de l'environnement est postee en commentaire sur la MR
4. À la fermeture de la MR, la CI exécuté terraform destroy sur le workspace

Migration vers l'IaC¶

La migration d'une infrastructure existante (ClickOps) vers l'IaC est un projet a part entière.

Approche progressive¶

Points d'attention¶

• Commencez par les nouvelles ressources : tout ce qui est créé après le début du projet doit passer par l'IaC
• Importez les ressources stables : commencez par le réseau, le DNS, les configurations les moins changeantes
• Planifiez les destructions/recreations : certaines ressources ne peuvent pas être modifiées en place (changement de type d'instance RDS, VPC) — prevoyez une fenêtre de maintenance
• Formez les équipes : la migration technique sans adoption culturelle échoué

Outils¶