Découvrez pourquoi éviter Flux pour le GitOps en pull. Le GitOps en push via un pipeline CICD est une bonne alternative, mais ArgoCD reste le meilleur choix.
ArgoCD : la meilleure option pour le GitOps en pull
Quiconque pratique Kubernetes finit par mesurer la valeur du GitOps. Vient alors la question des bonnes pratiques. Faut-il choisir ArgoCD ou FluxCD v2 ? Existe-t-il d'autres options ? Si ces questions vous parlent, vous êtes au bon endroit.
Dans cet article, j'explique pourquoi il vaut mieux éviter Flux et pourquoi ArgoCD s'impose comme le meilleur choix pour faire du GitOps en pull. Une autre piste à envisager : le GitOps en push via un pipeline CICD.
Qu'attendions-nous du GitOps ?
Pour commencer, c'est une bonne réponse à un problème introduit par une solution antérieure : l'Infrastructure as Code (IaC) permet d'obtenir des déploiements reproductibles, et une source unique de vérité maintient les grandes équipes synchronisées avec un minimum d'échanges. Hélas, ces bénéfices de l'IaC supposent que l'état réel de votre infrastructure corresponde à l'état défini dans Git. Le GitOps règle ce nouveau problème de dérive de configuration, en gardant la réalité alignée sur git.
Recourir au GitOps pour traiter la dérive de configuration facilite aussi l'application du principe du moindre privilège et simplifie le contrôle d'accès basé sur les rôles (RBAC). Plutôt que d'accorder aux humains un accès kubectl en lecture seule, on peut leur donner un accès en lecture seule au dépôt git. L'accès direct à kubectl peut ainsi être réduit au strict minimum, au profit d'un RBAC appliqué aux comptes de service GitOps et aux dépôts git.
Le GitOps hérite également des contrôles de sécurité intégrés à git. Exiger des merges revus par les pairs revient à exiger des déploiements revus par les pairs. L'historique git devient alors une piste d'audit indiquant qui a modifié quoi, à quel moment et qui a approuvé le changement.
Pourquoi je recommande ArgoCD plutôt que FluxCD pour le GitOps en pull
En résumé : ArgoCD est un produit bien plus mature, doté d'une expérience utilisateur nettement supérieure à celle de Flux v2.
D'abord, si vous poussez une configuration erronée avec Argo, vous vous connectez en SSO à une interface graphique, vous voyez visuellement où se situe l'erreur et vous obtenez un message d'erreur exploitable. Avec Flux en revanche, il est déjà difficile de savoir qu'une erreur existe. Pour faire apparaître le message, vous devez exécuter la bonne commande sur le bon objet dans le bon namespace avec le bon outil CLI. Certaines erreurs remontent via kubectl, d'autres via fluxctl.
Ensuite, seul ArgoCD permet de faire véritablement du GitOps en pull et d'en tirer les bénéfices listés plus haut. Avec Argo, vous résolvez les problèmes sans accès kubectl. Vous poussez un changement sur git. Argo réconcilie en permanence un cluster en production à partir de git et restitue le retour dans l'interface graphique.
Avec Flux, impossible de résoudre les problèmes sans accès kubectl. Imaginons que vous ayez pris le temps de mettre en place des pipelines de logs parfaits, assortis d'alertes pour faire remonter les erreurs. Flux n'utilise pas une boucle de réconciliation infinie de type KISS comme Argo. Il s'appuie sur une boucle de réconciliation événementielle fragile, qui se retrouve fréquemment bloquée dans un mauvais état (plus souvent encore avec helm).
Dans un précédent poste, j'ai formé des centaines de personnes au GitOps avec Flux. Lors de ces sessions, Flux se retrouvait bloqué pour au moins 5 participants sur 20. La réconciliation s'arrête tant que l'état incohérent n'est pas corrigé. Les changements du dépôt git sont temporairement ignorés, et une intervention manuelle devient indispensable.
Le seul moyen de débloquer la situation passe par plusieurs commandes fluxctl. Et comme fluxctl dépend de kubectl, et qu'il faut corriger l'état, un accès en lecture seule ne suffit pas. Exemple classique : les erreurs install retries exhausted. Même si vous avez corrigé le problème dans git, tant pis : Flux a abandonné après s'être épuisé. Il faut alors plusieurs commandes fluxctl pour forcer un redéploiement. Vous pouvez bien modifier la configuration par défaut en retries = -1 (infini), cela ne résout pas le problème pour autant, cela en réduit seulement la fréquence. Flux ne déclenche la logique de déploiement que lorsqu'il détecte un changement. Il existe des cas limites où la réconciliation échoue parce qu'un changement lié à helm n'a pas été détecté.
Existe-t-il des cas où Flux fait mieux qu'Argo ?
ArgoCD évite délibérément certaines fonctionnalités avancées de helm rarement utilisées. Il privilégie une stabilité sans faille pour les cas d'usage les plus courants. Si vous utilisez un chart helm très avancé exploitant par exemple les helm hooks, ArgoCD pourrait ne pas le prendre en charge. Flux couvre mieux les fonctionnalités de helm.
Quelles autres options existent ?
J'ai souvent observé le schéma suivant dans les équipes qui réfléchissent à leur implémentation GitOps :
ArgoCD face à FluxCD, face à une multitude d'autres outils calqués sur le pattern operator. Je soupçonne que ce sont ces outils qui ressortent dans les moteurs de recherche sur le mot-clé GitOps.
Une alternative que l'on néglige souvent : pointer un pipeline CICD générique vers de l'IaC et des scripts stockés dans un dépôt git. J'appelle cette approche le GitOps en push. J'en suis adepte, car elle permet de combiner facilement logique de déploiement impérative et déclarative, ce qui s'avère précieux pour gérer des cas comme les mises à jour impliquant des breaking changes. Autant de scénarios difficiles à traiter avec une solution GitOps purement déclarative en pull.
Pour conclure
Les équipes qui adoptent le GitOps pour la première fois devraient rayer Flux de leur liste. ArgoCD ou un pipeline CICD sont des choix nettement plus pertinents pour mettre en œuvre le GitOps.