Introduction au GitOps
Table des matières
- Qu'est-ce que le GitOps ?
- Les 4 principes du GitOps
- Pourquoi adopter GitOps ?
- Cas d'utilisation
- GitOps et Kubernetes
- Exercices pratiques
1 - Qu'est-ce que le GitOps ?
Définition
GitOps est une méthodologie de déploiement continu qui utilise Git comme source unique de vérité pour l'infrastructure et les applications déclaratives.
Origine
- 2017 : Terme inventé par Weaveworks
- Évolution naturelle de l'Infrastructure as Code (IaC)
- Popularisé avec l'essor de Kubernetes
En une phrase
GitOps = Infrastructure as Code + Pull Request + Continuous Deployment
🔝 Retour à la table des matières
2 - Les 4 principes du GitOps
Principe 1 : Déclaratif
# L'état désiré est décrit, pas les actions
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3 # Je veux 3 réplicas
# Pas : "scale up de 2 à 3"
| Impératif | Déclaratif |
|---|---|
kubectl scale --replicas=3 | replicas: 3 dans YAML |
| "Fais cette action" | "Voici l'état souhaité" |
| Non reproductible | Reproductible |
Principe 2 : Versionné et Immuable
# Tout dans Git
infrastructure/
├── apps/
│ ├── frontend.yaml
│ └── backend.yaml
├── monitoring/
│ └── prometheus.yaml
└── ingress/
└── nginx.yaml
# Historique complet
git log --oneline
a1b2c3d Update replicas to 5
d4e5f6g Add monitoring stack
g7h8i9j Initial infrastructure
Principe 3 : Récupéré Automatiquement (Pull)
Principe 4 : Réconciliation Continue
| Concept | Description |
|---|---|
| État désiré | Ce qui est dans Git |
| État réel | Ce qui tourne dans le cluster |
| Drift | Écart entre les deux |
| Réconciliation | Correction automatique |
🔝 Retour à la table des matières
3 - Pourquoi adopter GitOps ?
Avantages
| Avantage | Description |
|---|---|
| Auditabilité | Tout changement est tracé dans Git |
| Rollback facile | git revert = rollback production |
| Sécurité | Pas de kubectl direct en production |
| Reproductibilité | Même config = même résultat |
| Collaboration | Pull Requests pour les changements |
| Self-healing | Réconciliation automatique |
Exemple concret
# Avant GitOps
ssh server
kubectl set image deployment/app app=v2
# Qui a fait quoi ? Quand ? Pourquoi ?
# Avec GitOps
git checkout -b feature/update-app-v2
# Modifier deployment.yaml
git commit -m "Update app to v2 - fixes #123"
git push
# Créer Pull Request
# Review par l'équipe
# Merge = déploiement automatique
# Historique complet dans Git
ROI du GitOps
| Métrique | Avant | Après GitOps |
|---|---|---|
| Temps de déploiement | 30 min | 5 min |
| Temps de rollback | 1h+ | 2 min |
| Incidents de config | Fréquents | Rares |
| Audit trail | Partiel | 100% |
🔝 Retour à la table des matières
4 - Cas d'utilisation
Idéal pour
- ✅ Déploiements Kubernetes
- ✅ Infrastructure cloud (IaC)
- ✅ Configuration d'applications
- ✅ Environnements multi-clusters
- ✅ Équipes distribuées
Moins adapté pour
- ⚠️ Applications legacy non-conteneurisées
- ⚠️ Changements très fréquents (bases de données)
- ⚠️ Équipes sans culture Git
Exemples d'entreprises
| Entreprise | Usage |
|---|---|
| Weaveworks | Créateur du terme, utilise Flux |
| Intuit | 2500+ microservices via ArgoCD |
| Adobe | Multi-cloud avec GitOps |
| Chick-fil-A | Edge computing |
🔝 Retour à la table des matières
5 - GitOps et Kubernetes
Pourquoi Kubernetes ?
Kubernetes est naturellement compatible avec GitOps car :
- API déclarative (YAML/JSON)
- Concept de controllers (réconciliation)
- État désiré vs état réel intégré
Workflow typique
# 1. Développeur modifie deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5 # Changement: 3 → 5
# 2. Commit et Push
# git commit -m "Scale my-app to 5 replicas"
# git push
# 3. GitOps operator détecte le changement
# 4. Apply automatique sur le cluster
# 5. Kubernetes réconcilie (crée 2 pods)
Outils GitOps pour Kubernetes
| Outil | Type | Maintenu par |
|---|---|---|
| ArgoCD | Application | CNCF |
| Flux | Toolkit | CNCF |
| Fleet | Multi-cluster | Rancher |
| Jenkins X | CI/CD + GitOps | Jenkins |
🔝 Retour à la table des matières
6 - Exercices pratiques
Quiz
Q1. Quel est le principe fondamental de GitOps ?
Réponse
Git comme source unique de vérité (Single Source of Truth) pour l'état désiré de l'infrastructure.
Q2. Quelle est la différence entre Push et Pull model ?
Réponse
- Push : Le CI/CD pousse les changements vers le cluster
- Pull : Un agent dans le cluster tire les changements depuis Git
Q3. Pourquoi Kubernetes est-il adapté au GitOps ?
Réponse
Car Kubernetes a une API déclarative native et un système de controllers qui compare constamment l'état désiré à l'état réel.
Exercice : Identifier les avantages
Pour chaque scénario, identifiez l'avantage GitOps :
- Un changement non autorisé est fait directement sur le cluster → Self-healing
- Besoin de savoir qui a déployé quoi il y a 3 mois → Auditabilité
- Un déploiement cause des problèmes → Rollback facile
🔝 Retour à la table des matières
Points clés à retenir
- GitOps = Git comme source de vérité
- 4 principes : Déclaratif, Versionné, Pull-based, Réconciliation
- Avantages : auditabilité, rollback, sécurité, reproductibilité
- Kubernetes est naturellement compatible avec GitOps
- ArgoCD et Flux sont les outils les plus populaires