Il y a deux ans, notre equipe a fait le pari du GitOps pour gerer l'ensemble de notre infrastructure Kubernetes. Aujourd'hui, avec le recul, nous pouvons dresser un bilan honnete de cette transition : les gains reels, les difficultes rencontrees et les lecons que nous en tirons.
Le contexte : pourquoi le GitOps ?
Notre infrastructure comprenait une quinzaine de microservices deployes sur trois clusters Kubernetes. Les deploiements etaient geres par des pipelines CI/CD classiques avec des scripts kubectl. Les problemes etaient recurrents :
- Derive de configuration entre les environnements
- Difficulte a savoir l'etat reel du cluster
- Rollbacks complexes et stressants
- Manque d'audit trail sur les changements
La mise en place avec ArgoCD
Nous avons choisi ArgoCD comme outil de reconciliation GitOps. La mise en place initiale a pris environ trois mois, incluant la migration progressive de tous nos manifestes vers un repository Git dedie.
# Structure de notre repo GitOps
gitops-repo/
├── base/
│ ├── api-gateway/
│ ├── auth-service/
│ └── user-service/
├── overlays/
│ ├── staging/
│ └── production/
└── argocd/
└── applications.yamlLes gains confirmes
Auditabilite totale
Chaque changement d'infrastructure passe par une Pull Request. L'historique Git devient la source de verite. Fini les "qui a change quoi et quand" : tout est trace, revue et approuve.
Rollbacks en une commande
Un rollback se resume a un git revert. ArgoCD detecte le changement et reconcilie automatiquement l'etat du cluster. Ce qui prenait 30 minutes de stress en prend desormais 2.
Environnements coherents
Grace a Kustomize et aux overlays, nos environnements staging et production partagent la meme base de configuration. Les surprises au deploiement ont quasiment disparu.
Les difficultes rencontrees
La gestion des secrets
C'est le point le plus delicat du GitOps. Stocker des secrets dans Git, meme chiffres, reste un sujet sensible. Nous utilisons Sealed Secrets, mais la solution est loin d'etre parfaite.
La courbe d'apprentissage
L'equipe a du s'adapter a un nouveau workflow. Les developpeurs habitues a kubectl apply ont eu besoin de temps pour adopter le workflow PR-based. La formation et l'accompagnement sont essentiels.
Le GitOps n'est pas juste un outil, c'est un changement culturel. Il faut accompagner l'equipe, pas juste deployer ArgoCD.
Bilan : le referait-on ?
Oui, sans hesitation. Les gains en fiabilite, en tracabilite et en serenite lors des deploiements justifient largement l'investissement initial. Le conseil principal : commencez petit, avec un seul service, et etendez progressivement.