GitOps, déclarer c'est tricher

15.12.2021
GitOps, qu'est-ce que c'est ? À quoi sert-il ? Quels sont ses avantages et ses limites ? Ce sont les questions auxquelles répond Matisse, expert DevOps au sein de notre agence de Paris à travers ce nouvel article Lab.go :
DevOps

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.

GitOps : c'est quoi ?

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.

GIT : le système de contrôle de version le plus utilisé

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.

Schéma démontrant que chaque point correspond à une version différente du code accompagné de la date et du nom de l'auteur

Comme nous pouvons le voir ci-contre, chaque point correspond à une version différente du code. Mais également la date et le nom de l'auteur, ainsi que son commentaire sur les changements apportés.

Ops : l'équipe chargée de l'exploitation des applications et des infrastructures

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.

GitOps

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.

Schéma démontrant le process afin d'obtenir l'état de l'infrastructure souhaité

L’objectif du GitOps est donc de déclarer l'état désiré d'une infrastructure. Il est souvent corrélé d’un outil d’IaC (Infrastructure as Code), grâce auquel il est possible d’apporter les modifications nécessaires afin que la déclaration et l'état de l’infrastructure correspondent.

En savoir plus

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.

Schéma démontrant la réalisation du modèle push dans GitOps grâce à l'outil CI/CD

Les accès aux ressources de l’infrastructure sont disponibles dans l'outil CI/CD. Il est nécessaire de mettre en place de bonnes pratiques de sécurité. L’ensemble du processus de mise à jour dépend de l’outil de déploiement continu utilisé, ce qui demande plus d’efforts pour migrer d’un outil à l’autre.

Ansible vs. XL Deploy
Schéma démontrant la réalisation du modèle pull avec Kubernetes

Modèle pull 


À la différence de la stratégie « push », la mise à jour n’est plus déclenchée par un changement sur le repository Git. L’outil responsable de l’actualisation de l’infrastructure va récupérer périodiquement sa définition et l’actualiser en cas de changements.

C’est la stratégie recommandée pour Kubernetes car les outils proposant ce modèle ont presque tous été créés pour, rendant son implémentation simple et efficace.

En savoir plus

Pourquoi utiliser du GitOps ? Bénéfices d’une telle approche

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.

Limites de l’approche GitOps ?

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.

Conclusion

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

ENVIE D'APPORTER VOTRE EXPERTISE AUPRÈS DE NOS CLIENTS ?
Découvrez nos offres d'emploi DevOps
120
Offres à pourvoir
nous rejoindre