Installer Argo CD et déployer une application

Pourquoi

La leçon précédente a montré, avec un agent de vingt lignes, ce qu'est une boucle de réconciliation, et tout ce qui lui manque. Argo CD est cette boucle, industrialisée : il sait lire Helm et Kustomize, suit les objets qu'il crée, élague ceux qui disparaissent de Git, évalue la santé des applications, ordonne les déploiements, gère des centaines d'applications et plusieurs clusters, et offre une interface, une API et un contrôle d'accès.

Avant de s'en servir, il faut savoir ce qu'on installe. Argo CD n'est pas un binaire, c'est un ensemble de sept composants dans le cluster, avec des droits étendus et un compte d'administration créé à l'installation. Chez Lyneko, son installation a d'ailleurs provoqué un incident (leçon 10) : sur un cluster d'un seul nœud au disque trop petit, ses images ont fait déborder le disque et le nœud a commencé à expulser des pods, dont le contrôleur d'ingress. Connaître les composants, c'est savoir ce qu'ils coûtent et ce qu'ils protègent.

Cette leçon installe et sécurise Argo CD dans le laboratoire, puis déploie Signalements avec une première Application, en lisant chacun des états qu'Argo CD affiche.

Les concepts

Les composants

    flowchart LR
  U["Interface web<br/>argocd (CLI)"] --> S["argocd-server<br/>(API, interface, auth)"]
  S --> R[("argocd-redis<br/>(cache)")]
  S --> D["argocd-dex-server<br/>(SSO, optionnel)"]
  C["argocd-application-controller<br/>(réconciliation)"] --> RS["argocd-repo-server<br/>(rend les manifestes)"]
  RS --> G["Dépôts Git, OCI, Helm"]
  C --> K["API Kubernetes<br/>(un ou plusieurs clusters)"]
  C --> R
  AS["argocd-applicationset-controller"] --> K
  N["argocd-notifications-controller"] --> K
  

Tout l'état est dans Kubernetes. Les Applications, les projets, les dépôts et les clusters déclarés sont des ressources (Application, AppProject) ou des Secret et ConfigMap du namespace argocd. Sauvegarder ce namespace suffit à reconstruire Argo CD ; et tout peut se déclarer en YAML, donc se gérer lui-même en GitOps.

Les variantes d'installation

Chez Lyneko, Argo CD est installé par le chart Helm communautaire (argo-cd, série 10.9 pour Argo CD 3.5.3), depuis Terraform, avec les autres composants de la plateforme. Le laboratoire utilise le manifeste standard, plus simple à lire.

Synchronisation et santé

Argo CD affiche deux états indépendants pour chaque application et chaque ressource :

Une application peut être Synced et Degraded : elle est exactement ce que dit Git, et ce que dit Git ne fonctionne pas (une image qui plante). Ou OutOfSync et Healthy : elle fonctionne, mais pas avec la configuration voulue. Les deux questions sont distinctes, et c'est l'un des apports majeurs par rapport à l'agent de la leçon 1.

En pratique

Ce qui tourne

Après le script installer-labo.sh, le namespace argocd contient :

$ kubectl -n argocd get deploy,statefulset -o custom-columns='TYPE:.kind,NOM:.metadata.name,IMAGE:.spec.template.spec.containers[0].image'
TYPE          NOM                                IMAGE
Deployment    argocd-applicationset-controller   quay.io/argoproj/argocd:v3.5.3
Deployment    argocd-dex-server                  ghcr.io/dexidp/dex:v2.45.1
Deployment    argocd-notifications-controller    quay.io/argoproj/argocd:v3.5.3
Deployment    argocd-redis                       public.ecr.aws/docker/library/redis:8.2.3-alpine
Deployment    argocd-repo-server                 quay.io/argoproj/argocd:v3.5.3
Deployment    argocd-server                      quay.io/argoproj/argocd:v3.5.3
StatefulSet   argocd-application-controller      quay.io/argoproj/argocd:v3.5.3
$ kubectl -n argocd get networkpolicy -o name | wc -l
7

Cinq composants partagent la même image, argocd, qui démarre l'un ou l'autre selon sa commande. Le manifeste installe aussi sept politiques réseau, qui limitent par exemple l'accès à Redis et au repo-server aux seuls composants d'Argo CD, à condition que le plugin réseau du cluster les applique. Celui de kind (kindnet) embarque un moteur de politiques réseau, et un pod quelconque ne joint effectivement pas Redis :

$ kubectl -n argocd run essai-redis --rm -i --restart=Never --image=busybox:1.37 --quiet -- \
    sh -c 'nc -w 3 argocd-redis 6379 </dev/null && echo "redis joignable" || echo "redis injoignable"'
redis injoignable

Sur Kapsule, le plugin réseau des clusters de Lyneko est Cilium, qui applique lui aussi les politiques réseau.

Se connecter

L'API n'est pas exposée hors du cluster. Pour le laboratoire, un tunnel suffit :

$ kubectl -n argocd port-forward svc/argocd-server 8080:443 &

L'installation crée un compte admin et range son mot de passe initial, aléatoire, dans le secret argocd-initial-admin-secret. On se connecte, on change ce mot de passe, puis on supprime le secret, qui n'a plus de raison d'exister :

$ INIT=$(argocd admin initial-password -n argocd | head -1)
$ argocd login 127.0.0.1:8080 --username admin --password "$INIT" --insecure
'admin:login' logged in successfully
Context '127.0.0.1:8080' updated
$ openssl rand -base64 24 | tr -d '/+=' > argocd-admin.mdp
$ argocd account update-password --current-password "$INIT" --new-password "$(cat argocd-admin.mdp)"
Password updated
Context '127.0.0.1:8080' updated
$ kubectl -n argocd delete secret argocd-initial-admin-secret
secret "argocd-initial-admin-secret" deleted from argocd namespace
$ argocd account get-user-info
Logged In: true
Username: admin
Issuer: argocd
Groups:

--insecure accepte le certificat auto-signé que présente le serveur ; acceptable dans un tunnel local, jamais à travers un réseau. La ligne de commande enregistre le jeton de session dans un fichier de configuration, par défaut ~/.config/argocd/config ; l'option --config permet de le placer ailleurs (argocd --config ./argocd-config login ...), pour ne rien laisser dans le répertoire personnel.

L'interface web est disponible à la même adresse, https://127.0.0.1:8080. Le compte admin est commode pour démarrer ; en production, on le désactive au profit de l'authentification unique (leçon 9).

Le mode « core ». Pour une personne qui a déjà les droits sur le cluster, argocd login --core se passe complètement de l'API et du compte admin : la ligne de commande lit et écrit directement les ressources Kubernetes, avec les droits du kubeconfig.

$ kubectl config set-context --current --namespace=argocd
$ argocd login --core
Context 'kubernetes' updated
$ argocd app list   # capture faite plus loin dans la leçon, une fois l'application créée
NAME                         CLUSTER                         NAMESPACE             PROJECT  STATUS     HEALTH   SYNCPOLI
argocd/signalements-recette  https://kubernetes.default.svc  signalements-recette  default  OutOfSync  Healthy  Manual

C'est le mode à utiliser avec l'installation core-install.yaml.

Une première Application

Une Application est une ressource Kubernetes qui relie une source (un dépôt, une révision, un chemin) à une destination (un cluster, un namespace) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: signalements-recette
  namespace: argocd
spec:
  project: default
  source:
    repoURL: http://forgejo.forge.svc.cluster.local:3000/plateforme/signalements-deploiement.git
    targetRevision: main
    path: signalements
  destination:
    server: https://kubernetes.default.svc
    namespace: signalements-recette
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

• namespace: argocd : les Applications vivent dans le namespace d'Argo CD (la fonction « applications dans n'importe quel namespace » permet d'en placer ailleurs ; ce cours ne l'utilise pas).
• project: default : le projet qui fixe ce que l'application a le droit de faire. default autorise tout ; la leçon 9 le restreint.
• repoURL : l'adresse de la forge vue depuis le cluster. Le dépôt est public dans la forge, aucun identifiant n'est nécessaire ; pour un dépôt privé, on déclare ses identifiants dans un Secret étiqueté argocd.argoproj.io/secret-type: repository.
• targetRevision: main : la branche suivie. On peut aussi suivre une étiquette ou un commit précis.
• destination.server : https://kubernetes.default.svc désigne le cluster où tourne Argo CD lui-même.
• syncPolicy sans automated : la synchronisation est manuelle. C'est le bon choix pour un premier déploiement, comme pour l'adoption d'une application existante (leçon 10) : on regarde avant d'appliquer. CreateNamespace=true crée le namespace de destination s'il manque.

$ kubectl apply -f applications/signalements-recette.yaml
application.argoproj.io/signalements-recette created
$ argocd app get signalements-recette
...
Sync Status:        OutOfSync from main (a2160cb)
Health Status:      Missing

GROUP  KIND        NAMESPACE             NAME          STATUS     HEALTH   HOOK  MESSAGE
       Service     signalements-recette  signalements  OutOfSync  Missing
apps   Deployment  signalements-recette  signalements  OutOfSync  Missing

Argo CD a cloné le dépôt, rendu les deux manifestes du commit a2160cb, et constaté qu'aucun des deux objets n'existe : OutOfSync, Missing. Rien n'a encore été appliqué.

Regarder avant d'appliquer

$ argocd app diff signalements-recette

===== /Service signalements-recette/signalements ======
0a1,13
> apiVersion: v1
> kind: Service
> metadata:
>   annotations:
>     argocd.argoproj.io/tracking-id: signalements-recette:/Service:signalements-recette/signalements
>   name: signalements
>   namespace: signalements-recette
> spec:
>   ports:
>   - port: 80
>     targetPort: 8000
>   selector:
>     app: signalements

===== apps/Deployment signalements-recette/signalements ======
0a1,39
> apiVersion: apps/v1
> kind: Deployment
> metadata:
>   annotations:
>     argocd.argoproj.io/tracking-id: signalements-recette:apps/Deployment:signalements-recette/signalements
...

Deux détails ne viennent pas du dépôt. Le namespace a été ajouté à chaque objet, à partir de la destination. Et une annotation argocd.argoproj.io/tracking-id marque chaque objet comme appartenant à l'application signalements-recette. C'est la réponse à la première limite de l'agent de la leçon 1 : Argo CD sait quels objets il gère, et pourra donc élaguer ceux qui disparaissent de Git (leçon 3).

Synchroniser

$ argocd app sync signalements-recette
Name:               argocd/signalements-recette
Project:            default
Namespace:          signalements-recette
SyncWindow:         Sync Allowed
Sync Policy:        Manual
Sync Status:        Synced to main (a2160cb)
Health Status:      Progressing

Operation:          Sync
Sync Revision:      a2160cbbbf9c80f1dd938656ca291f866b18fbfd
Phase:              Succeeded
Start:              2026-10-02 09:17:49 +0200 CEST
Finished:           2026-10-02 09:17:49 +0200 CEST
Duration:           0s
Message:            successfully synced (all tasks run)

GROUP  KIND        NAMESPACE             NAME                  STATUS   HEALTH       HOOK  MESSAGE
       Namespace                         signalements-recette  Running  Synced             namespace/signalements-recette created
       Service     signalements-recette  signalements          Synced   Healthy            service/signalements created
apps   Deployment  signalements-recette  signalements          Synced   Progressing        deployment.apps/signalements created
$ argocd app wait signalements-recette --health --timeout 120
...
Sync Status:        Synced to main (a2160cb)
Health Status:      Healthy

La synchronisation a réussi en moins d'une seconde : elle n'a fait que créer les objets. Le Deployment est alors Progressing : ses pods démarrent. argocd app wait --health attend que l'application soit saine, ce qui en fait la bonne commande pour un script qui doit savoir si un déploiement a abouti. Signalements répond, dans sa version 1.1.0 :

$ kubectl -n signalements-recette run essai --rm -i --restart=Never --image=curlimages/curl:8.16.0 --quiet -- -s http://signalements/
{"application":"signalements","conteneur":"signalements-5b4c9cdf98-8hznx","environnement":"recette","stockage":"memoire","version":"1.1.0"}

Une modification dans Git

Passons à trois répliques, par un commit :

$ sed -i 's/replicas: 2/replicas: 3/' signalements/deployment.yaml
$ git commit -qam "Signalements : trois répliques" && git push -q origin main
$ argocd app get signalements-recette --refresh
...
Sync Status:        OutOfSync from main (1c8a9e2)
Health Status:      Healthy
apps   Deployment  signalements-recette  signalements          OutOfSync  Healthy        deployment.apps/signalements created

Sans --refresh, il aurait fallu attendre : Argo CD interroge chaque dépôt toutes les 120 secondes, plus un délai aléatoire d'au plus 60 secondes (pour ne pas interroger tous les dépôts au même instant), soit jusqu'à trois minutes. En production, on configure un webhook de la forge vers Argo CD, qui déclenche le rafraîchissement dès la poussée. L'application est maintenant OutOfSync (Git demande trois répliques) et Healthy (les deux répliques actuelles fonctionnent). On synchronise, puis on consulte l'historique :

$ argocd app sync signalements-recette
$ argocd app history signalements-recette
SOURCE  http://forgejo.forge.svc.cluster.local:3000/plateforme/signalements-deploiement.git
ID      DATE                            REVISION
0       2026-10-02 09:17:49 +0200 CEST  main (a2160cb)
1       2026-10-02 09:18:10 +0200 CEST  main (1c8a9e2)

Le retour arrière, et pourquoi il n'est pas du GitOps

Argo CD sait revenir à une synchronisation précédente :

$ argocd app rollback signalements-recette 0
...
Sync Status:        OutOfSync from main (1c8a9e2)
Health Status:      Healthy
Message:            successfully synced (all tasks run)
apps   Deployment  signalements-recette  signalements  OutOfSync  Healthy        deployment.apps/signalements configured
$ kubectl -n signalements-recette get deploy signalements -o jsonpath='répliques : {.spec.replicas}{"\n"}'
répliques : 2

Le cluster est revenu à deux répliques en quelques secondes. Mais l'application est désormais OutOfSync : Git dit toujours trois. Le retour arrière d'Argo CD réapplique une ancienne révision en s'écartant volontairement de la source, ce qui contredit le principe même du GitOps. C'est un geste d'urgence, utile pour revenir en arrière en quelques secondes pendant un incident, à condition de faire ensuite le vrai retour arrière dans Git :

$ git revert --no-edit HEAD && git push -q origin main
$ git log --oneline -1
6b3be97 Revert "Signalements : trois répliques"
$ argocd app get signalements-recette --refresh | grep "^Sync Status"
Sync Status:        Synced to main (6b3be97)

Ce n'est qu'après ce revert que Git et le cluster disent de nouveau la même chose : l'application est Synced sans qu'aucune synchronisation soit nécessaire, puisque le cluster était déjà à deux répliques. Pour la même raison, Argo CD refuse le retour arrière d'une application en synchronisation automatique : il serait annulé au passage suivant.

Sous le capot

La synchronisation suit trois étapes. Le repo-server clone le dépôt à la révision demandée (il garde un cache des clones), détecte le type de source (un répertoire de manifestes ici ; Helm s'il trouve un Chart.yaml ; Kustomize s'il trouve un kustomization.yaml), et rend les manifestes. Le contrôleur compare chaque objet rendu à l'objet réel, en normalisant les champs que Kubernetes remplit lui-même (valeurs par défaut, status, métadonnées techniques) pour ne pas voir d'écarts imaginaires. Puis, à la synchronisation, il applique les objets avec l'équivalent de kubectl apply, en y ajoutant l'annotation de suivi.

Le résultat du rendu est mis en cache dans Redis, par révision : tant que le dépôt ne change pas, le repo-server n'est pas sollicité. Le contrôleur, lui, reste informé de l'état réel en continu, par les mécanismes de surveillance (watch) de l'API Kubernetes : il n'a pas besoin d'interroger le cluster pour savoir qu'un objet a changé. C'est pourquoi un écart créé à la main est vu presque instantanément, alors qu'un commit attend le prochain rafraîchissement du dépôt.

La santé est calculée par type d'objet, avec des règles intégrées (pour un Deployment : la génération observée, les répliques à jour et disponibles) ou des scripts Lua pour les ressources personnalisées. La santé de l'application est la pire de celles de ses objets existants : depuis la 3.4, un objet absent ne compte plus, sauf si tous le sont (l'application est alors Missing).

Pièges courants

L'application reste OutOfSync après un commit... ou ne voit pas le commit. Le dépôt n'a pas encore été rafraîchi (jusqu'à trois minutes). argocd app get --refresh, ou un webhook.

ComparisonError et synchronisation Unknown. Le repo-server n'a pas pu cloner ou rendre : adresse du dépôt fausse vue depuis le cluster (l'adresse 127.0.0.1:3000 du poste n'existe pas dans un pod), identifiants manquants, chemin inexistant. Le message de l'application le dit.

argocd login répond x509: certificate signed by unknown authority. Le serveur présente un certificat auto-signé. --insecure dans un tunnel local ; en production, un vrai certificat sur l'ingress.

Le compte admin reste actif avec son mot de passe initial. Le secret argocd-initial-admin-secret contient un mot de passe valide tant qu'on ne l'a pas changé. Changez-le, puis supprimez le secret ; mieux, désactivez le compte une fois l'authentification unique en place.

L'interface ne répond plus après une mise à jour du nœud. Un redémarrage du nœud coupe les tunnels kubectl port-forward ; relancez-les. En production, l'interface passe par un ingress, pas par un tunnel.

argocd app rollback est refusé. L'application est en synchronisation automatique. Faites le retour arrière dans Git.

Sécurité

Les droits du contrôleur. L'installation standard donne au contrôleur d'application un rôle qui autorise toutes les actions sur toutes les ressources du cluster (apiGroups: ['*'], resources: ['*'], verbs: ['*']). Toute application peut donc, en principe, créer n'importe quoi, y compris modifier Argo CD lui-même ; ce sont les projets (leçon 9) qui restreignent ce que chacune peut faire, pas les droits du contrôleur.

Le compte admin. Partagé, il rend le journal d'audit anonyme : on sait que « admin » a supprimé une application, pas qui. Chez Lyneko, Argo CD s'authentifie directement auprès de Google, sans Dex ni compte partagé, et une personne sans rôle explicite n'obtient rien (leçon 9).

Le repo-server exécute du contenu externe. Rendre un chart Helm ou une configuration Kustomize, c'est exécuter des outils sur des fichiers venus des dépôts. Les politiques réseau livrées avec Argo CD l'isolent ; ne les supprimez pas, et ne donnez pas à ses pods plus de droits que nécessaire.

Les versions. Argo CD publie une version mineure par trimestre et ne corrige que les trois dernières (3.5, 3.4 et 3.3 au moment de l'écriture). Des failles sérieuses ont été corrigées récemment, par exemple CVE-2025-55190 (septembre 2025, gravité 9,9 : un jeton de projet pouvait révéler les identifiants des dépôts) ou CVE-2026-42880 (mai 2026, critique : extraction de secrets par un utilisateur en lecture seule via la comparaison côté serveur, versions 3.2.0 à 3.2.10 et 3.3.0 à 3.3.8). Restez sur la dernière version corrective d'une mineure maintenue.

En production

L'exposition. L'interface et l'API passent par un ingress avec un certificat valide, et l'authentification unique remplace le compte local. Chez Lyneko, argocd.lyneko.com est exposé par l'ingress destiné aux applications publiques, et c'est l'authentification OIDC d'Argo CD qui protège la page de connexion.

Le dimensionnement. Le repo-server consomme de la mémoire à chaque rendu de chart, et le contrôleur proportionnellement au nombre de ressources suivies. Sur un petit cluster, l'installation elle-même pèse : plusieurs centaines de méga-octets d'images et de mémoire. L'incident de Lyneko (leçon 10) en est l'illustration.

La haute disponibilité. Le manifeste ha multiplie les répliques et passe Redis en haute disponibilité, mais suppose au moins trois nœuds. Argo CD hors service ne coupe pas les applications, qui continuent de tourner : seuls les nouveaux déploiements attendent.

Gérer Argo CD avec Argo CD. Une fois installé, Argo CD peut suivre sa propre configuration (projets, dépôts, applications) dans un dépôt : c'est le motif de l'application racine, vu à la leçon 4.

Exercices

1. Pour chacune de ces situations, prévoyez les états de synchronisation et de santé de l'application : (a) l'image référencée dans Git n'existe pas ; (b) quelqu'un supprime à la main le Service ; (c) le dépôt est inaccessible depuis le cluster.

2. Modifiez à la main le nombre de répliques (kubectl scale ... --replicas=5), puis observez l'application dans Argo CD sans synchroniser. Que se passe-t-il, et pourquoi Argo CD ne corrige-t-il pas ?

3. Faites un retour arrière avec argocd app rollback, puis un argocd app sync. Qu'obtient-on ? Qu'en concluez-vous sur le bon ordre des gestes pendant un incident ?

4. Déclarez une seconde application, signalements-demo, qui déploie le même chemin dans le namespace signalements-demo. Que montre l'annotation tracking-id des objets des deux namespaces ?

5. Quelle variante d'installation choisiriez-vous pour (a) le cluster de production de Lyneko, à un seul nœud ; (b) une équipe qui n'a des droits que sur son namespace d'un cluster partagé ; (c) un cluster de périphérie sans interface, piloté par un outil d'automatisation ?

Récapitulatif

• Argo CD, c'est sept composants : le contrôleur (réconciliation), le repo-server (rendu des manifestes), le serveur (API, interface, authentification), Redis (cache), Dex (SSO, optionnel), et les contrôleurs d'ApplicationSet et de notifications. Tout l'état durable est dans des ressources Kubernetes.
• Changez le mot de passe admin initial et supprimez son secret ; en production, désactivez admin au profit de l'authentification unique.
• Une Application relie une source (dépôt, révision, chemin) à une destination (cluster, namespace).
• Synchronisation (Synced, OutOfSync, Unknown) et santé (Healthy, Progressing, Degraded, Suspended, Missing, Unknown) sont deux questions distinctes.
• Argo CD interroge les dépôts toutes les deux à trois minutes ; un webhook rend la détection immédiate.
• argocd app rollback est un geste d'urgence qui s'écarte de Git ; le vrai retour arrière est un git revert.

Pour aller plus loin

• Argo CD, Architectural Overview : le rôle exact de chaque composant.
• Argo CD, Resource Health : les règles de santé par type d'objet.
• Leçon suivante : L'Application en détail.