Quiz : GitOps avec Argo CD

b. Le principe « tiré automatiquement » d'OpenGitOps : l'agent tire l'état voulu, et la CI se contente d'écrire dans Git. L'identifiant du cluster quitte la CI. Leçon 1.

L'application passe OutOfSync : Argo CD détecte la dérive, mais ne la corrige pas tant qu'une synchronisation n'est pas lancée. Avec selfHeal: true, il la corrige en quelques secondes. (Si le champ est listé dans ignoreDifferences, la dérive n'est même pas signalée.) Leçon 3.

Argo CD rend le chart (équivalent de helm template) et applique le résultat lui-même : aucune release Helm n'est créée, helm list ne montre rien. Les hooks Helm sont traduits en hooks Argo CD. Leçon 3.

b. Sans prune, la synchronisation automatique n'élague pas : la ressource reste, signalée comme à élaguer, et l'application reste désynchronisée. Leçon 3.

Il fait de la suppression de l'Application une suppression en cascade : Argo CD supprime d'abord toutes les ressources gérées, puis retire le finalizer. Sans lui, un kubectl delete de l'Application laisse les ressources en place. (La CLI argocd app delete, elle, pose le finalizer d'elle-même et supprime en cascade par défaut.) Leçons 3 et 6.

Par l'annotation argocd.argoproj.io/tracking-id, méthode de suivi par défaut depuis la 3.0 (et non plus par l'étiquette app.kubernetes.io/instance). Elle contient le nom de l'application, ce qui permet à une application recréée sous le même nom de retrouver ses ressources. Leçons 3 et 6.

Par une demande de fusion qui change la version dans environnements/production/values.yaml, relue et fusionnée. Argo CD synchronise ensuite. La promotion est un commit, tracé, annulable par un revert. Leçon 4.

Rien de destructeur : un chemin absent est une erreur de rendu (ComparisonError, application Unknown), pas un rendu vide, donc rien n'est élagué. C'est ce qui a protégé les environnements lors du commit accidentel de la leçon 6. Leçons 4 et 6.

La synchronisation s'arrête : la vague 1 n'est jamais appliquée, le Deployment reste sur l'ancienne version, qui continue de servir. Un hook SyncFail peut s'exécuter, et la synchronisation automatique réessaie (5 fois par défaut). Leçon 5.

Argo CD applique les manifestes par l'application côté serveur de Kubernetes : le serveur fusionne et enregistre Argo CD comme propriétaire déclaré des champs qu'il fournit (dans managedFields, l'opération d'argocd-controller passe de Update à Apply). Utile pour les ressources volumineuses et la cohabitation avec d'autres contrôleurs. Leçon 5.

Au rafraîchissement suivant du générateur (trois minutes par défaut), l'application signalements-demo n'est plus générée : le contrôleur la supprime, et comme les applications générées portent par défaut le finalizer de cascade, toutes ses ressources sont supprimées. Leçon 6.

syncPolicy.preserveResourcesOnDeletion: true (pas de finalizer de cascade sur les applications générées) et syncPolicy.applicationsSync: create-update (le contrôleur ne supprime plus les applications qui ne sont plus générées). Leçon 6.

Ils déploient le contenu d'une demande de fusion avant sa relecture. Sur un dépôt ouvert, n'importe qui pourrait faire exécuter du code dans le cluster. On filtre les demandes (étiquette posée par un mainteneur), on isole les aperçus dans un projet aux droits réduits, sans accès aux secrets de production. Leçon 6.

argocd appset generate fichier.yaml exécute les générateurs et affiche les Applications qui seraient produites ; kubectl apply --dry-run=server valide le schéma. Leçon 6.

b. Le code (NewCluster) n'utilise le jeton de argocd-manager que si le contexte n'a pas de certificat client : Argo CD reçoit alors l'identité d'administration du kubeconfig. D'où l'enregistrement déclaratif avec un compte limité. Leçon 7.

Les ressources de l'ancien cluster restent en place, orphelines (l'élagage ne concerne que la destination). Et, la révision ayant déjà été synchronisée, la synchronisation automatique n'est qu'une auto-réparation partielle : pas de hooks (ni migration, ni test de fumée), pas d'entrée d'historique. Il faut une synchronisation complète manuelle. Leçon 7.

Non : deny l'emporte sur allow. Seule exception, une synchronisation manuelle si la fenêtre deny a manualSync: true. Leçon 7.

Argo CD doit alors accéder au coffre, et les manifestes rendus, secrets compris, sont conservés en clair dans son cache Redis et exposés par l'API du repo-server. Les mises à jour de secrets sont aussi couplées aux synchronisations. Elle recommande de résoudre les secrets dans le cluster de destination (External Secrets, Sealed Secrets). Leçon 8.

policy.default s'applique à tout utilisateur authentifié, et aucune règle deny ne peut le retirer. Avec role:readonly, tout compte qui se connecte lit toutes les applications, projets et dépôts ; plusieurs vulnérabilités (dont CVE-2026-42880) ont permis d'extraire des secrets avec la seule lecture. Leçon 9.

helm uninstall évalue cette annotation sur le manifeste enregistré dans le secret de release, pas sur les objets du cluster : les ressources annotées à la main sont supprimées quand même. On supprime plutôt les secrets de release de Helm (owner=helm,name=<release>), après qu'Argo CD a synchronisé l'application. Leçon 10.