GitOps, un terme, une approche qui fait beaucoup parler de lui depuis quelque temps. Restons pragmatiques, l’objectif gravite autour des avantages du DevOps. On cherche à livrer plus rapidement en rendant autonomes les équipes et cela passe par automatiser la mise en production ou tout du moins, en réduire les goulots d’étranglement.
L’idée de base est d'utiliser Git comme source de vérité pour décrire l'état désiré des ressources dans Kubernetes, uniquement via des changements du code validés par des pull-requests (ou merge-request). La promesse est d'améliorer l'expérience des développeurs, des SRE et toutes les équipes qui gravitent autours pour la gestion des services, composants et add-ons (certificats, DNS, monitoring, log, csi drivers, policies, etc. ) qui fonctionnent dans Kubernetes en utilisant des outils qu'ils connaissent :
À tout instant, l'état des ressources du cluster doit être le reflet de sa description dans les sources de code Git. Lorsqu'une modification est apportée dans l'application ou les add-ons du cluster, elle est prise en compte et appliquée, que ce soit de manière automatique ou manuelle en fonction de la maturité des équipes.
L’idée derrière le GitOps est de mieux gérer le flux de déploiement. Que ce soit pour de la production, mais pas que, et ce, à l’échelle. En date de cet article, les cas d’usages que l’on retrouve sont orientés autour de déploiement dans Kubernetes via le concept de pattern operator qui utilise la mécanique de Pull based deployment. Le principe du GitOps est applicable à toute infrastructure déployée de manière déclarative ou via des outils d’Infrastructure-as-Code qui vont, eux, plutôt implémenter un dispositif de Push based deployment.
Deux stratégies de déploiement pour assurer une chaîne de CI/CD :
Dans les deux cas, il n'y a plus besoin de modification ou d'accès manuel aux infrastructures. Ce sont les orchestrateurs et les outils de déploiement continu qui exécutent les tâches (ceci étant dépendant du niveau de maturité des équipes sur les outils mis en place).
Pour cela, on cherche à mettre en place plusieurs éléments :
Comme vous avez pu le comprendre, l’un des éléments indispensables du GitOps est d’avoir une source de vérité pour les ressources add-on d’infrastructure (au niveau de Kube), mais aussi pour les applications : on va pouvoir augmenter drastiquement la vitesse de déploiement pour les équipes de développement qui gagnent en autonomie tout en améliorant la fiabilité du système via des revues de code pour les équipes de production.
Bon, pour être juste, toutes les technologies de déploiement continu promettent de rendre le déploiement plus rapide et de vous permettre de le faire plus souvent. Ce qui est unique avec GitOps, c'est que vous n'avez pas à changer d'outil pour déployer votre application. Tout se passe dans le système de contrôle de version que vous utilisez pour développer l'application.
L’adoption d’un workflow GitOps orbitant autour du combo d’outils GitLab-CI + Argo CD ou même de GitHub Actions + Flux CD va permettre aux équipes de développement de livrer quel que soit l’environnement, et ce, en autonomie. La mise en production devient un non-événement autant pour les dev que pour les SRE.
On garde léger le catalogue d’outils pour travailler : pousser son code sur Git sans s’occuper des ressources Kubernetes. Chaque équipe produit peut, de façon sécurisée, mettre à jour plusieurs fois par jour - instantanément, des fonctionnalités des applications qu’elle gère sans avoir besoin de connaître tout le fonctionnement interne de Kubernetes. Elle aura la possibilité d’observer les résultats en temps réel et d’utiliser ses informations pour itérer rapidement.
Cela se traduit aussi par un onboarding plus simple pour les nouveaux, donc une productivité en quelques jours au lieu de plusieurs semaines voir mois. Il reste néanmoins très utile de comprendre les mécanismes et ressources de Kubernetes pour respecter au mieux the twelve-factors app.
Le fait que Git soit au cœur du workflow GitOps améliore grandement les capacités d’audit et de visibilité des changements apportées au cluster en dehors de Kubernetes : qui a fait quoi (commit signé, clé GPG, etc.) et quand (horodatage), ces informations sont d’une grande aide en cas d'incident ou bien lors d’audits de conformité.
On profite encore une fois de la puissance de Git pour effectuer des revert/rollback sur les changements. Que ce soit en cas de catastrophe suite à un changement (ajout de fonctionnalités, modification des ressources Kubernetes, etc.) ou bien un effet de bord, vous réduisez ainsi le temps pour revenir à un état stable par de simples actions qui ne prennent que quelques minutes.
De plus, il devient possible de partager la gestion des incidents liés aux applications entre des SRE et des équipes de développeurs. L’idée étant de donner le plus d’autonomie possible aux équipes produit qui créent de nouvelles fonctionnalités pour s’occuper elles-mêmes des défaillances liées à leur code.
En effet, elles sont les plus à même d’en connaître l’origine car qui d’autre serait mieux placé que le développeur pour comprendre d’où proviennent les défaillances.