Un setup Argo CD pragmatique — du GitOps qui survit au contact de la réalité

Argo CD est l'un de ces projets follement populaires et follement mal déployés. Chaque équipe avec laquelle je travaille a une certaine version d'Argo CD en marche. Peut-être un tiers d'entre elles l'ont configuré d'une manière qui leur économise réellement du travail au lieu d'être une version pire de kubectl apply avec du YAML en plus.

La différence est généralement à trois endroits : structure du repo, orchestration des sync waves, et la manière dont vous gérez les secrets.

La disposition de repo App-of-Apps

gitops-repo/
├── bootstrap/                  # root app-of-apps
├── platform/                   # infra cluster-wide (ingress, cert-manager, …)
├── tenants/
│   ├── team-payments/{dev,staging,prod}/
│   └── team-search/{dev,staging,prod}/
└── projects/                   # frontières RBAC AppProject

Une seule Application racine amorce le cluster. platform/ est possédé par l'équipe plateforme. Chaque tenant a son propre dossier par environnement, donc la promotion est une PR qui copie les manifestes d'un répertoire à l'autre.

L'article complet couvre :

• Les sync waves — la convention de numérotation que nous utilisons sur chaque cluster
• Pourquoi nous utilisons External Secrets Operator + un vault, pas sealed-secrets (rotation)
• Auto-sync pour dev/staging, sync manuel pour prod (et pourquoi)
• ApplicationSet pour les patterns flotte-d'environnements
• Notifications : les alertes Slack qui comptent vraiment
• Sauvegarder Argo CD et les leçons de la fois où nous ne l'avons pas fait

Nous livrons cette disposition sur chaque cluster Kubernetes managé.