Optimiser le Déploiement Continu avec ArgoCD et Kubernetes
Introduction
ArgoCD est devenu mon outil de prédilection pour le déploiement continu sur Kubernetes. Je l'ai déployé sur au moins 6 missions différentes ces dernières années, de la startup (Earny SA) au secteur défense (KNDS), en passant par l'e-santé (Okeiro) et l'industrie (F2R2). Chaque contexte m'a appris quelque chose de nouveau sur la façon d'exploiter au mieux cet outil.
Le principe GitOps appliqué concrètement
ArgoCD incarne le GitOps : l'état souhaité du cluster est décrit dans Git, et ArgoCD synchronise le cluster pour qu'il corresponde. Concrètement, chez Padam Mobility, chaque application avait son répertoire dans un monorepo infra contenant les manifestes Kubernetes (via Helm ou Kustomize). Quand un développeur mergeait une PR modifiant un chart Helm, ArgoCD détectait le changement en moins de 3 minutes et appliquait la modification. Le dashboard ArgoCD affichait en temps réel l'état de synchronisation de chaque application. Cette visibilité a été un game-changer : les développeurs voyaient exactement ce qui était déployé, sans avoir besoin d'accéder au cluster.
La gestion multi-environnements
ArgoCD excelle dans la gestion multi-environnements. Chez F2R2, avec une architecture AWS multi-comptes (25 modules Terraform, EKS Fargate), j'avais configuré ArgoCD pour gérer 3 environnements : dev, staging, production. Chaque environnement avait son ApplicationSet qui pointait vers la même branche mais avec des overlays Kustomize différents (replicas, resources, config). La promotion d'une version se faisait par mise à jour du tag d'image dans le fichier values du bon environnement. Ce workflow a permis de standardiser le processus de déploiement sur les 25 modules tout en gardant la flexibilité de configuration par environnement.
Les secrets avec ArgoCD : le piège à éviter
Le plus grand piège avec ArgoCD est la gestion des secrets. Les secrets ne doivent JAMAIS être stockés en clair dans Git, même dans un repo privé. Ma solution systématique : External Secrets Operator couplé à HashiCorp Vault. Chez KNDS, les secrets sensibles (clés OKMS, tokens d'API) étaient stockés dans Vault et synchronisés automatiquement dans Kubernetes via External Secrets. ArgoCD gérait les ExternalSecret manifests (qui ne contiennent que des références, pas les valeurs). Sur WizOps.fr même, les Helm charts dans wizops_charts/ utilisent External Secrets avec Vault pour les credentials du registry Docker. Cette séparation entre la référence au secret (dans Git) et la valeur du secret (dans Vault) est fondamentale pour un GitOps sécurisé.
Monitoring et alerting ArgoCD
ArgoCD expose des métriques Prometheus natives que j'intègre systématiquement dans Grafana. Chez Bloomflow, le dashboard ArgoCD montrait : le temps de synchronisation par application, le nombre d'applications out-of-sync, les échecs de sync avec le détail de l'erreur. Une alerte Slack se déclenchait si une application restait out-of-sync plus de 10 minutes. Cette supervision a permis de détecter des problèmes subtils : un Helm chart avec un template invalide qui fonctionnait en dry-run mais échouait en apply, des quotas de ressources dépassés sur le namespace, ou des PVC non provisionnable faute de capacité de stockage.
ArgoCD en haute disponibilité
En production, ArgoCD doit lui-même être hautement disponible. Chez Coopengo, en environnement HDS sur AWS, ArgoCD était déployé en mode HA avec 3 replicas du controller et de l'API server, une base Redis sentinelle pour le cache, et un PostgreSQL RDS pour le stockage. Les backups de la configuration ArgoCD (Applications, Projects, Repositories) étaient exportés quotidiennement vers S3. Cette précaution a sauvé la mise lors d'un incident où le namespace ArgoCD a été accidentellement supprimé : la restauration complète a pris 15 minutes au lieu des heures qu'aurait nécessité une reconfiguration manuelle.
Conclusion
ArgoCD transforme le déploiement Kubernetes d'une opération manuelle risquée en un processus automatisé, auditable et réversible. Les clés du succès : séparer les secrets de Git, monitorer ArgoCD lui-même, et adopter une stratégie multi-environnements claire. Après des dizaines de déploiements ArgoCD en production, je considère cet outil comme indispensable dans toute stack Kubernetes sérieuse.