Git comme source de vérité
Table des matières
- Single Source of Truth
- État désiré vs état réel
- Immutabilité et versioning
- Branching strategies
- Bonnes pratiques
- Exercices pratiques
1 - Single Source of Truth
Définition
Single Source of Truth (SSOT) = Une seule source fait autorité pour l'état désiré du système.
Pourquoi Git ?
| Caractéristique | Avantage pour SSOT |
|---|---|
| Versionné | Historique complet |
| Distribué | Haute disponibilité |
| Merge/Diff | Collaboration |
| Signatures | Authenticité |
| Branches | Environnements |
Ce qui va dans Git
gitops-repo/
├── apps/
│ ├── frontend/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ └── ingress.yaml
│ └── backend/
│ ├── deployment.yaml
│ └── service.yaml
├── infrastructure/
│ ├── monitoring/
│ │ ├── prometheus.yaml
│ │ └── grafana.yaml
│ └── ingress/
│ └── nginx-ingress.yaml
└── namespaces/
└── namespaces.yaml
🔝 Retour à la table des matières
2 - État désiré vs état réel
Les deux états
Détection du drift
# État désiré (Git)
spec:
replicas: 3
# État réel (Cluster) - Quelqu'un a fait kubectl scale
spec:
replicas: 5
# L'agent GitOps détecte :
# Drift detected: replicas 5 != 3
# Action: Reconciling to desired state
Réconciliation
| Mode | Comportement |
|---|---|
| Auto-sync | Correction automatique du drift |
| Manual sync | Notification, action manuelle |
| Dry-run | Affiche les différences seulement |
# ArgoCD - Configuration de sync
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
syncPolicy:
automated:
prune: true # Supprime les ressources non dans Git
selfHeal: true # Corrige le drift automatiquement
🔝 Retour à la table des matières
3 - Immutabilité et versioning
Historique Git
# Chaque changement est tracé
git log --oneline
a1b2c3d (HEAD -> main) Rollback to v1.9 - hotfix #567
d4e5f6g Deploy v2.0 - feature #234
g7h8i9j Scale backend to 5 replicas
j0k1l2m Add monitoring stack
m3n4o5p Initial infrastructure
# Qui, quand, quoi, pourquoi
git show a1b2c3d
Author: [email protected]
Date: Mon Dec 15 14:30:00 2024
Message: Rollback to v1.9 - hotfix #567
# Rollback = simple git revert
git revert a1b2c3d
Tags pour les releases
# Tagger les versions stables
git tag -a v1.0.0 -m "Production release v1.0.0"
git push origin v1.0.0
# Utiliser les tags dans ArgoCD
spec:
source:
targetRevision: v1.0.0 # ou HEAD, ou branch
Avantages de l'immutabilité
| Avantage | Description |
|---|---|
| Audit | Preuve de qui a fait quoi |
| Rollback | Retour à n'importe quelle version |
| Reproductibilité | Même commit = même état |
| Compliance | Traçabilité pour SOC2, ISO |
🔝 Retour à la table des matières
4 - Branching strategies
Strategy 1 : Branch per environment
main (production)
├── staging
└── develop
# Promotion : develop → staging → main
# Workflow
git checkout develop
# Faire les changements
git commit -m "New feature"
git push
# Promotion vers staging
git checkout staging
git merge develop
git push
# Promotion vers production
git checkout main
git merge staging
git push
Strategy 2 : Single branch + directories
main/
├── environments/
│ ├── dev/
│ │ └── kustomization.yaml
│ ├── staging/
│ │ └── kustomization.yaml
│ └── prod/
│ └── kustomization.yaml
└── base/
└── deployment.yaml
Strategy 3 : Single branch + overlays (Kustomize)
# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 1 # Base
# overlays/prod/kustomization.yaml
resources:
- ../../base
patchesStrategicMerge:
- replicas-patch.yaml
# overlays/prod/replicas-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 5 # Override pour prod
Comparaison
| Strategy | Avantages | Inconvénients |
|---|---|---|
| Branch per env | Simple, claire | Merge conflicts |
| Directory per env | Pas de merge | Duplication |
| Kustomize overlays | DRY, flexible | Complexité |
🔝 Retour à la table des matières
5 - Bonnes pratiques
Structure de repository
gitops-repo/
├── README.md
├── apps/
│ ├── app1/
│ │ ├── base/
│ │ └── overlays/
│ │ ├── dev/
│ │ ├── staging/
│ │ └── prod/
│ └── app2/
├── infrastructure/
│ ├── cert-manager/
│ ├── ingress-nginx/
│ └── monitoring/
└── clusters/
├── dev-cluster/
├── staging-cluster/
└── prod-cluster/
Conventions de commit
# Format
<type>(<scope>): <description>
# Exemples
feat(frontend): deploy v2.3.0
fix(backend): increase memory limit to 1Gi
chore(monitoring): update Prometheus to 2.45
docs(readme): add deployment instructions
# Avec référence au ticket
feat(api): add rate limiting - closes #123
Review process
# Toujours via Pull Request
1. Créer une branche
2. Faire les changements
3. Ouvrir une PR
4. Review par l'équipe
5. Tests automatiques (lint, validation)
6. Merge = déploiement
Ce qui NE va PAS dans Git
- ❌ Secrets en clair
- ❌ Données dynamiques (métriques, logs)
- ❌ État de la base de données
- ❌ Configurations générées
🔝 Retour à la table des matières
6 - Exercices pratiques
Quiz
Q1. Que signifie "drift" en GitOps ?
Réponse
Le drift est l'écart entre l'état désiré (dans Git) et l'état réel (dans le cluster). Par exemple, si Git dit replicas: 3 mais le cluster a replicas: 5.
Q2. Pourquoi les secrets ne vont pas directement dans Git ?
Réponse
Car Git conserve l'historique complet. Même si vous supprimez un secret, il reste dans l'historique. Il faut utiliser des solutions comme Sealed Secrets, SOPS ou Vault.
Exercice : Choisir une stratégie
Votre équipe a 3 environnements. Quelle stratégie de branches recommandez-vous ?
Recommandation
Pour débuter, Directory per environment est le plus simple :
main/
├── dev/
├── staging/
└── prod/
Une fois à l'aise, migrer vers Kustomize overlays pour réduire la duplication.
🔝 Retour à la table des matières
Points clés à retenir
- SSOT = Git est la seule source de vérité
- État désiré (Git) vs état réel (cluster)
- Drift = écart entre les deux, corrigé par réconciliation
- Historique Git = audit trail complet
- Plusieurs stratégies de branches possibles
- Secrets doivent être chiffrés