Appréhender le GitOps, le déploiement continu façon Kube Native

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 : 

• Un langage déclaratif pour décrire l'état souhaité des ressources dans Kube ;
• Un dépôt de code source Git ;
• Un workflow adapté sur la gestion des changements ;
• Un opérateur ou un agent chargé de maintenir l'état entre la description dans Git et l’état dans un cluster Kubernetes.

À 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.

Les fondements du GitOps

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 : 

• Le Push based deployment, plus conventionnel. Ici, la pipeline de CI/CD, va pousser les modifications en production lorsque la chaîne termine un build en succès. C'est donc une modification poussée dans Git qui va déclencher la CI/CD et à terme mettre à jour l'infrastructure.
  
  
• Et le Pull based deployment, qui sera utilisé par les outils GitOps. Cette stratégie inverse les données du problème, dans ce cas, c’est l’agent déployé dans le cluster Kubernetes qui va directement surveiller les sources et maintenir les différentes ressources en cohérence vis-à-vis de sa description.

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 :

• Avoir l’ensemble des éléments du système décrit en utilisant un langage déclaratif (généralement, le YAML)
  
  
• Quand on parle de langage déclaratif, on cherche à garantir que la configuration de votre application est définie par un ensemble d’instructions versionnées dans Git, une source de vérité unique. Elles sont donc déployables et réinitialisables dans Kubernetes, que ce soit pour mettre à jour ou bien réagir rapidement à un incident.

• Le stockage versionné dans Git du code représentant l’état désiré des add-ons (certificats, dns, monitoring, log, csi-drivers, policies, etc.) et des applications (deployment, ingress, etc.)
  
  
• Garantir le contrôle de version du code source dans une source de vérité unique d’où tout est basé. Les avantages sont nombreux : du rollback rapide à l’état précédent de votre application, la signature des commits via l’utilisation de clés GPG ou SSH…

• Des outils pour détecter s'il y a une différence entre la source de vérité (Git) et l’état actuel. Il est recommandé de mettre en place de l’autocorrection au moindre changement d’état qui ne reflète pas le code. On parle d’ici d’une plateforme de déploiement continue.
  
  
• Pouvoir séparer ce que l’on souhaite faire de comment on va le faire dans plusieurs environnements distincts, car la définition de l’état est déclarée ailleurs.

• Et enfin, un moyen de déployer automatiquement (après validation) les changements pour correspondre à l’état désiré via l’utilisation d'opérateurs ou d’agents.
  
  
• Maintenant que votre système est déclaré et versionné dans une unique source de vérité, il va falloir s’assurer que les informations déclarées sont conformes à la réalité. Pour cela, on utilise des agents qui garantissent l’autocorrection des composants du système au moindre changement non reflété dans votre code. Ces outils vont assurer constamment l’état de vos applications.
  
  

Quels intérêts d’adopter le GitOps ?

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.

Gain de productivité

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.

Amélioration de l’expérience des équipes de développement

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. 

Meilleure traçabilité

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é.

Un SI plus fiable

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.

Les deux outils leaders en 2022

• Argo CD
• Une interface web bien travaillée avec une expérience utilisateur plaisante et accessible à tout type de métier ;
• Une CLI permettant de s’intégrer dans les processus d’automatisation ;
• Un écosystème d’outils orienté Kube native.

• Flux CD
• Full CLI mais des plugins d’UI existent ;
• Un mécanisme d’installation/bootstrap natif exécutable ensemble qui se branche à un repo git, génère tous les manifestes et transfère la responsabilité de la gestion/synchronisation du cluster au système Flux qui vient d’être installé.
• Pour plus de détails sur son utilisation et son fonctionnement, n’hésitez pas à lire l’article d'Ismaël : Comprendre l’approche GitOps avec Flux V2.
  
  

Take-Away

• Bien architecturer en amont quel type de workflow et organisation des repo Git on souhaite en fonction des applications, des équipes, des environnements et du besoin de scaling. Il faut en discuter avec les équipes ;
• Il est important d’écrire une documentation utile et compréhensible pour expliquer le fonctionnement du workflow et de l’implémentation choisie en fonction du contexte. Cela peut se faire par l’écriture d’un ADR, pour cela je vous invite à lire l’article de David Drungeon-Hamon Comment et pourquoi écrire une décision d’architecture ? .
• Déployer plus oui, mais attention à l’augmentation des incidents, gardez un œil sur vos métriques et KPI.