Module 4e · Packaging & GitOps (Helm, ArgoCD)¶

Objectifs

Helm : déployer une app packagée et paramétrable.
Comprendre le principe GitOps : Git = source de vérité, le cluster se synchronise.
Installer ArgoCD et déployer une app depuis un dépôt Git.
Observer drift, sync et self-heal en direct, le tout via k9s.
Durée : ~1 h 30 · Pré-requis : Module 4d.

Helm : packager une app¶

Helm = le « apt/npm » de Kubernetes : des charts paramétrables par un fichier values.yaml. Plutôt que d'écrire chaque manifeste à la main, on installe un chart existant et on l'ajuste.

graph LR
    C[Chart<br/>templates à trous] --> H{helm}
    V[values.yaml<br/>tes paramètres] --> H
    H -->|rend| M[manifestes k8s] --> O[objets dans le cluster]

Un chart est un patron à trous ; le values.yaml bouche les trous (nb de réplicas, image, domaine…). Helm rend les manifestes finaux et les applique. Même chart, values différentes = la même app en dev et en prod, sans copier-coller de YAML.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install monsite bitnami/nginx
helm list
helm upgrade monsite bitnami/nginx --set replicaCount=3
helm uninstall monsite

Exercice 4e.1 - Déployer via Helm

Installe un chart simple, observe les objets créés dans k9s (:deploy, :svc, :cm), puis fais un helm upgrade et regarde le rolling update se déclencher.

Helm et GitOps se complètent

En GitOps, on ne lance pas helm install à la main : on référence le chart depuis Git et ArgoCD l'installe. Helm package, GitOps déploie - d'où leur place dans le même module.

GitOps en une idée¶

Au lieu de kubectl apply à la main, on décrit l'état désiré dans Git. Un opérateur (ArgoCD) compare en continu Git ↔ cluster et réconcilie.

graph LR
    Dev[Commit dans Git] --> Repo[(Dépôt Git)]
    Repo -->|surveille| Argo[ArgoCD]
    Argo -->|applique / réconcilie| K8s[(Cluster)]
    K8s -->|état réel| Argo

Avantage	Concrètement
Traçabilité	tout changement = un commit (qui, quoi, quand)
Rollback	`git revert` → l'état précédent revient
Cohérence	le cluster ne dérive pas : ArgoCD corrige (self-heal)
Revue	les changements passent par une PR

Installer ArgoCD¶

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd rollout status deploy/argocd-server

Mot de passe admin initial :

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d; echo

Accès à l'UI (port-forward - ou via k9s, touche Shift-f sur le pod argocd-server) :

kubectl -n argocd port-forward svc/argocd-server 8080:443
# puis https://localhost:8080  (user: admin)

Dans k9s

:ns → argocd, observe les pods se créer. Sur argocd-server, Shift-f pour le port-forward sans quitter le terminal.

Déclarer une application¶

Une Application ArgoCD dit : « surveille ce dépôt/ce chemin et applique-le dans ce namespace ».

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps
    path: guestbook
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: demo
  syncPolicy:
    automated:
      prune: true        # supprime ce qui n'est plus dans Git
      selfHeal: true     # corrige toute modif manuelle (drift)
    syncOptions:
      - CreateNamespace=true

kubectl apply -f application.yaml
kubectl -n argocd get applications

Drift & self-heal (le moment magique)¶

Avec selfHeal: true, modifie une ressource à la main et regarde ArgoCD la remettre comme dans Git :

kubectl -n demo scale deploy/guestbook-ui --replicas 5    # drift volontaire
# ArgoCD détecte l'écart et ramène au nombre déclaré dans Git

Refais-le avec l'édition à chaud du module 3 (e dans k9s, kubectl edit) : ton edit tient quelques secondes, puis ArgoCD le rebat. Le geste de dépannage appris là-bas devient ici un anti-pattern : sur un cluster GitOps, la correction passe par Git.

Sans selfHeal, l'app passe simplement OutOfSync : ArgoCD signale l'écart mais ne corrige qu'au prochain Sync manuel.

Ce pattern, tu l'as sous les yeux

Demande au mentor de te montrer comment cette plateforme elle-même est déployée - la démo vaut le détour.

Pratique¶

Le TP de ce module reproduit la boucle GitOps sans installer ArgoCD, dans ta sandbox - une fois la lecture faite :

tp start 03e-gitops   # état désiré → drift (kubectl diff = OutOfSync) → réconciliation
tp start ancrage-4e   # en autonomie ensuite : double drift (scale + objet supprimé)

fais la manip puis tp check (ou tp watch pour l'auto-validation) · tp hint / tp solution si tu bloques.

Pour t'entraîner librement à côté :

Exercice 4e.2 - Première app GitOps

Installe ArgoCD, récupère le mot de passe, ouvre l'UI.
Déploie l'Application guestbook ci-dessus. Observe la synchro dans l'UI et dans k9s.

(ArgoCD, c'est ~7 pods : ta sandbox vit sous quota - si des pods restent Pending, fais cette partie en démo avec le mentor ; le TP 03e-gitops couvre la boucle GitOps sans rien installer.)

Exercice 4e.3 - Self-heal

Avec selfHeal: true, scale le deployment à la main (replicas=5).
Observe ArgoCD revenir à l'état Git. Combien de temps ? Que dit l'UI (Synced/OutOfSync) ?
Refais l'expérience sans selfHeal : l'app reste OutOfSync jusqu'à un Sync manuel.

Ce qu'il faut retenir¶

Helm package une app (charts + values.yaml) ; install / upgrade / uninstall.
GitOps : Git = source de vérité, un opérateur réconcilie cluster ↔ Git.
automated.prune supprime l'obsolète ; selfHeal corrige le drift automatiquement.
OutOfSync = écart détecté ; Synced = cluster conforme à Git.
Rollback = git revert. Traçabilité = l'historique Git.

Quiz éclair¶

Teste-toi : réponds de tête, puis déplie.

1. Que signifient OutOfSync et Synced ?

OutOfSync = ArgoCD a détecté un écart entre Git et le cluster. Synced = le cluster est conforme à ce qui est décrit dans Git.

2. Différence entre prune et selfHeal ?

prune supprime ce qui n'est plus dans Git. selfHeal corrige le drift : il remet automatiquement toute modif manuelle à l'état déclaré.

3. Comment fait-on un rollback en GitOps ?

Par git revert : on revient à l'état précédent dans Git, et l'opérateur le réapplique. L'historique Git est l'historique des déploiements.

➡️ Suite : Module 5 - Cloud provider (AWS EKS)