GitOps Patterns: Git as the Single Source of Truth

Le GitOps est un cadre opérationnel qui applique les bonnes pratiques DevOps pour l'automatisation d'infrastructure -- en utilisant Git comme source unique de vérité pour l'infrastructure et les applications déclaratives.

Principes Fondamentaux

Déclaratif : l'ensemble du système est décrit de manière déclarative (YAML, HCL, JSON)
Versionné et immuable : Git fournit la piste d'audit, la capacité de rollback et le modèle de collaboration
Tiré automatiquement : des agents logiciels tirent l'état désiré depuis Git et l'appliquent
Réconcilié en continu : les agents détectent la dérive et la corrigent automatiquement

Modèle Push vs Pull

Aspect	Modèle Push (CI/CD traditionnel)	Modèle Pull (GitOps)
Qui déploie	Le pipeline CI pousse vers le cluster	L'agent dans le cluster tire depuis Git
Credentials	Le CI a besoin d'accès au cluster	Seul l'agent a besoin d'accès au cluster
Détection de dérive	Aucune -- l'état peut diverger silencieusement	Réconciliation continue
Sécurité	Surface d'attaque plus large	Réduite -- pas d'accès externe au cluster nécessaire
Outils	Jenkins, GitHub Actions, GitLab CI	ArgoCD, Flux

Le modèle pull est le standard GitOps car il réduit l'exposition des credentials et garantit que le cluster correspond à l'état Git.

ArgoCD vs Flux

Fonctionnalité	ArgoCD	Flux
Interface	UI web riche avec visualisation	CLI d'abord, UI Weave GitOps optionnelle
Architecture	Centralisée, multi-cluster depuis une instance	Décentralisée, agent par cluster
Multi-tenancy	Projets et RBAC intégrés	RBAC natif Kubernetes
Support Helm	Rend les charts Helm, stocke les manifests	Contrôleur Helm natif
Kustomize	Support intégré	Support intégré
Notifications	Moteur de notification intégré	Contrôleur de notification
Communauté	CNCF diplômé, plus grande communauté	CNCF diplômé, écosystème solide
Idéal pour	Équipes voulant de la visibilité et une UI	Équipes préférant une approche légère et composable

Décision : ArgoCD pour les équipes qui valorisent un dashboard visuel et une gestion centralisée. Flux pour les équipes qui préfèrent les primitives natives Kubernetes et l'opération décentralisée.

Promotion Multi-Environnements

Un flux de promotion GitOps typique :

dev/ --> staging/ --> production/
  |         |            |
  Flux de commits Git : promotion par PR

Stratégies :

Par répertoire : répertoires séparés par environnement (environments/dev/, environments/prod/)
Par branche : branches d'environnement (main = prod, staging, dev) -- moins recommandé à cause de la complexité de merge
Par overlays : overlays Kustomize avec une base partagée et des patches spécifiques par environnement

Mécanismes de promotion :

PR de la config dev vers la config staging
Promotion automatique après des smoke tests réussis
Mises à jour de tags d'images via les contrôleurs d'automatisation d'images (Flux) ou image updater (ArgoCD)

Gestion des Secrets en GitOps

Les secrets dans les repositories Git nécessitent un traitement spécial :

Approche	Fonctionnement	Compromis
Sealed Secrets	Chiffrer les secrets avec la clé publique du cluster, seul le cluster peut déchiffrer	Simple, mais spécifique au cluster
SOPS (Mozilla)	Chiffrer avec AWS KMS, GCP KMS, ou clés PGP	Multi-cloud, compatible git-diff
External Secrets Operator	Synchroniser les secrets depuis Vault, AWS SM, etc. vers K8s	Secrets jamais dans Git, mais ajoute une dépendance
Vault Agent Injector	Injecter les secrets au runtime du pod	Pas de secrets K8s du tout, mais plus complexe

Recommandation : External Secrets Operator pour la plupart des équipes -- les secrets restent dans un vault dédié, jamais dans Git, et se synchronisent automatiquement.

Détection de Derive et Reconciliation

Les agents GitOps comparent en continu l'état désiré (Git) avec l'état réel (cluster) :

Auto-sync : appliquer automatiquement les changements quand une dérive est détectée
Sync manuel : nécessiter une approbation humaine avant d'appliquer (plus sûr pour la production)
Fenêtres de sync : n'autoriser les syncs que pendant les fenêtres de maintenance
Visualisation des diffs : ArgoCD montre exactement ce qui va changer avant le sync
Health checks : vérifier la santé de l'application après le sync, auto-rollback en cas d'échec

Ressources

:::