20 commentaires
Le GitOps, c'est surtout la garantie de l'état désiré. En CI/CD classique, tu peux avoir des dérives de configuration (drift) que personne ne voit. Avec GitOps, ton repo git est la source de vérité, point final.
La "source de vérité" c'est bien beau, mais quand ton cluster est en vrac parce qu'une synchro automatique a échoué à cause d'un bug de template, tu pleures. En CI classique, tu as un log clair et direct.
C'est une question de maturité. Si tu considères que ton cluster doit être "immuable" au niveau de la config, le GitOps est obligatoire. Si tu fais du patch à la main en kubectl, forcément ça va coincer.
Personne ne fait du patch à la main en prod, soyons sérieux. Je parle de la complexité de gérer des centaines de chart Helm via ArgoCD vs un script bash ou un pipeline Jenkins/GitLab CI bien fait.
Jenkins pour déployer sur K8s en 2024 ? C'est le meilleur moyen de finir avec des permissions cluster-admin sur tes serveurs CI. Le GitOps permet de découpler la CI (build) du déploiement (CD).
Le découplage est un argument, mais en pratique, ça ajoute un hop réseau entre le repo et le cluster. Le debug est plus lent.
Le vrai problème du GitOps c'est la gestion des secrets. Tu te retrouves à ajouter SealedSecrets ou Vault, ce qui ajoute encore plus de couches. C'est pas plus simple, c'est juste différent.
Exactement ! La gestion des secrets en GitOps est souvent un enfer de maintenance comparé aux variables d'environnement injectées par une CI classique.
C'est pour ça qu'on utilise des outils comme ExternalSecrets, pour éviter de stocker des trucs dans git. Faut juste savoir configurer son cluster correctement.
Encore une dépendance externe. Si ton Vault est down, ton déploiement échoue. C'est pas plus robuste.
Le GitOps force à structurer tes manifests. Si ton repo est un bordel de fichiers YAML, c'est pas la faute de l'outil, c'est la faute de l'équipe.
Sauf que le GitOps rend le "hotfix" impossible. Tu veux changer une config en urgence ? Tu dois attendre le merge, la synchro, etc. C'est trop rigide.
Le hotfix en prod sans passer par le pipeline, c'est justement ce qui crée le drift que le GitOps est censé résoudre. Le GitOps protège l'équipe contre elle-même.
Ça protège l'équipe contre l'agilité, oui. Parfois on a besoin de réagir vite.
Je pense qu'on confond GitOps et "déploiement automatisé". Tu peux faire du bon CI/CD sans forcément tout mettre dans ArgoCD.
C'est ce que je dis. Le GitOps est devenu un buzzword que tout le monde veut implémenter pour "faire moderne" sans évaluer le coût opérationnel.
Le coût opérationnel est largement compensé par la facilité de rollback. Un git revert et tout revient en arrière. Tente ça avec ton pipeline impératif.
Un git revert est aussi simple avec un pipeline de déploiement classique. La différence est minime.
Le GitOps offre une audit trail native. Qui a changé quoi et quand ? C'est dans l'historique git. C'est précieux pour la conformité.
On peut avoir de l'audit sans GitOps. Mais je comprends l'argument. Je reste sceptique sur le gain réel vs la complexité.
Laisser une réponse
Vous devez être connecté pour poster un message !
On entend partout que le GitOps est la panacée pour le déploiement Kubernetes. Pourtant, après avoir migré plusieurs pipelines vers ArgoCD, je commence à douter de la complexité ajoutée par rapport à un pipeline CI/CD classique bien huilé.
Est-ce que le GitOps n'est pas juste une couche de sur-ingénierie pour les équipes qui n'ont pas de bonnes pratiques de CI ? J'ai l'impression qu'on perd en visibilité sur l'état réel du déploiement au profit d'une abstraction qui rend le debug infernal quand ça synchronise pas.