ArgoCD qui se manage lui-même, le peak GitOps

Tu installes ArgoCD avec Helm. Tu utilises ArgoCD pour déployer tout le reste. Mais qui déploie ArgoCD?

Toi. Manuellement. Comme un paysan

Il y a mieux. Fais en sorte qu’ArgoCD se manage lui-même. Tu push un changement dans tes values Helm ArgoCD, et ArgoCD le détecte, fait le diff, et s’upgrade tout seul. Full GitOps. Pas de kubectl apply. Pas de commandes Helm upgrade

La question existentielle

Est-ce qu’ArgoCD peut supprimer et recréer ses propres pods pendant qu’il traite un sync? Qu’est-ce qui se passe quand le pod controller redémarre en pleine réconciliation?

En fait: rien de grave. ArgoCD est conçu pour ça. L’état du sync est stocké dans les ressources Kubernetes, pas en mémoire. Quand les pods redémarrent, ils reprennent là où ils en étaient. J’ai regardé ArgoCD tuer son propre pod controller et revenir 10 secondes plus tard pour finir le sync

C’est comme un chirurgien qui s’opère lui-même, sauf que là ça marche vraiment

Le setup

Crée une Application qui pointe vers ArgoCD lui-même:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://argoproj.github.io/argo-helm
    chart: argo-cd
    targetRevision: 7.7.5
    helm:
      valuesObject:
        configs:
          params:
            server.insecure: false
        server:
          replicas: 2
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

C’est tout. ArgoCD surveille maintenant son propre chart Helm. Change la version, change une value, push sur git. ArgoCD se sync lui-même

L’œuf et la poule

Comment tu crées cette Application si ArgoCD n’existe pas encore?

Option 1: Installe ArgoCD d’abord avec Helm, puis crée l’Application. ArgoCD s’adopte lui-même

helm install argocd argo/argo-cd -n argocd
kubectl apply -f argocd-application.yaml

Option 2: Utilise le pattern App of Apps. Ton Application bootstrap crée toutes les autres Applications, y compris celle pour ArgoCD

Option 3: Inclus l’Application dans le chart Helm lui-même via server.additionalApplications

J’utilise l’option 1. C’est simple. L’install manuelle se fait une seule fois. Après, tout est GitOps

Ce qui se passe pendant un self-upgrade

1. Tu push de nouvelles values sur git
2. ArgoCD détecte le drift
3. ArgoCD commence à sync
4. Le Helm upgrade tourne, les pods sont remplacés
5. Le controller ArgoCD redémarre
6. Le nouveau controller démarre, check le statut du sync
7. Le sync se termine (ou retry si interrompu)

Le truc clé: selfHeal: true veut dire que si quelque chose casse en plein sync, ArgoCD va retry jusqu’à matcher l’état désiré

Le moment fun

Regarde l’UI pendant qu’ArgoCD s’upgrade lui-même. Tu vas voir les pods passer en jaune (progressing), puis l’UI se déconnecte quelques secondes, puis ça revient et tout est vert

C’est étrangement satisfaisant. Comme regarder un robot se réparer tout seul

Gérer les CRDs

Les CRDs ArgoCD demandent une attention particulière. Si tu upgrade les CRDs via l’Application, faut que les CRDs soient appliquées avant que le controller essaie de les utiliser

Le chart Helm gère ça avec un hook pre-install. Mais si t’es parano, tu peux gérer les CRDs séparément avec une Application dédiée qui sync en premier:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-crds
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
spec:
  source:
    repoURL: https://github.com/argoproj/argo-cd
    path: manifests/crds
    targetRevision: v2.13.0
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd

Sync wave -1 veut dire que les CRDs se déploient avant l’Application ArgoCD principale

Quand ça foire

J’ai eu exactement un problème: une mauvaise config qui faisait crash loop ArgoCD. Il pouvait pas sync parce qu’il pouvait pas démarrer. Deadlock classique

Le fix: kubectl apply de la version précédente qui marchait, manuellement. Une fois ArgoCD healthy, il sync sur git (que t’as corrigé entre temps)

C’est pour ça que tu veux replicas: 2 pour le controller. Si un pod crash pendant l’upgrade, l’autre continue de faire tourner les choses

Le meta va plus loin

Tu peux aller plus loin. ArgoCD qui manage ArgoCD qui manage tes apps. ArgoCD Image Updater qui surveille les nouvelles versions d’ArgoCD et crée des PRs. Renovate qui bump la version du chart automatiquement

À un moment t’es juste en train de regarder des robots mettre à jour des robots. Et c’est le but. Tu push du code, tout le reste se fait automatiquement

Tu devrais le faire?

Oui. Si tu utilises ArgoCD pour tout le reste, ne pas l’utiliser pour ArgoCD lui-même c’est incohérent. Tu perds la trace d’audit. Tu perds la détection de drift. T’es de retour à “je crois que j’ai fait un helm upgrade le mois dernier”

Le self-management marche. ArgoCD gère ça bien. Et il y a quelque chose de philosophiquement satisfaisant dans un outil qui applique ce qu’il prêche