TP19 : GitOps avec Argo CD (synchronisation, self-healing, ApplicationSet, promotion)

Le GitOps applique les pratiques de Git aux opérations : l’état désiré du cluster est déclaré dans un dépôt Git, qui devient la source de vérité. Un agent installé dans le cluster (ici Argo CD) compare en permanence Git et le cluster, et les réconcilie. On ne fait plus de kubectl apply à la main : on fait une Pull Request. Chaque changement est relu, tracé, et réversible par un git revert.

Fichiers de départ : gitops-starter.zip

1. Objectifs pédagogiques

À l’issue du TP, vous serez capable de :

• énoncer les quatre principes GitOps (OpenGitOps) : déclaratif, versionné, tiré (pull), réconcilié en continu ;
• installer Argo CD et déployer une application depuis un dépôt Git (UI et CLI) ;
• configurer la synchronisation automatique, le prune et le self-healing ;
• revenir en arrière par Git (git revert) et par Argo CD (history and rollback) ;
• générer une Application par environnement avec un ApplicationSet ;
• promouvoir une version de dev vers staging puis prod sans reconstruire l’image.

Les images de cette page sont des schémas explicatifs, pas des captures d’écran.

2. Environnement du TP

• Le cluster K3s du TP14 (≥ 2 Go de RAM libres), kubectl, Kustomize (TP15).

• Un dépôt GitHub public tp19-gitops contenant le dossier gitops-starter/ (à la racine du dépôt) :

  cp -r gitops-starter ~/tp19-gitops && cd ~/tp19-gitops
  sed -i 's/TODO-utilisateur/<votre-utilisateur>/' argocd/*.yaml
  git init -b main && git add . && git commit -m "feat: dépôt GitOps initial"
  git remote add origin [email protected]:<votre-utilisateur>/tp19-gitops.git && git push -u origin main

  Argo CD tire les changements depuis GitHub : aucun webhook ni port entrant vers la VM n’est nécessaire.

3. Partie 1 : Installer Argo CD

• Installer Argo CD et récupérer le mot de passe initial :

  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 rollout status deploy/argocd-server
  kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d; echo
  kubectl -n argocd port-forward svc/argocd-server 8443:443 --address 0.0.0.0 &

• Ouvrir https://<IP-VM-lab>:8443 (certificat autosigné), se connecter en admin, puis changer le mot de passe.

• Installer le CLI argocd (releases) et se connecter : argocd login localhost:8443 --insecure.

4. Partie 2 : Première Application

• Appliquer argocd/application-dev.yaml (sans synchronisation automatique) :

  kubectl apply -f argocd/application-dev.yaml
  argocd app get whoami-dev             # OutOfSync / Missing
  argocd app diff whoami-dev
  argocd app sync whoami-dev
  kubectl -n whoami-dev get all

• Explorer l’UI : arbre des ressources, diff, événements, logs d’un Pod.

5. Partie 3 : Synchronisation automatique, prune et self-healing

• Ajouter dans l’Application :

  syncPolicy:
    automated:
      prune: true
      selfHeal: true

• Changement par Git : passer replicas à 2 dans envs/dev, commiter, pousser. Argo CD vérifie le dépôt toutes les 3 minutes ; forcer la vérification avec argocd app get whoami-dev --refresh.

• Dérive : kubectl -n whoami-dev scale deploy whoami --replicas=5, puis observer le retour à 2 replicas (self-heal).

• Prune : supprimer service.yaml de la base (et de kustomization.yaml), pousser : le Service disparaît du cluster. Le remettre.

• Rollback par Git : pousser un tag d’image inexistant (v9.9.9), constater l’état Degraded, puis git revert HEAD && git push.

  Le rollback par l’UI (History and rollback) est impossible tant que automated est actif : Argo CD remettrait aussitôt l’état de Git. En GitOps, on corrige dans Git.

6. Partie 4 : ApplicationSet et environnements

• Supprimer l’Application whoami-dev (argocd app delete whoami-dev --cascade=false pour garder les ressources), puis appliquer argocd/applicationset.yaml.

• Vérifier que trois Applications whoami-dev, whoami-staging, whoami-prod sont générées, chacune dans son namespace, avec ses propres replicas et sa propre version :

  argocd app list
  kubectl get deploy -A --field-selector metadata.name=whoami -o custom-columns=NS:.metadata.namespace,REPLICAS:.spec.replicas,IMAGE:.spec.template.spec.containers[0].image

• Décider quels environnements sont synchronisés automatiquement. Une approche courante : automated pour dev et staging, synchronisation manuelle (ou fenêtre de synchronisation) pour la prod. Comment l’exprimer dans un ApplicationSet (templatePatch, ou un générateur list avec un paramètre par environnement) ?

7. Partie 5 : Promotion sans reconstruction

• Promouvoir v1.10.1 de dev vers staging par Pull Request :

  git switch -c promote/staging-v1.10.1
  (cd envs/staging && kustomize edit set image traefik/whoami:v1.10.1)   # ou modification manuelle
  git commit -am "chore(staging): promotion whoami v1.10.1" && git push -u origin HEAD
  # ouvrir la PR sur GitHub, la relire, la merger

• Après le merge, vérifier que staging tourne exactement la même image que dev (comparer les digests : kubectl get pod -o jsonpath='{..imageID}').

• Promouvoir vers prod de la même façon, puis synchroniser la prod (manuellement si elle n’est pas automatique).

• Protéger main (ruleset : PR obligatoire, 1 approbation). Expliquer pourquoi la revue de la PR devient la revue du changement en production.

Défi

1. Installer Argo CD Image Updater pour que dev suive automatiquement le dernier tag v1.10.* publié, en écrivant le changement dans Git (write-back).
2. Faire déployer le chart Helm du TP15 par une Application Argo CD (source.helm.valueFiles) et comparer avec l’approche Kustomize.
3. Multi-cluster : créer un second cluster K3s mono-nœud (une VM Vagrant de plus), l’enregistrer avec argocd cluster add, puis remplacer le générateur git par un générateur matrix (clusters × git) pour déployer dev sur les deux clusters. Lire la présentation de Karmada et comparer son approche (propagation de ressources par un plan de contrôle fédéré) avec celle d’Argo CD.

8. Livrables

Captures à déposer dans captures/ :

Ainsi que le dépôt tp19-gitops (lien) avec son historique de commits.