ArgoCD est l’outil GitOps de référence pour Kubernetes en 2026. En s’appuyant sur Git comme unique source de vérité, il automatise la synchronisation entre vos manifests versionnés et l’état réel de vos clusters, éliminant les dérives de configuration et simplifiant le rollback. Ce tutoriel complet couvre l’installation, la création d’Applications, la gestion multi-environnement avec Kustomize et Helm, le contrôle d’accès, et le déploiement à grande échelle avec les ApplicationSets.
GitOps : le paradigme qui redéfinit le déploiement Kubernetes
Le GitOps est une approche de déploiement continu qui utilise Git comme unique source de vérité pour l’état désiré d’une infrastructure et de ses applications. Plutôt que d’exécuter des commandes kubectl ou des scripts Ansible à la main, les équipes DevOps décrivent l’état cible dans des fichiers YAML versionnés dans un dépôt Git. Un opérateur (tel qu’ArgoCD) surveille ce dépôt en permanence et réconcilie l’état réel du cluster avec l’état déclaré dans Git. Ce modèle « pull » remplace le modèle « push » des pipelines CI/CD traditionnels.
Les avantages du GitOps sont multiples et tangibles. La traçabilité est totale : chaque modification de configuration est un commit signé, avec auteur, date et message. Le rollback devient trivial : un git revert suffit à restaurer une version antérieure de l’infra. La collaboration s’améliore via les pull requests et les revues de code, qui s’appliquent désormais à l’infrastructure comme au code applicatif. La sécurité est renforcée : les credentials de production ne transitent plus dans les pipelines CI, puisque c’est l’opérateur dans le cluster qui « tire » les changements depuis Git.
ArgoCD est le projet GitOps le plus adopté de l’écosystème Kubernetes. Incubé par la CNCF (Cloud Native Computing Foundation) et passé au statut « graduated » en 2022, il bénéficie d’une large communauté, d’une interface web intuitive, d’une CLI puissante et d’une API REST complète. Il supporte les manifests Kubernetes bruts, Helm, Kustomize, Jsonnet et Ksonnet, ce qui le rend compatible avec la grande majorité des stratégies de packaging Kubernetes existantes.
Architecture d’ArgoCD : composants et fonctionnement interne
ArgoCD se déploie lui-même dans un namespace Kubernetes (généralement argocd) et comprend plusieurs composants clés. Le serveur ArgoCD expose l’interface web et l’API REST. L’Application Controller est le cœur du système : il surveille en permanence l’état des Applications ArgoCD, compare l’état réel du cluster avec l’état désiré dans Git, et déclenche une synchronisation si une dérive (drift) est détectée. Le Repo Server récupère et met en cache le contenu des dépôts Git. Enfin, le Dex Server gère l’authentification via OIDC (GitHub, GitLab, LDAP, SAML).
Le concept central d’ArgoCD est l’objet « Application » (un Custom Resource Kubernetes). Une Application ArgoCD définit la source (dépôt Git, chemin, révision), la destination (cluster Kubernetes cible, namespace), et la politique de synchronisation. ArgoCD gère nativement le déploiement sur plusieurs clusters depuis une installation centralisée : un cluster « hub » peut gérer les déploiements sur des dizaines de clusters cibles, ce qui en fait un outil adapté aux architectures multi-cloud et multi-région des grandes entreprises.
La politique de synchronisation est configurable finement. Le mode manuel exige une action humaine (bouton Sync dans l’UI ou commande argocd app sync) pour appliquer les changements. Le mode automatique (–sync-policy automated) applique les changements dès qu’un nouveau commit est détecté sur la branche cible. L’option –auto-prune supprime automatiquement les ressources Kubernetes qui ont été retirées du dépôt Git. L’option –self-heal corrige automatiquement les dérives manuelles : si quelqu’un modifie un ConfigMap directement avec kubectl, ArgoCD le remet à l’état Git dans les minutes suivantes.
Installation et premiers pas avec ArgoCD
L’installation d’ArgoCD nécessite un cluster Kubernetes fonctionnel (k3s, minikube, ou un cluster cloud comme EKS, GKE ou AKS). L’installation standard se fait en appliquant le manifeste officiel dans un namespace dédié. L’équipe ArgoCD publie des releases régulières sur GitHub avec des notes de migration détaillées. Pour la production, il est conseillé d’utiliser une release spécifique (pas latest) et de l’ajouter à votre propre dépôt GitOps pour bénéficier du versioning de votre propre installation d’ArgoCD.
La première connexion se fait via l’interface web (port 80/443 du service argocd-server) ou la CLI. Le login initial utilise le nom d’utilisateur « admin » et le mot de passe généré automatiquement lors de l’installation, stocké dans un Secret Kubernetes. Pour la production, changez ce mot de passe immédiatement après le premier login (argocd account update-password) et activez l’authentification SSO via GitHub ou GitLab pour supprimer l’accès par mot de passe direct. Créez des comptes de service (argocd account create) avec des permissions limitées pour vos pipelines CI.
Pour créer votre première Application, vous avez deux options : l’interface graphique (bouton « + New App ») qui guide pas à pas, ou la CLI argocd app create avec les flags appropriés. La méthode déclarative (définir l’Application comme un fichier YAML et le soumettre via kubectl apply) est recommandée pour la production, car elle permet de versionner la configuration d’ArgoCD elle-même dans Git : c’est le concept « app of apps » ou « ApplicationSet », qui permet de gérer des centaines d’applications depuis un seul dépôt.
# Installer ArgoCD dans un namespace dédié
kubectl create namespace argocd
kubectl apply -n argocd -f
https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Attendre que tous les pods soient prêts
kubectl wait --for=condition=Ready pod --all -n argocd --timeout=300s
# Récupérer le mot de passe admin initial (encodé en base64)
kubectl -n argocd get secret argocd-initial-admin-secret
-o jsonpath="{.data.password}" | base64 -d
# Port-forward pour accéder à l'UI locale
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Créer une Application ArgoCD depuis un dépôt Git
argocd app create my-app
--repo https://github.com/mon-org/mon-repo.git
--path k8s/overlays/production
--dest-server https://kubernetes.default.svc
--dest-namespace production
--sync-policy automated
--auto-prune
--self-healGestion des environnements avec Kustomize et Helm
La gestion de plusieurs environnements (dev, staging, production) est l’un des cas d’usage les plus courants avec ArgoCD. Deux outils se distinguent : Kustomize et Helm. Kustomize (intégré à kubectl depuis la version 1.14) utilise un fichier kustomization.yaml pour définir une base commune et des overlays par environnement. L’overlay de production peut par exemple modifier les ressources CPU/RAM, le nombre de réplicas, les secrets, ou les URLs d’ingress. ArgoCD comprend Kustomize nativement et applique les overlays automatiquement selon le chemin Git configuré.
Helm est un gestionnaire de packages Kubernetes qui utilise des « charts » (des templates paramétrables). Un chart Helm définit l’ensemble des ressources Kubernetes nécessaires à une application (Deployment, Service, Ingress, ConfigMap) et expose des valeurs personnalisables via un fichier values.yaml. ArgoCD supporte Helm nativement : vous pouvez pointer une Application vers un chart Helm dans un registry OCI ou dans un dépôt Git, et définir des values spécifiques à l’environnement directement dans la configuration de l’Application ArgoCD.
Le choix entre Kustomize et Helm dépend du contexte. Kustomize est préférable pour des applications maison dont vous gérez les templates directement : la structure de fichiers est transparente et lisible. Helm est préférable pour des applications tierces (nginx-ingress, cert-manager, prometheus-stack) car les charts officiels sont maintenus par la communauté. Il est tout à fait possible d’utiliser les deux : Helm pour les composants d’infrastructure, Kustomize pour vos applications métier.
RBAC et gestion des accès dans ArgoCD
ArgoCD dispose d’un système de contrôle d’accès basé sur les rôles (RBAC) qui permet de définir finement qui peut faire quoi. Les permissions portent sur des ressources (applications, repositories, clusters) et des actions (get, create, update, delete, sync). Par défaut, deux rôles existent : « role:readonly » (lecture seule sur toutes les ressources) et « role:admin » (accès total). Pour des équipes plus larges, créez des rôles personnalisés : un rôle « developer » qui peut déclencher une sync sur les environnements de dev/staging mais pas de production, ou un rôle « viewer » pour les parties prenantes non techniques.
L’intégration OIDC (OpenID Connect) avec GitHub, GitLab, Okta ou Azure AD permet de mapper des groupes d’organisations directement sur des rôles ArgoCD. Ainsi, l’équipe « team-backend » dans GitHub peut automatiquement hériter du rôle ArgoCD permettant de gérer les applications du namespace « backend ». Cette intégration supprime la nécessité de gérer des comptes locaux dans ArgoCD et centralise la gestion des accès dans votre provider d’identité existant.
Pour les environnements de production, activez le mode « audit logs » d’ArgoCD qui enregistre toutes les actions (sync, delete, rollback) avec l’identité de l’utilisateur et l’horodatage. Ces logs peuvent être exportés vers un système SIEM (Elasticsearch, Splunk) pour satisfaire aux exigences de conformité (SOC 2, ISO 27001). Activez également les notifications ArgoCD (via le plugin argocd-notifications) pour alerter sur Slack ou Teams lorsqu’une application passe en état « Degraded » ou lorsqu’une sync automatique échoue.
Rollback, health checks et gestion des incidents
L’un des points forts d’ArgoCD est la gestion native du rollback. Chaque déploiement correspond à un commit Git : pour rollback, il suffit de sélectionner une révision antérieure dans l’UI (onglet « History and Rollback ») ou via la CLI (argocd app rollback my-app HEAD~1). ArgoCD redéploie immédiatement les ressources correspondant à cette révision. Cette approche est plus fiable qu’un rollback basé sur des images Docker car elle restaure également les ConfigMaps, Secrets et autres ressources modifiées, pas seulement l’image du container.
ArgoCD surveille la santé (health) de chaque ressource Kubernetes qu’il gère. Les états de santé possibles sont : Healthy (toutes les ressources sont dans l’état attendu), Progressing (un déploiement est en cours), Degraded (une ressource est en erreur, par exemple un pod CrashLoopBackOff), Suspended (l’application est volontairement suspendue), ou Missing (la ressource définie dans Git n’existe pas dans le cluster). Ces états sont visibles dans l’UI sous forme de codes couleur et disponibles via l’API pour intégration dans vos dashboards.
Pour les health checks personnalisés, ArgoCD permet de définir des « custom health checks » en Lua pour des Custom Resource Definitions (CRDs) que le moteur ne connaît pas nativement. Par exemple, un opérateur métier qui gère un type de ressource DatabaseCluster peut avoir un statut « Ready » non standard : le script Lua permet à ArgoCD d’interpréter correctement ce statut et de signaler la ressource comme Healthy ou Degraded selon votre logique métier. Ces scripts sont configurés dans le ConfigMap argocd-cm.
ApplicationSet : déploiement à grande échelle et multi-cluster
ApplicationSet est une extension d’ArgoCD qui permet de créer dynamiquement des Applications à partir de templates et de générateurs. Un générateur List crée une Application par entrée de liste (par exemple, une Application par région géographique). Un générateur Git crée une Application par répertoire ou par fichier dans un dépôt Git (utile pour des équipes autonomes qui ajoutent leurs manifests dans un dossier dédié). Un générateur Cluster crée une Application sur chaque cluster enregistré dans ArgoCD.
Le cas d’usage le plus puissant est la combinaison du générateur Matrix, qui croise deux autres générateurs. Par exemple, pour déployer l’application « api » sur 3 environnements (dev, staging, prod) et 2 régions (eu-west, us-east), un Matrix generator crée automatiquement 6 Applications ArgoCD, chacune configurée avec les bonnes valeurs d’environnement et de région. Ajouter un nouveau cluster ou un nouvel environnement revient simplement à modifier la configuration du générateur : toutes les Applications correspondantes sont créées automatiquement.
Pour les grandes organisations, ArgoCD peut être structuré en architecture « hub-and-spoke » : un cluster ArgoCD central (hub) gère les déploiements sur des dizaines de clusters applicatifs (spoke). Chaque cluster spoke est enregistré avec ses credentials dans le hub, qui maintient une connexion permanente. Cette architecture évite de multiplier les installations d’ArgoCD et centralise la visibilité et la gouvernance des déploiements. Des projets ArgoCD (AppProject) permettent d’isoler les équipes : chaque équipe ne voit et ne peut déployer que dans son périmètre de clusters et de namespaces.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.