Patterns GitOps : Git comme Source Unique de Vérité
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.
Actors: Git host, argocd-server, repo-server, app-controller, Kubernetes API
- Git host → argocd-server webhook: push to main, revision 7be03d1
- argocd-server → app-controller refresh apps tracking that repo
- app-controller → repo-server render repo@revision, path
- repo-server → Git host fetch; check GPG signature
- repo-server ⇠ app-controller rendered YAML (cached in redis)
- app-controller → Kubernetes API diff live vs desired; apply by sync wave, prune
- Kubernetes API ⇠ app-controller admission result, health
Extrait de la fiche « GitOps and Continuous Delivery Security » · Demander la fiche complète
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 :
1 dev/ → 2 staging/ → 3 production/
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)
Extrait de la fiche « GitOps and Continuous Delivery Security » · Demander la fiche complète
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
selfHeal: true, le contrôleur réapplique git dès qu'un objet live dérive.Extrait de la fiche « GitOps and Continuous Delivery Security » · Demander la fiche complète