Argo CD GitOps : déploiement continu Kubernetes

À la fin de ce tutoriel, vous maîtriserez Argo CD pour un déploiement continu GitOps : déclarer une Application, borner les droits avec un AppProject, générer des apps via ApplicationSet, activer auto-sync / selfHeal / prune avec discernement, et ancrer le lab en ca-central-1.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Argo CD stable (manifests officiels) · Kubernetes 1.31+ · Git (HTTPS/SSH) · AWS CLI v2 (lab) · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-argo-cd-gitops · Série : WOW (3/50) · Mot-clé SEO : argo cd gitops · Publish : prêt (feu vert Maître)

← : Backstage IDP · → : Flux vs Argo · Lab P3

Prérequis

• Cluster lab Kubernetes 1.31+ (kubectl admin) — kubeadm ou kind/minikube
• Bases Helm utiles — Helm Kubernetes
• Install / sync de base déjà vus : GitOps avec ArgoCD (P3)
• Dépôt Git public ou privé avec manifests (Deployment + Service) ou chart Helm
• Compte AWS lab optionnel (tags / EKS) — profil lab

Coût estimé : 0 € en kind/minikube ; quelques cents si vous pointez un EKS déjà existant en ca-central-1 (ne créez pas un cluster « pour tester GitOps »).

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity 2>/dev/null || true
kubectl version --client
kubectl get nodes

Ce que nous allons construire

GitOps CD Argo CD (WOW 3/50) — ca-central-1
  ├── Rappel : Git = source of truth, CI build, CD sync
  ├── Application déclarative (repo + path + destination)
  ├── AppProject least-privilege (repos / ns / kinds)
  ├── ApplicationSet (list / git generator) multi-env
  ├── Auto-sync + selfHeal + prune (stratégie progressive)
  ├── Sync waves / hooks (ordre migrations)
  ├── Lab : guestbook (ou app DEH) Synced/Healthy
  └── FAQ + quiz + maillage WOW / K8s / CI

(Schéma — alt : « Pipeline CI pousse une image ; Git décrit l’état désiré ; Argo CD synchronise le cluster Kubernetes en ca-central-1 ».)

Étape 1 — Pourquoi Argo CD pour le CD en 2026 ?

Le CI (Jenkins, GitHub Actions, GitLab CI) build, teste et pousse une image. Le CD GitOps applique l’état déclaré dans Git au cluster. Argo CD est le contrôleur qui compare desired (Git) et live (API Kubernetes), puis synchronise.

Avantages concrets :

1. Audit : chaque changement = commit / PR
2. Rollback = git revert + sync (pas de kubectl sauvage en prod)
3. Drift detection : un patch manuel devient visible (et optionnellement guéri)
4. Multi-env : folders ou ApplicationSets plutôt que 40 jobs « deploy-prod »

Concept	Rôle
Application	CR : repo + path + revision → cluster/namespace
AppProject	Garde-fous (repos, destinations, kinds autorisés)
ApplicationSet	Génère des Applications (list, git, cluster…)
Sync	Appliquer Git → cluster
Refresh	Re-lire Git / recalculer le desired state
Health	Healthy, Progressing, Degraded…
Self-heal	Resync si drift manuel
Prune	Supprimer les objets absents de Git

Angle DEH : CI ne doit pas faire kubectl apply en prod. CI écrit Git (image tag / values) ; Argo CD déploie. Region workloads AWS : ca-central-1.

Étape 2 — Installer Argo CD (rappel lab)

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd wait --for=condition=Ready pods --all --timeout=300s

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

kubectl port-forward svc/argocd-server -n argocd 8080:443
# UI : https://127.0.0.1:8080  (admin + mot de passe Secret)

Attendu : pods argocd-server, repo-server, application-controller, redis Ready. En lab mono-nœud, prévoyez ~512 Mo–1 Go pour le namespace argocd.

Install détaillée : argocd-gitops-kubernetes. Ici : modèle CD (projets, sets, policies).

Étape 3 — Application déclarative (Git → namespace)

Créez le namespace cible et une Application versionnée (idéalement dans un repo « gitops » séparé du code app).

# apps/demo-payments.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-payments-nonprod
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: demo-gitops
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

kubectl apply -f apps/demo-payments.yaml
kubectl -n argocd get application demo-payments-nonprod
# Puis Sync depuis UI ou :
# argocd app sync demo-payments-nonprod

Attendu : statut Synced / Healthy ; objets dans demo-gitops. Tags / labels applicatifs : Owner, Service, Env=nonprod, Region=ca-central-1 (si manifests DEH).

Règle d’or : l’image tag change via commit Git (Kustomize image, Helm values), jamais un kubectl set image oublié.

Étape 4 — AppProject : least-privilege dès le jour 1

Le projet default est trop large pour une plateforme réelle. Bornez repos, namespaces et kinds.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-payments
  namespace: argocd
spec:
  description: Equipe payments — nonprod
  source repos:
    - 'https://github.com/org/payments-gitops.git'
  destinations:
    - namespace: 'payments-*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap
    - group: 'networking.k8s.io'
      kind: Ingress
  orphanedResources:
    warn: true

Puis pointez spec.project: team-payments dans l’Application. Interdisez ClusterRole / CRDs aux équipes app sauf projet plateforme. C’est le même esprit que les guardrails IDP — Platform Engineering.

Étape 5 — ApplicationSet : multi-env sans copier-coller

Hand-écrire une Application par service × env ne scale pas. Un ApplicationSet génère les Applications.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payments-envs
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - env: nonprod
            path: overlays/nonprod
          - env: prod
            path: overlays/prod
  template:
    metadata:
      name: 'payments-{{env}}'
    spec:
      project: team-payments
      source:
        repoURL: https://github.com/org/payments-gitops.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: 'payments-{{env}}'
      syncPolicy:
        syncOptions:
          - CreateNamespace=true

Lab : list + 1–2 envs. Generators Git/Cluster pour les flottes. Prod gated ; nonprod auto-sync OK.

Étape 6 — Auto-sync, selfHeal, prune (stratégie)

syncPolicy:
  automated:
    prune: true
    selfHeal: true
    allowEmpty: false
  syncOptions:
    - CreateNamespace=true
    - PruneLast=true
  retry:
    limit: 5
    backoff:
      duration: 5s
      factor: 2
      maxDuration: 3m

Option	Effet	Conseil DEH
automated	Sync dès OutOfSync	nonprod d’abord
selfHeal	Annule drift kubectl	activer quand l’équipe est formée
prune	Supprime objets hors Git	+ PruneLast ; protéger ressources partagées
allowEmpty	Sync repo vide	false en prod

Sync waves : annotation argocd.argoproj.io/sync-wave: "-1" sur migrations / CRDs, 0 sur workloads. Hooks PreSync pour Jobs de migration schéma — si le hook échoue, le Deployment ne part pas.

Secrets : jamais en clair dans Git. SOPS+age, Vault, ou External Secrets — pages WOW sœurs. CI OIDC vers AWS ca-central-1 pour build/push ECR ; Argo CD consomme le tag déjà dans Git.

Étape 7 — Check-list validation lab

1. Namespace argocd : pods Ready
2. AppProject team-payments (ou lab) appliqué
3. Application (ou ApplicationSet) Synced / Healthy
4. Objets dans le namespace destination ; CreateNamespace OK
5. Test drift (option) : patch un label → selfHeal le restaure
6. Tags / labels Owner, Service, Env, region ca-central-1 documentés
7. Cleanup prévu (voir ci-dessous)

kubectl -n argocd get applications
kubectl -n demo-gitops get all
kubectl -n argocd get appprojects

Nettoyage lab

kubectl -n argocd delete application demo-payments-nonprod --ignore-not-found
kubectl -n argocd delete applicationset payments-envs --ignore-not-found
kubectl delete namespace demo-gitops --ignore-not-found
# Option : désinstaller Argo CD (lab jetable uniquement)
# kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# kubectl delete namespace argocd --ignore-not-found

Erreurs fréquentes

Symptôme	Cause	Correction
Sync échoue permissions	Projet trop strict / RBAC	Ajuster whitelist ; vérifier SA Argo
Namespace manquant	Oubli CreateNamespace	syncOptions: CreateNamespace=true
Drift permanent	selfHeal off + patch manuel	Revenir à Git ou activer selfHeal
Prune trop agressif	Ressource partagée dans l’app	Annotation exclude / projet dédié
ApplicationSet écrase edits	Patch du child	Modifier le template / generator
Secrets dans Git	Anti-pattern	SOPS / ESO / Vault
kubectl apply en CI prod	Contourne GitOps	CI → commit image tag ; Argo sync

FAQ

Argo CD remplace-t-il Jenkins / GitHub Actions ?

Non. Le CI build & test ; Argo CD déploie depuis Git. Voir Jenkins pour le pipeline as code.

App of Apps ou ApplicationSet ?

App of Apps = une Application racine qui pointe vers des manifests Application. ApplicationSet = génération dynamique. Commencez simple (1–2 Applications), passez aux Sets dès multi-env / multi-cluster.

Auto-sync en production ?

Souvent manuel ou gated en prod, auto en nonprod. Activez selfHeal quand le contrat « Git only » est accepté par l’équipe.

Pourquoi parler de ca-central-1 ?

Convention DEH pour les labs AWS (EKS/ECR/tags). Même sur kind local, documentez la region cible des workloads cloud pour éviter le défaut us-east-1.

Argo CD vs Flux CD ?

Les deux sont GitOps CNCF. Argo : UI riche, Application CR, ApplicationSets. Flux : approche toolkit / controllers. Comparaison dédiée : wow-flux-cd-gitops.

Quiz (3 questions)

1. En GitOps Argo CD, où vit l’état désiré ?
– A. Uniquement dans Slack
– B. Dans Git, référencé par l’Application
– C. Seulement en mémoire du pod serveur

2. Un AppProject sert surtout à :
– A. Remplacer Helm
– B. Limiter repos, destinations et kinds (tenancy)
– C. Builder des images Docker

3. La région lab DEH pour les workloads AWS est :
– A. us-east-1
– B. ca-central-1
– C. eu-central-1

Réponses : 1‑B · 2‑B · 3‑B

Points clés à retenir

• Git = source of truth ; Argo CD réconcilie le cluster en continu.
• Application lie repo/path → destination ; AppProject borne les droits.
• ApplicationSet scale multi-env sans YAML dupliqué.
• Auto-sync / selfHeal / prune : progressifs (nonprod → prod gated).
• CI build, GitOps deploy — pas de kubectl apply prod depuis le CI.
• Labs DEH : tags + region ca-central-1 ; secrets hors Git.

Pour aller plus loin

• Docs Argo CD : Applications, AppProjects, ApplicationSets, sync waves, notifications
• Progressive delivery : Argo Rollouts · Secrets : SOPS / Vault / ESO · IDP : Backstage

Maillage série WOW / Kubernetes

← WOW	Platform Engineering · Backstage IDP
→ WOW	Flux CD vs Argo · Crossplane AWS
Lab P3	ArgoCD GitOps Kubernetes · Helm
Hubs	Kubernetes · Docker · Jenkins

---

Meta publication (Rank Math / SEO)

• Title SEO : Argo CD GitOps : déploiement continu Kubernetes 2026
• Meta description (≤ 155) : Argo CD GitOps : Application, AppProject, ApplicationSet, auto-sync. Lab FR ca-central-1 — déploiement continu Kubernetes 2026.
• Slug : wow-argo-cd-gitops · URL : https://devopelastichayway.com/tutoriels/wow-argo-cd-gitops/
• Image : réutiliser cover-argocd-gitops-kubernetes-1200x630.webp si besoin cover
• Catégorie : Kubernetes / DevOps · Niveau : Intermédiaire · Série : WOW 3/50
• KW principal : argo cd gitops · Secondaires : gitops kubernetes, application argo cd, applicationset, déploiement continu
• Parent WP : tutoriels (5463) · Statut : publish via wow-build-publish.py (feu vert Maître)