GitOps vs CI/CD traditionnel

---

Table des matières

1. CI/CD traditionnel
2. Le modèle Push
3. Le modèle Pull (GitOps)
4. Comparaison détaillée
5. Quand choisir quoi ?
6. Exercices pratiques

---

1 - CI/CD traditionnel

Architecture classique

Exemple avec GitHub Actions

# .github/workflows/deploy.yml
name: Build and Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .
      - run: docker push myapp:${{ github.sha }}
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: azure/k8s-set-context@v1
        with:
          kubeconfig: ${{ secrets.KUBECONFIG }}
      
      - run: kubectl set image deployment/myapp myapp=myapp:${{ github.sha }}

Problèmes du CI/CD traditionnel

Problème	Impact
Credentials exposés	kubeconfig dans CI
Drift possible	Changements manuels non tracés
Pas de self-healing	Si quelqu'un modifie directement
Audit incomplet	Actions hors Git non tracées

🔝 Retour à la table des matières

---

2 - Le modèle Push

Comment ça marche

Caractéristiques

• Le CI/CD pousse les changements vers le cluster
• Le CI a des credentials d'accès au cluster
• Déploiement déclenché par le pipeline
• L'état du cluster peut diverger de Git

Sécurité

# Le CI doit stocker des secrets sensibles
KUBECONFIG=...
# ou
kubectl config set-credentials ...

# Risques :
# - Fuite des credentials
# - Accès direct au cluster
# - Surface d'attaque élargie

🔝 Retour à la table des matières

---

3 - Le modèle Pull (GitOps)

Comment ça marche

Caractéristiques

• L'agent tire les changements depuis Git
• Aucun credential externe vers le cluster
• Le cluster s'auto-réconcilie
• Git est la source de vérité absolue

Sécurité améliorée

# Le CI n'a PAS accès au cluster
# Seul l'agent GitOps (dans le cluster) a accès

# Avantages :
# - Pas de credentials CI vers cluster
# - Surface d'attaque réduite
# - Principe du moindre privilège

Workflow GitOps

# 1. CI: Build et push l'image
# .github/workflows/ci.yml
build:
  steps:
    - run: docker build -t myapp:${{ github.sha }} .
    - run: docker push registry/myapp:${{ github.sha }}
    
    # Mise à jour du repo GitOps
    - run: |
        git clone $GITOPS_REPO
        cd gitops-repo
        yq -i '.spec.template.spec.containers[0].image = "myapp:${{ github.sha }}"' apps/myapp/deployment.yaml
        git commit -am "Update myapp to ${{ github.sha }}"
        git push

# 2. GitOps Agent détecte le changement et l'applique

🔝 Retour à la table des matières

---

4 - Comparaison détaillée

Tableau comparatif

Aspect	CI/CD Push	GitOps Pull
Direction	CI → Cluster	Cluster ← Git
Credentials	CI a accès cluster	Agent interne seulement
Drift	Possible	Auto-corrigé
Rollback	Pipeline à relancer	git revert
Audit	Logs CI	Git history
Self-healing	Non	Oui
Complexité	Simple	Initiale plus complexe

Sécurité

Critère	Push	Pull
Credentials externes	✅ Oui	❌ Non
Surface d'attaque	Large	Réduite
Connexions entrantes	Requises	Non requises

Réconciliation

# Scénario : Quelqu'un fait kubectl directement
kubectl scale deployment/myapp --replicas=10

# Push Model : 
# - Le changement persiste
# - Drift par rapport à Git
# - Pas de correction automatique

# Pull Model (GitOps) :
# - L'agent détecte la différence
# - Rétablit l'état de Git (ex: replicas=3)
# - Le changement manuel est annulé

🔝 Retour à la table des matières

---

5 - Quand choisir quoi ?

Choisir CI/CD Push si

• ✅ Application simple, peu de déploiements
• ✅ Équipe petite sans culture GitOps
• ✅ Pas de Kubernetes
• ✅ Déploiements peu fréquents

Choisir GitOps Pull si

• ✅ Kubernetes en production
• ✅ Besoin d'audit complet
• ✅ Équipes multiples
• ✅ Multi-environnements (dev, staging, prod)
• ✅ Exigences de sécurité élevées
• ✅ Besoin de self-healing

Migration progressive

# Étape 1 : Séparer le repo GitOps
# Le CI met à jour le repo GitOps au lieu de kubectl

# Étape 2 : Installer l'agent GitOps
# ArgoCD ou Flux dans le cluster

# Étape 3 : Désactiver le push direct
# Le CI ne fait plus kubectl

🔝 Retour à la table des matières

---

6 - Exercices pratiques

Quiz

Q1. Quelle est la principale différence de sécurité entre Push et Pull ?

Réponse

En Push, le CI a des credentials pour accéder au cluster (surface d'attaque large). En Pull, seul l'agent interne au cluster accède à Git (surface d'attaque réduite).

Q2. Que se passe-t-il si quelqu'un fait kubectl scale manuellement en GitOps ?

Réponse

L'agent GitOps détecte le drift entre l'état réel et l'état dans Git, puis réconcilie automatiquement en rétablissant l'état de Git.

Exercice : Analyse de scénario

Votre équipe hésite entre Push et Pull. Analysez :

• 50 microservices sur Kubernetes
• 3 environnements (dev, staging, prod)
• Exigences de conformité (SOC2)
• Équipe de 15 développeurs

Recommandation

GitOps Pull est recommandé car :

• Multi-environnements → GitOps excelle
• SOC2 → Audit trail complet dans Git
• 50 services → Drift serait un cauchemar sans self-healing
• 15 devs → Risque de changements manuels non tracés

🔝 Retour à la table des matières

---

Points clés à retenir

• Push : CI pousse vers le cluster (credentials exposés)
• Pull : Agent tire depuis Git (plus sécurisé)
• GitOps = self-healing et audit complet
• Push = simple mais risque de drift
• Migration progressive possible

🔝 Retour à la table des matières

---

← Chapitre précédent | Chapitre suivant : Source de vérité →