Structurer un dépôt GitOps qui tient à l’échelle
Organisation d’un dépôt Argo CD multi-cluster : séparation infrastructure et applications, vagues de synchronisation et gestion des dépendances.
3 min de lecture
Un dépôt GitOps commence toujours bien. Quelques manifestes, une application Argo CD, tout est lisible. Le problème apparaît au troisième cluster, quand la même correction doit être appliquée à trois endroits légèrement différents.
Séparer l’infrastructure des applications
La première décision structurante est de distinguer deux familles de composants.
L’infrastructure regroupe ce qui est partagé : contrôleur d’ingress, gestion des certificats, stockage, supervision. Les applications regroupent ce qui est propre à un service.
Cette séparation n’est pas cosmétique. Les deux familles n’ont ni le même rythme de mise à jour, ni les mêmes responsables, ni le même risque. Les mélanger revient à imposer le cycle de validation de l’infrastructure à chaque livraison applicative.
Figer les versions
Une application ne doit jamais suivre une branche mobile. Elle référence une version précise d’un chart, publiée dans un registre.
C’est ce qui rend le retour arrière possible : revenir à l’état d’hier consiste à révoquer un commit, pas à espérer que l’amont n’a rien changé entre-temps.
Ordonner avec les vagues de synchronisation
Argo CD ne garantit aucun ordre entre applications distinctes. Un service qui suppose l’existence d’un secret démarrera avant que celui-ci soit créé, et échouera.
Les vagues de synchronisation règlent l’ordre à l’intérieur d’une application :
metadata:
annotations:
argocd.argoproj.io/sync-wave: '-2'Les valeurs négatives passent en premier. Une progression lisible consiste à réserver les vagues les plus basses aux certificats et aux secrets, puis le stockage, et enfin les charges applicatives.
Gérer les dépendances entre applications
Les vagues ne franchissent pas la frontière d’une application. Pour une dépendance inter-applications, la solution la plus robuste reste un conteneur d’initialisation qui attend la disponibilité réelle de la dépendance.
C’est moins élégant qu’un graphe d’ordonnancement, mais cela a le mérite de fonctionner sans coordination centrale, et surtout de rendre l’attente visible dans l’état du pod plutôt que dans une boucle de redémarrages.
Désactiver sans supprimer
Retirer une application d’un cluster en supprimant son fichier fait perdre l’historique de configuration au moment où l’on en a le plus besoin.
Déplacer le fichier dans un répertoire ignoré par la synchronisation conserve tout : le manifeste, ses valeurs, et la raison de sa désactivation dans le message de commit.
Ce qu’il ne faut pas faire
Ne déployez jamais vers la production depuis la chaîne d’intégration. Si la CI applique directement des manifestes, Argo CD et la CI deviennent deux sources de vérité concurrentes, et la dérive est garantie.
La CI construit, valide, publie et met à jour une référence de version. Argo CD déploie. Chacun son rôle.