ADR-0010 : ArgoCD comme outil de déploiement GitOps


Statut	Accepté
Date	2025-10
Décideurs	Équipe Edukit (dev + ops)
Périmètre	Pipeline de déploiement continu, cluster K3s

Contexte

Une fois K3s en place (voir ADR-0009), il faut un moyen d’y déployer les services de façon fiable et traçable. Sans outil dédié, déployer revient à lancer kubectl apply à la main - ce qui ne permet pas de savoir qui a déployé quoi, ni de revenir en arrière facilement.

Les besoins sont :

Traçabilité : chaque déploiement doit être lié à un commit Git ;
Détection de dérive : si quelqu’un modifie un déploiement directement dans le cluster (sans passer par Git), on doit le détecter ;
Rollback facile : revenir à une version précédente doit être simple ;
Séparation des rôles : les développeurs ne doivent pas avoir accès directement au cluster de production.

Décision

Utiliser ArgoCD pour synchroniser automatiquement les fichiers de configuration Kubernetes depuis Git vers le cluster K3s.

Les fichiers de déploiement (ce qu’on veut déployer, en quelle quantité, avec quelles variables) sont versionnés dans Git.
ArgoCD surveille Git et applique les changements sur le cluster dès qu’il en détecte.
Le pipeline CI (Azure Pipelines) met à jour le numéro de version de l’image dans Git après chaque build ; ArgoCD s’occupe du reste.
En staging, la synchronisation est automatique. En production, un opérateur valide manuellement le déploiement depuis l’interface ArgoCD.

Conséquences

Bénéfices

Git comme référence : l’historique Git est le journal de tous les déploiements. On sait exactement ce qui tourne en production et depuis quand.
Détection de dérive : si le cluster diverge de ce qui est dans Git (modification manuelle, crash), ArgoCD le signale et peut corriger automatiquement.
Rollback simple : pour revenir en arrière, on revient au commit précédent dans Git - ArgoCD fait le reste.
Expérience d’équipe : l’équipe connaît déjà ArgoCD, ce qui accélère la mise en place.
Interface claire : l’interface web d’ArgoCD montre l’état de chaque service, les différences avec Git et l’historique des déploiements.

Coûts et limites

Les secrets ne vont pas dans Git : ArgoCD ne gère pas les mots de passe et tokens. Ils sont stockés dans Vaultwarden (voir ADR-0013) et créés manuellement comme Kubernetes Secrets - ils ne doivent jamais apparaître dans le dépôt Git.
Courbe d’apprentissage : la notion d’“application ArgoCD” et ses options de configuration (App of Apps, ApplicationSets) prennent un peu de temps à maîtriser.
Dépendance à Git : si le dépôt Git est inaccessible, ArgoCD ne peut plus synchroniser. Le cluster continue de fonctionner avec son état actuel, mais aucun nouveau déploiement n’est possible.

Alternatives écartées

Flux CD : outil GitOps similaire à ArgoCD, maintenu par la CNCF. Les fonctionnalités sont comparables. Écarté uniquement parce que l’équipe est déjà à l’aise avec ArgoCD - changer d’outil n’apporterait rien de plus.
kubectl apply dans le pipeline CI : facile à mettre en place, mais sans détection de dérive, sans historique centralisé et sans interface pour visualiser l’état du cluster. Pas adapté à la production.
Helm seul : Helm est un gestionnaire de templates pour les fichiers Kubernetes. Il ne gère pas la réconciliation continue. ArgoCD peut d’ailleurs piloter des charts Helm - les deux sont complémentaires.
Spinnaker : outil de déploiement continu très complet (déploiements progressifs, blue/green), mais beaucoup trop lourd à installer et opérer pour les besoins d’Edukit.

Références

ADR-0009 : cluster K3s où ArgoCD déploie les services.
ADR-0013 : Vaultwarden stocke les secrets de l’équipe ; les Kubernetes Secrets sont créés manuellement à partir de ces valeurs.
Pipeline CI : azure-pipelines.yml (met à jour les tags d’image dans Git, ce qui déclenche la synchronisation ArgoCD).