Skip to content

ADR 013 — GitOps avec ArgoCD : pull-based vs push-based (2026-06-11)

Statut

Accepté (2026-06-11). Issue #72.

Contexte

Le déploiement sur EKS était push-based : le job deploy de la CI faisait kubectl apply -k k8s/base/ directement sur le cluster (manuel, DEPLOY=true). Limites de cette approche :

  • Pas de source de vĂ©ritĂ© unique : l'Ă©tat rĂ©el du cluster pouvait diverger de Git sans que rien ne le dĂ©tecte (drift). Un kubectl edit manuel n'Ă©tait jamais rĂ©conciliĂ©.
  • Credentials cluster dans la CI : le runner dĂ©tient un accĂšs kubectl au cluster (kubeconfig gĂ©nĂ©rĂ© via aws eks update-kubeconfig). Surface d'attaque Ă©largie (le runner self-hosted est dĂ©jĂ  un SPOF, cf. #35).
  • DĂ©ploiement impĂ©ratif : kubectl apply ne supprime pas les ressources retirĂ©es de k8s/base/ (pas de prune natif), l'Ă©tat dĂ©rive au fil des releases.
  • GitOps Ă©tait annoncĂ© dans le README depuis le Sprint 3 (« GitLab Agent for Kubernetes ») mais jamais livrĂ©.

DĂ©cision 1 — ArgoCD plutĂŽt que GitLab Agent

Le plan initial (README Sprint 3) prévoyait le GitLab Agent for Kubernetes. On retient ArgoCD à la place :

CritĂšre ArgoCD GitLab Agent
Adoption marchĂ© Standard de facto CNCF (incubating→graduated) SpĂ©cifique GitLab
UI Riche (arbre de ressources, diff, sync, health) Limitée
Visibilité entretiens Forte (compétence demandée) Faible
Découplage du forge Agnostique (lit n'importe quel repo Git) Couplé GitLab
Multi-cluster / app-of-apps Natif Moins mature

La visibilitĂ© en entretien et la portabilitĂ© (mĂȘme outil sur EKS, homelab, platform) priment. DĂ©viation assumĂ©e par rapport au README initial.

DĂ©cision 2 — Pull-based avec write-back CI

Le flux devient pull-based : ArgoCD réconcilie le cluster depuis Git, la CI n'accÚde plus au cluster.

1. commit applicatif sur develop
2. pipeline : build image :SHA → scan → promote (inchangĂ©)
3. job update-image-tag : kustomize edit set image fastapi=$IMAGE_SHA
   → commit "ci: bump ... [skip ci]" → push sur develop
4. ArgoCD dĂ©tecte le commit → sync → rollout

Le tag d'image est désormais commité dans k8s/base/kustomization.yaml (champ images:), versionné dans Git. ArgoCD déploie exactement ce que contient Git : Git devient la source de vérité unique.

Le job deploy (kubectl apply) est supprimé. La CI ne détient plus de kubeconfig, ne fait plus d'accÚs cluster au déploiement.

DĂ©cision 3 — App-of-apps

L'installation et la configuration ArgoCD sont posĂ©es par le bootstrap Ansible (MR !145, #72). Un root Application (apps) surveille k8s/platform/argocd-apps/ et gĂšre les Application CRs qui s'y trouvent (dont fastapi → k8s/base/). Ajouter une future Application (observabilitĂ© #74) = dĂ©poser un fichier dans ce rĂ©pertoire, ArgoCD le dĂ©couvre. Pattern app-of-apps.

automated.prune: true + selfHeal: true : ArgoCD supprime ce qui disparaßt de Git (résout le manque de prune du kubectl apply) et corrige tout drift manuel.

Le piĂšge de la boucle CI

Le job update-image-tag pousse un commit sur develop. Sans prĂ©caution, ce commit relancerait un pipeline, qui re-bumperait, qui re-pousserait → boucle infinie. Le message de commit contient [skip ci] : GitLab n'instancie alors aucun pipeline pour ce commit. La chaĂźne s'arrĂȘte aprĂšs un seul write-back.

Conséquences

  • Token de push : le job pousse sur develop (branche protĂ©gĂ©e). NĂ©cessite un Project Access Token (rĂŽle Maintainer, scope write_repository) en variable CI masquĂ©e GITLAB_PUSH_TOKEN, autorisĂ© en push sur la rĂšgle de protection de develop. Le CI_JOB_TOKEN par dĂ©faut ne peut pas pousser.
  • Infra down : si le cluster est Ă©teint (Ă©phĂ©mĂšre), le write-back Ă©crit quand mĂȘme le tag dans Git. Au prochain aws-start, ArgoCD rĂ©concilie le dernier tag prĂ©sent dans Git. Git reste la source de vĂ©ritĂ©, la convergence est diffĂ©rĂ©e.
  • Deux commits par release : le commit applicatif + le commit de bump [skip ci]. Fonctionnement nominal du write-back GitOps.
  • Teardown : les Applications ArgoCD doivent ĂȘtre supprimĂ©es en premier (le selfHeal recrĂ©erait l'HTTPRoute, donc l'ELB → orphelin bloquant terraform destroy, classe INC-016). GĂ©rĂ© dans teardown.yml (MR !145).

Évolution possible

  • Image Updater ArgoCD : automatiserait le bump de tag sans job CI (ArgoCD scrute l'ECR). ÉcartĂ© pour l'instant : le write-back CI garde la trace du tag dans Git (auditabilitĂ©) et Ă©vite de donner Ă  ArgoCD un accĂšs ECR.
  • Sync waves / hooks : ordonnancement fin des ressources si besoin (migrations Alembic avant rollout). Pas nĂ©cessaire au pĂ©rimĂštre actuel.

Date : 2026-06-11 Sprint : 4 Issue : #72