DevOps·

L'automatisation des déploiements avec ArgoCD et Kubernetes

Découvrez comment automatiser les déploiements de vos applications avec ArgoCD et Kubernetes pour une gestion efficace et fiable de votre infrastructure.
L'automatisation des déploiements avec ArgoCD et Kubernetes

Introduction

ArgoCD est l'outil que j'installe sur chaque cluster Kubernetes en production. En tant que pilier du GitOps, il garantit que l'état du cluster correspond toujours à ce qui est déclaré dans Git. Voici comment je l'utilise au quotidien, avec des retours d'expérience concrets.

ArgoCD en détail : le GitOps en action

Le principe d'ArgoCD est élégant : vous déclarez l'état souhaité de votre application dans un dépôt Git (Helm Charts, Kustomize ou manifests bruts), et ArgoCD s'assure que le cluster Kubernetes reflète cet état en permanence. Si quelqu'un fait un kubectl edit en production, ArgoCD détecte la dérive et restaure l'état souhaité.

Chez Padam Mobility, cette propriété a mis fin aux modifications manuelles en production. Avant ArgoCD, un ingénieur pressé pouvait modifier un Deployment directement sur le cluster pour "corriger un bug en urgence". Le problème : ces modifications n'étaient pas tracées et disparaissaient au prochain déploiement, causant confusion et incidents. Avec ArgoCD, le message est clair : si ce n'est pas dans Git, ça n'existe pas.

Kubernetes : la plateforme de déploiement

Kubernetes fournit les primitives dont ArgoCD a besoin : Deployments pour les rolling updates, Services pour le networking, Ingress pour le routing HTTP, et tout l'écosystème de custom resources. ArgoCD s'installe via Helm en quelques minutes et s'intègre nativement avec l'API Kubernetes.

Chez un acteur de la Défense, ArgoCD tourne sur un cluster OVH Cloud avec des contraintes de sécurité strictes. Il déploie des Helm Charts qui incluent des NetworkPolicies deny-by-default, des pods non-root avec seccomp, et des secrets gérés via OKMS. Tout ça est défini dans Git et appliqué automatiquement par ArgoCD.

L'intégration ArgoCD dans le pipeline CI/CD

Mon architecture CI/CD standard sépare strictement CI et CD :

  1. CI (GitHub Actions) : tests, build Docker, push image vers GHCR
  2. Image Updater : met à jour le tag d'image dans le repo Git des manifests
  3. CD (ArgoCD) : détecte le changement dans Git et déploie

La clé : le pipeline CI n'a jamais d'accès au cluster Kubernetes. Seul ArgoCD peut modifier le cluster. Cette séparation est essentielle pour la sécurité, surtout dans les environnements réglementés (Défense, santé HDS).

Les avantages mesurables

Chez Earny SA, lors de la migration GCP vers AWS, ArgoCD a déployé les applications sur les deux clusters en parallèle pendant la phase de transition. Le basculement s'est fait sans downtime et avec la possibilité de revenir en arrière instantanément.

Sur un cluster que je gère, le temps moyen de rollback est passé de 15-20 minutes (scripts de déploiement manuels) à 45 secondes (git revert + sync ArgoCD). Quand un bug critique est détecté par Prometheus en production, cette rapidité fait la différence.

Les stratégies de déploiement avancées

ArgoCD, combiné avec Argo Rollouts, supporte des stratégies de déploiement avancées :

  • Blue/Green : deux versions en parallèle, basculement instantané
  • Canary : déploiement progressif (10%, 50%, 100%) avec validation à chaque étape

Chez Bloomflow, le canary deployment permet de tester une nouvelle version sur 10% du trafic avant de l'étendre. Si les métriques Prometheus montrent une dégradation, le rollback est automatique.

Les sync waves pour les dépendances

ArgoCD permet d'ordonner les déploiements avec les sync waves. C'est indispensable quand vos applications ont des dépendances : d'abord les migrations de base de données (wave -1), puis les services backend (wave 0), puis le frontend (wave 1). Sans cet ordonnancement, un backend qui démarre avant la migration de base de données va crasher.

Conclusion

ArgoCD est devenu un standard de facto pour le déploiement GitOps sur Kubernetes. Son installation est simple (5 minutes via Helm), ses bénéfices sont immédiats (traçabilité, rollback rapide, détection des dérives), et il s'intègre naturellement dans un pipeline CI/CD sécurisé. Si vous utilisez Kubernetes en production sans ArgoCD (ou Flux), vous passez à côté d'un outil qui transformera votre workflow de déploiement.



RDV