L'automatisation des pipelines de déploiement avec Kubernetes et ArgoCD
Introduction
ArgoCD + Kubernetes, c'est la combinaison que je déploie sur la quasi-totalité de mes missions depuis 3 ans. Cette approche GitOps a remplacé avantageusement les scripts de déploiement ad hoc et les kubectl apply manuels. Voici pourquoi et comment.
ArgoCD : Git comme source de vérité
Le principe fondamental d'ArgoCD est simple : l'état souhaité de votre infrastructure est défini dans un dépôt Git (des manifests Kubernetes ou des Helm Charts). ArgoCD compare en permanence cet état souhaité avec l'état réel du cluster, et corrige automatiquement les dérives.
Chez Padam Mobility, cette approche a résolu un problème récurrent : des ingénieurs qui faisaient des modifications manuelles en production via kubectl, créant des dérives invisibles. Avec ArgoCD, toute modification manuelle est automatiquement écrasée par l'état déclaré dans Git. Si vous voulez changer quelque chose, vous passez par une pull request.
La séparation CI/CD propre
Un pattern que j'applique systématiquement :
- CI (GitHub Actions) : build de l'image Docker, tests, push vers le registry
- CD (ArgoCD) : déploiement de l'image sur le cluster Kubernetes
Le pipeline CI n'a jamais de credentials d'accès au cluster de production. Il met à jour un tag d'image dans le dépôt Git des manifests, et ArgoCD fait le reste. Cette séparation est fondamentale pour la sécurité.
Chez un acteur de la Défense, cette isolation est une exigence absolue. Le cluster Kubernetes OVH Cloud est accessible uniquement par ArgoCD, qui tourne à l'intérieur du cluster. Aucun pipeline externe n'y a accès.
Le déploiement multi-environnement
ArgoCD gère nativement les déploiements multi-environnement avec les ApplicationSets. Chez Bloomflow, j'ai configuré des environnements dev, staging et production, chacun dans son namespace, avec des valeurs Helm différentes. Le passage en production est un simple merge de la branche staging vers main.
Chez Earny SA, lors de la migration GCP vers AWS, ArgoCD déployait simultanément sur les deux clusters. Le basculement du trafic s'est fait sans downtime, avec la possibilité de revenir en arrière instantanément.
Les rollbacks automatiques
L'un des avantages majeurs d'ArgoCD : le rollback est un git revert. Pas besoin de chercher quelle version était déployée, pas besoin de scripts spéciaux. L'historique Git est l'historique des déploiements.
Sur une de mes missions, un déploiement a introduit un bug critique détecté par les alertes Prometheus en 3 minutes. Le rollback via ArgoCD a pris 45 secondes. En mode "déploiement manuel", ce même rollback aurait pris 15-20 minutes de stress.
Les bonnes pratiques que j'applique
- Utiliser des Helm Charts plutôt que des manifests bruts (plus maintenables)
- Activer le auto-sync sur les environnements non-prod, et le sync manuel sur la prod
- Configurer les health checks ArgoCD pour valider que le déploiement est réellement sain
- Utiliser les sync waves pour ordonner les déploiements (d'abord les migrations DB, puis l'application)
Conclusion
ArgoCD + Kubernetes est la combinaison que je recommande à tous mes clients. Elle apporte traçabilité, sécurité et fiabilité aux déploiements. Le coût de mise en place est faible (ArgoCD s'installe en 10 minutes via Helm), et le retour est immédiat. Si vous déployez encore manuellement sur Kubernetes, c'est le premier investissement à faire.