GitOps avec Argo CD

Argo CD est l'autre grand outil GitOps (projet diplômé de la CNCF). Mêmes principes que Flux (leçon D.4) : un dépôt Git décrit l'état voulu, un contrôleur dans le cluster le réconcilie. Sa différence la plus visible : une interface web qui montre chaque application, l'arbre de ses objets, leur santé et l'écart avec Git. Il est souvent choisi par les équipes qui veulent offrir une vue en libre-service aux développeurs. Cette leçon est théorique.

Ce que vous saurez à la fin : installer Argo CD, décrire une Application, choisir entre synchronisation manuelle et automatique (avec auto-réparation et suppression), lire les états Sync et Health, déployer plusieurs applications avec un ApplicationSet, et cloisonner les équipes avec les projets.

1. Installer

kubectl create namespace argocd
kubectl apply -n argocd --server-side -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d   # mot de passe initial d'admin
kubectl -n argocd port-forward svc/argocd-server 8080:443                                           # l'interface, sur https://localhost:8080

En production, on épingle une version précise (pas stable), on installe plutôt par le chart Helm officiel, on branche l'authentification de l'entreprise (OIDC) et on supprime le compte admin initial.

2. Une Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: {name: vitrine, namespace: argocd}
spec:
  project: default
  source:
    repoURL: https://github.com/mon-org/vitrine
    targetRevision: main
    path: deploy/prod                 # manifestes bruts, Kustomize ou chart Helm : détecté automatiquement
  destination:
    server: https://kubernetes.default.svc     # ce cluster ; Argo CD peut piloter d'autres clusters
    namespace: vitrine
  syncPolicy:
    automated:
      prune: true                     # supprimer ce qui a disparu de Git
      selfHeal: true                  # annuler les modifications manuelles
    syncOptions: [CreateNamespace=true]

Sans automated, Argo CD détecte les écarts et les affiche, mais attend qu'on clique sur Sync (ou argocd app sync vitrine). C'est un choix courant pour la production : la fusion dans Git déclenche une synchronisation validée par un humain.

3. Lire l'état d'une application

Statut	Valeurs	Signification
Sync	Synced, OutOfSync	le cluster correspond-il à Git ?
Health	Healthy, Progressing, Degraded, Missing	les objets fonctionnent-ils ? (Deployment disponible, pods prêts…)

Une application peut être Synced et Degraded : tout ce qui est dans Git est appliqué, mais la nouvelle version plante. Ou OutOfSync et Healthy : quelqu'un a modifié le cluster à la main, ou un commit attend sa synchronisation.

argocd app list
argocd app get vitrine            # objets, statuts, révision
argocd app diff vitrine           # l'écart exact entre Git et le cluster
argocd app history vitrine
argocd app rollback vitrine 3     # revenir à une synchronisation précédente (désactive l'automatique)

4. L'ordre de synchronisation

Les vagues (sync waves) ordonnent l'application des objets : annotation argocd.argoproj.io/sync-wave: "-1" pour une migration de base avant l'application, "1" pour ce qui vient après. Les hooks (argocd.argoproj.io/hook: PreSync) lancent un Job avant ou après la synchronisation, par exemple une migration de schéma.

5. Beaucoup d'applications : ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: {name: vitrine, namespace: argocd}
spec:
  generators:
    - list:
        elements:
          - {env: recette, cluster: https://recette.exemple.fr}
          - {env: prod,    cluster: https://prod.exemple.fr}
  template:
    metadata: {name: 'vitrine-{{env}}'}
    spec:
      project: default
      source: {repoURL: https://github.com/mon-org/vitrine, targetRevision: main, path: 'deploy/{{env}}'}
      destination: {server: '{{cluster}}', namespace: vitrine}

Un générateur produit une liste de paramètres (une liste, les clusters déclarés, les dossiers d'un dépôt, les demandes de fusion ouvertes…), et le modèle fabrique une Application par élément. Le motif « app of apps » (une Application qui déploie d'autres Applications) sert au même but.

6. Cloisonner : les projets

Un AppProject limite ce qu'une équipe peut déployer : dépôts sources autorisés, clusters et namespaces de destination, types d'objets permis (par exemple : pas de ClusterRole). Avec le RBAC d'Argo CD, l'équipe vitrine ne voit et ne synchronise que ses applications.

7. Flux ou Argo CD ?

	Flux	Argo CD
Interface	ligne de commande, tableaux de bord tiers	interface web complète
Modèle	ensemble de contrôleurs et de CRD, tout en YAML	serveur, contrôleur d'applications, interface
Multi-cluster	un Flux par cluster, en général	un Argo CD peut piloter plusieurs clusters
Automatisation d'images	intégrée	module séparé (Argo CD Image Updater)

Les deux sont solides et largement adoptés. Le choix tient surtout à l'organisation : libre-service visuel pour de nombreuses équipes (Argo CD), ou approche légère, entièrement déclarative, cluster par cluster (Flux).

Validez la leçon avec le questionnaire.