GitOps, déclarer c’est tricher

Introduit par WeaveWorks en 2017, le GitOps définit des pratiques pour gérer et configurer une infrastructure ou une application de façon déclarative et versionnée. Utilisant Git comme base, cette stratégie permet d’avoir une source unique de vérité apportant de nombreux avantages.

En corrélation avec les avancées technologiques du domaine applicatif, les méthodes de travail évoluent également. De nouvelles méthodes de gestion des cycles d’une application ont vu le jour.

Partant du modèle en cascade, avec des itérations généralement très longues, la méthode Agile (notamment une des ses implémentations, Scrum), a commencé à faire son apparition, apportant plus de rapidité et de flexibilité.

Cette méthode de développement a pour objectif une distribution continue du logiciel, basée sur des itérations rapides. Cela permet d’accélérer les livraisons par le déploiement de versions fonctionnelles et non plus d’un produit fini.

L’objectif ici est de mettre en place une démarche GitOps pour permettre d’optimiser et de sécuriser la gestion des ressources informatiques.

Pour y voir plus clair, nous allons maintenant définir les termes Git et Ops.

Il permet, par exemple dans un contexte de développement, de facilement gérer l’évolution du code.

En utilisant cet outil, nous obtenons un historique des modifications effectuées donnant la possibilité de revenir à une version antérieure simplement.

Il facilite grandement la collaboration permettant de travailler à plusieurs sur le même projet, chacun apportant ses changements pour ensuite les mettre en commun.

Ops vient de la désormais célèbre approche DevOps. C’est un ensemble de pratiques mettant en avant la collaboration et la coordination des personnes, des processus et des technologies entre ces deux équipes.

L’approche GitOps suit le même objectif en donnant les outils nécessaires à l’intégration des pratiques DevOps pour l’administration des composants d’une infrastructure.

Le GitOps se concentre sur l’expérience développeur. L’utilisation d’outils de CI/CD et Git, leur évite de devoir apprendre à utiliser une nouvelle stack pour prendre en charge l’exploitation de leur application. Ceci est notamment vrai avec l’utilisation de Kubernetes, du serverless, et de certains services Cloud. Apportant un couche d’abstraction sur l’infrastructure, l’équipe de développement n’a besoin que de déclarer les ressources nécessaires.

L’idée centrale du GitOps est de mettre en place un flux de travail (workflow) autour de l’outil Git, tout en tirant les avantages que peut apporter ce système de contrôle de versions, notamment car l’émergence des architectures et de technologies récentes (micro-services, serverless, cloud) rendent les opérations de mise en production de plus en plus complexes.

Pour aller un peu plus loin on peut distinguer les deux différents modèles d’implémentation les plus utilisées :

Modèle push 

C’est la stratégie la plus commune.

À chaque changement de l’état de l’infrastructure sur le repository Git, une mise à jour de l’infrastructure existante va être initiée via des pipelines de déploiement.

Cette stratégie est la plus simple à mettre en place, la plupart des outils de CI/CD se basent sur un modèle « push ». Il est préférable d’utiliser ce modèle si l’infrastructure ne s’appuie pas sur Kubernetes.

En ajoutant une brique de gestion à l’Infrastructure as Code (IaC), le GitOps permet :

• Retour en arrière simple et fiable : chaque changement sur le repository Git est semblable à un snapshot. Si le service n’est plus fonctionnel, il est possible de revenir à une version antérieure.
• Lisibilité et documentation : chaque changement effectué sur le code est signé et expliqué par son auteur. Il est donc possible d’avoir une vision sur l’historique du projet sur : qui, quoi, quand et pourquoi telle modification a été effectuée.
• Sécurité et conformité : avec les intégrations natives aux plateformes proposant l’hébergement de repository Git, il est possible d’avoir une gestion fine des droits et la validation des changements sur le code source. Plusieurs outils sont également disponibles pour vérifier les bonnes pratiques et remonter de possibles erreurs sur le code décrivant l’infrastructure. Plus besoin d’accès à la machine, seul un compte de service a besoin d’y accéder. Le GitOps c’est aussi réduire le plus possible l’erreur humaine en donnant la main aux outils pour le déploiement.
• Déploiements accélérés : avec l’automatisation du déploiement de l’infrastructure, il suffit de définir l’état final et les outils de déploiements s’occupent du reste.
• Abstraction de l’infrastructure : Cette pratique permet aux développeurs de pouvoir mettre en place des ressources sans avoir besoin de connaître en détail l’infrastructure. Notamment sur le pilotage de ressources Kubernetes et Cloud.

Malgré tous ses avantages, GitOps reste difficile à mettre en place.

Initialement conçue pour être utilisée dans des environnements Cloud et Kubernetes, l’approche GitOps répond particulièrement aux complexités de ces solutions. Il est tout de même possible de l’utiliser avec des ressources plus classiques, mais cela rend son implémentation et sa gestion encore plus difficile.

Il ne suffit pas de vouloir faire du GitOps pour se retrouver avec quelque chose d’efficace. C’est un processus qui prend du temps à mettre en place, qui doit s’adapter au projet et ses possibles contraintes.

Le bon fonctionnement de l’approche GitOps nécessite la collaboration des différentes équipes concernées. Il est important de faire adhérer l’ensemble des acteurs quant à l’utilisation et à l’adaptation des ces nouvelles méthodes de travail.

J’ai eu l’occasion d’appréhender différentes implémentations, chacunes avec ses spécificités permettant de mieux s’accorder avec les problématiques techniques des projets sous-jacents.

L’approche GitOps permet de gérer efficacement les ressources d’une infrastructure. Cependant son implémentation doit être faite au cas par cas, afin de mieux répondre aux différents besoins de votre infrastructure. À savoir que cette-dernière s’harmonise mieux avec Kubernetes dans un environnement Cloud.

Pour finir, ayez conscience que l’implémentation de la démarche GitOps peut prendre du temps, surtout quand il s’agit de migrer un ancien projet vers cette méthode, alors n’hésitez pas à démarrer tout de suite vos nouveaux projets avec.

Matisse, expert DevOps au sein de notre agence de Paris