GitOps : principes et architecture

🎯 Objectif : Maîtriser les principes fondamentaux du GitOps, comprendre la différence entre push et pull model, et savoir structurer un workflow GitOps pour Kubernetes.

⏱️ Durée estimée : 45 minutes

Imagine un monde où chaque changement en production est un commit Git. Où tu fais un rollback en tapant git revert. Où tu sais exactement ce qui tourne dans ton cluster parce que c’est écrit noir sur blanc dans un dépôt. C’est ça, le GitOps — un paradigme opérationnel qui utilise Git comme source de vérité unique pour l’état de ton infrastructure et de tes applications.

Le terme a été inventé par Weaveworks en 2017, puis formalisé par la CNCF via le projet OpenGitOps. L’idée directrice est simple et volontairement radicale : si ce n’est pas dans Git, ça n’existe pas.

Pourquoi le GitOps change tout

Avec un CI/CD classique, ton pipeline build l’image puis exécute kubectl apply pour déployer. Ça fonctionne, mais ça crée des problèmes sérieux au quotidien :

• Le CI détient des credentials cluster. Pour déployer, le pipeline a besoin d’un kubeconfig avec des droits admin. Ces secrets vivent dans les variables CI — si un runner est compromis, ton cluster de prod l’est aussi.
• Pas de source de vérité. Quand quelqu’un te demande “qu’est-ce qui tourne en prod ?”, la seule réponse honnête c’est “ce qui est dans le cluster”. Mais l’état réel dérive : un hotfix en kubectl edit, un HPA qui scale, un admin qui patche en urgence…
• Rollback fragile. Tu dois re-run le pipeline de l’ancienne version — en espérant que les artefacts existent encore et que le contexte n’a pas changé.
• Audit artisanal. Qui a déployé quoi, quand ? Fouille dans les logs CI, croise avec les commits, bonne chance.

🔥 Cas réel : Dans une fintech, un dev a fait un kubectl edit deployment en prod un vendredi soir pour un quick fix. Le lundi, le pipeline CI a tourné et a écrasé le changement. Le bug est revenu. Personne ne savait qu’une modification manuelle avait été faite. Avec du GitOps et la réconciliation continue, ce scénario est impossible — le fix manuel aurait été écrasé immédiatement, forçant le dev à passer par Git.

Le GitOps résout tout ça d’un coup : source de vérité dans Git, rollback via git revert, audit trail natif via git log, et credentials qui restent dans le cluster.

Comprendre le concept : les 4 principes OpenGitOps

La CNCF a défini 4 principes qui distinguent le vrai GitOps du simple “je stocke mes YAML dans Git” :

1. Déclaratif — Tu décris ce que tu veux, pas comment y arriver. Un Deployment Kubernetes qui dit “3 replicas de l’image v2.1” est déclaratif. Un script bash qui lance kubectl scale est impératif.

2. Versionné et immutable — L’état désiré vit dans Git. Chaque changement = un commit avec auteur, date et message. Tu peux toujours répondre à “qui a changé quoi, quand, et pourquoi ?”.

3. Automatiquement appliqué — Un opérateur logiciel (ArgoCD, FluxCD) applique les changements. Tu ne tapes plus kubectl apply à la main. Tu merges une PR, l’opérateur s’en charge.

4. Réconciliation continue — L’opérateur surveille en permanence l’état réel du cluster et le compare à Git. Si quelqu’un fait un kubectl edit à la main, la dérive est détectée et corrigée automatiquement.

🧠 À retenir : C’est le principe n°4 qui fait toute la différence. Sans réconciliation continue, tu as de l’Infrastructure as Code classique. Avec, tu as du GitOps.

La distinction fondamentale, c’est le modèle pull vs push. En push (CI/CD classique), le pipeline pousse vers le cluster — le CI a des credentials Kubernetes. En pull (GitOps), un opérateur qui tourne dans le cluster va chercher les changements dans Git — les credentials cluster ne sortent jamais du cluster. Le CI n’a besoin que d’écrire dans un repo Git.

💡 Tip DevOps : Le pull model n’élimine pas le CI. Le CI continue de builder les images et lancer les tests. Ce qui change : il ne déploie plus directement. Il met à jour le dépôt GitOps (tag de l’image), et l’opérateur fait le reste.

Commandes essentielles : structurer un repo GitOps

La best practice n°1 en GitOps : séparer le code applicatif du code de déploiement dans deux repos distincts. L’App Repo contient le code source, les tests, le Dockerfile. Le GitOps Repo contient les manifests Kubernetes, organisés par environnement.

Voici la structure type d’un repo GitOps avec Kustomize :

gitops-repo/
├── environments/
│   ├── base/                    # Config commune
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   ├── production/              # Overlay prod
│   │   ├── kustomization.yaml
│   │   └── replica-patch.yaml
│   └── staging/                 # Overlay staging
│       └── kustomization.yaml
├── infrastructure/              # Composants partagés
│   ├── cert-manager/
│   └── monitoring/
└── clusters/
    ├── production/apps.yaml     # ArgoCD Applications
    └── staging/apps.yaml

Le base/deployment.yaml définit le manifest commun. Voici un exemple minimaliste :

# environments/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: ghcr.io/org/myapp:latest
          ports:
            - containerPort: 8080

Le kustomization.yaml de base référence les ressources à inclure :

# environments/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

L’overlay production surcharge la base avec des valeurs adaptées. C’est le champ images.newTag que ton CI mettra à jour à chaque nouvelle version :

# environments/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
resources:
  - ../base
patches:
  - path: replica-patch.yaml
images:
  - name: ghcr.io/org/myapp
    newTag: abc123def   # SHA du commit, mis à jour par le CI

Le patch de replicas ajuste le nombre d’instances pour la prod :

# environments/production/replica-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 5

Pour vérifier que tout s’assemble correctement avant de committer :

# Prévisualiser le manifest final pour staging
kubectl kustomize environments/staging

# Prévisualiser celui de production et comparer
kubectl kustomize environments/production

⚠️ Attention : N’utilise jamais le tag latest en GitOps. Ce tag est mutable — il pointe vers des images différentes au fil du temps. Le GitOps repose sur l’immutabilité. Utilise des tags basés sur le SHA du commit ou la version sémantique.

Pour les secrets, ne committe évidemment rien en clair. La combinaison SOPS + age est un excellent point de départ : les valeurs sont chiffrées dans le YAML, seul l’opérateur dans le cluster peut les déchiffrer. Pour des setups plus complexes, External Secrets Operator synchronise les secrets depuis HashiCorp Vault ou AWS Secrets Manager.

Cas concret : migration GitOps dans une entreprise SaaS

🔥 Cas réel : Un éditeur SaaS avec 30+ microservices déployait via Jenkins en push model. Les pipelines avaient des kubeconfigs pour 3 clusters (dev, staging, prod). Voici ce que la migration vers ArgoCD a changé concrètement :

Avant (push model Jenkins) :

• Temps de déploiement moyen : 45 minutes (pipeline + validation manuelle)
• Rollback : 20 minutes (re-run Jenkins + vérification)
• 5 à 10 déploiements par jour
• Un jour, un plugin Jenkins compromis a exfiltré des variables d’environnement — y compris les kubeconfigs de tous les clusters

Après (pull model ArgoCD) :

• Temps de déploiement : 3 minutes (merge PR → réconciliation)
• Rollback : 30 secondes (git revert → merge → réconciliation)
• 30 à 50 déploiements par jour — les équipes n’ont plus peur de déployer
• Jenkins n’a plus aucun accès aux clusters. Même compromis, l’attaquant ne peut que pousser du code dans un repo Git — qui passe par une PR review

Le workflow final : le dev pousse du code → le CI build et pousse l’image → le CI met à jour le tag dans le GitOps repo → ArgoCD détecte et déploie en staging → validation → PR de promotion vers prod → review par un SRE → merge → ArgoCD déploie en prod.

Pièges fréquents

Le drift légitime — Certains changements cluster sont normaux : le HPA qui ajuste les replicas, un controller qui ajoute des annotations. Configure des ignoreDifferences dans ArgoCD pour ces champs, sinon l’opérateur va se battre en permanence contre des changements voulus.

La réconciliation pendant un incident — Si un SRE fait un scale-up d’urgence et que l’opérateur le revert immédiatement, ça aggrave la situation. Assure-toi que ton équipe sait suspendre la réconciliation pendant les incidents.

Les CRDs mal ordonnées — Si ArgoCD essaie de déployer un ServiceMonitor avant que le CRD Prometheus ne soit installé, ça échoue. Utilise les sync waves pour ordonner les installations.

Trop de repos GitOps — Un repo par microservice, c’est ingérable. Un seul repo pour 200 apps, c’est le chaos. Le sweet spot : un repo par équipe ou domaine métier, avec 5 à 20 applications.

⚠️ Attention : Le GitOps ajoute de la complexité opérationnelle en échange de la fiabilité. Si tu as 3 services déployés une fois par semaine, c’est probablement de l’over-engineering. À partir de 10+ services avec des déploiements fréquents, l’investissement se rentabilise très vite.

Exercice : crée ton premier repo GitOps

Mets en place la structure complète d’un repo GitOps pour une application web avec deux environnements :

mkdir -p gitops-demo/environments/{base,staging,production}

# Crée le deployment de base, les overlays staging (2 replicas)
# et production (5 replicas) avec Kustomize

# Vérifie le résultat
kubectl kustomize gitops-demo/environments/staging
kubectl kustomize gitops-demo/environments/production

Ensuite, simule un déploiement : change le tag de l’image dans le kustomization de staging, committe, et observe le diff Git. Ce diff représente exactement ce qui changerait dans le cluster. Maintenant, fais la même chose en impératif avec kubectl set image — et essaie de répondre à “qui a fait ce changement et pourquoi ?” dans les deux cas.

💡 Tip DevOps : Pour choisir ton outil GitOps — si tu débutes, prends ArgoCD. L’UI web est un game changer pour comprendre l’état de ton cluster. Si tu préfères tout en CLI/YAML et que tu veux un truc léger, FluxCD est excellent.

🧠 À retenir :

• GitOps = Git comme source de vérité unique + réconciliation continue
• Le pull model est le cœur du GitOps : l’opérateur dans le cluster va chercher l’état dans Git
• Toujours séparer le repo applicatif du repo GitOps
• Tags immutables uniquement — jamais de latest
• git revert > re-run pipeline pour les rollbacks
• Le GitOps n’élimine pas le CI — il change son rôle : le CI build et teste, l’opérateur déploie

➡️ La suite : Chapitre suivant