Avec le lancement des premiers services de compute, les fournisseurs de Cloud publics ont révolutionné la manière dont les développeurs consomment et utilisent les ressources nécessaires pour déployer et maintenir les applications. Quelques années après, le potentiel des outils d’infrastructure-as-code a commencé à exploser comme pour Ansible et Terraform.
Avec la montée en maturité de ces outils dans les entreprises, il est devenu évident que mettre à l’échelle des applications dans un environnement cloud nécessite des composants d’infrastructures duplicables et réutilisables. Ainsi, l’infrastructure-as-code devient le nouveau standard pour s’assurer que les bonnes ressources soient allouées à une application.
Le monde de l’infrastructure et du logiciel a continué d’évoluer. Les concepts d'intégration et déploiement continu gagnent de plus en plus en maturité et de nouvelles solutions dans le domaine de l’infrastructure ont été créées pour suivre la tendance. Kubernetes et les technologies serverless promettent de libérer une fois de plus les développeurs de la nécessité de se préoccuper de l’infrastructure. Dans une période post-DevOps, comment peut-on penser à l’infrastructure-as-code et les applications comme un seul ensemble cohérent ? GitOps a la réponse.
C’est quoi GitOps ?
Le terme GitOps a été introduit en 2017 par WeaveWorks, dont les développeurs utilisent git comme la seule source de vérité et le point de convergence entre le code applicatif et l’infrastructure.
Le GitOps n’est techniquement pas différent de l’utilisation de l’infrastructure-as-code et des technologies de CI/CD. En fait, c’est la convergence de ces deux concepts. C’est une implémentation du déploiement automatisé d’application Cloud Native qui consiste à réaliser la construction de l'infrastructure en utilisant les mêmes outils utilisés lors du développement d’applications comme Git ou encore les outils de CI/CD.
Le concept est d’avoir dans un repository Git la description déclarative de l’infrastructure souhaitée en production et un processus automatisé, qui se charge d'appliquer l'état d’infrastructure défini dans le repo git sur vos environnements. Ainsi, pour déployer une nouvelle version d’application ou la mettre à jour, le repository Git doit être mis à jour et le processus automatisé se charge du reste, car c’est la source centrale de vérité pour toute l’infrastructure requise pour faire tourner les applications
Dès lors, les équipes de développement et des opérations peuvent tout aussi bien partager les mêmes pratiques et utiliser des modèles de développement et des stratégies de branching qui leur sont familiers.
De cette manière, le GitOps peut être utilisé comme un modèle opérationnel pour des infrastructures modernes comme Kubernetes, le serverless ou toute autre technologie cloud native.
Quelle est la différence entre GitOps et DevOps ?
Dans un sens large, DevOps désigne une philosophie, une culture, qui favorise une meilleure collaboration entre les équipes, casse les silos et fluidifie les cycles de vie d’applications. GitOps est une technique d’implémentation de l'intégration continue de l’infrastructure.
La comparaison entre les deux notions n’a donc pas de sens. Par contre, ils partagent les mêmes principes d’automatisation et livraison continue. En général, les équipes ayant une grande maturité DevOps arrivent plus facilement à adopter GitOps dans leurs projets.
Comment fonctionne GitOps ?
Pour arriver à une implémentation complète du GitOps, il faut utiliser un pipeline CI/CD. Les changements d’infrastructures sur Git seront déployés automatiquement dans l'environnement souhaité après chaque commit.
Il y a deux stratégies de déploiement différentes :
Stratégie de PUSH : C’est une stratégie classique supportée par la plupart des infrastructures. Le code source de l’application et des manifests de déploiement sont poussés sur Git. À chaque nouveau changement dans le code, le pipeline construit une nouvelle image docker et pousse les changements au repository de l’environnement.
Le petit inconvénient, c’est que votre outil de CI/CD a les accès en écriture sur vos infrastructures. Cette stratégie peut être appliquée par les outils classiques de CICD : Gitlab-CI, Jenkins… Toutefois, le mode PUSH n’assure pas que l'état du cluster correspond au repository git.
Stratégie de PULL : C’est une meilleure stratégie d’un point de vue sécurité et qui introduit une notion d’Operator. C’est un composant qui se situe entre votre pipeline et votre outil de provisioning. L'opérateur compare de manière constante l'état de votre infrastructure avec l'état désiré qui est déclaré dans votre repository et fait les changements nécessaires quand ils sont détectés. Cette stratégie peut être appliquée par des outils GitOps bien spécifiques comme Argocd ou fluxcd.
Les applications aujourd'hui nécessitent plusieurs environnements. Dans ce sens, GitOps permet de créer plusieurs pipelines qui peuvent modifier le repository d'environnements et ainsi, déployer sur un environnement ou un autre. L’utilisation des branches par environnement suivant un workflow bien défini (gitflow, Github flow, Trunk based development ... ) est recommandé et peut aider à gérer l’ensemble de vos environnements sur l’infrastructure de déploiement.
GitOps veut forcément dire un déploiement sur Kubernetes ?
+95% des articles ou tutoriels GitOps que vous trouverez sur internet intègrent Kubernetes. En principe, GitOps peut être appliqué à toute infrastructure qui peut être déclarée avec des outils d’Infrastructure-as-code et de manière déclarative.
Si GitOps est souvent associé à Kubernetes, c'est simplement parce que la plupart des Operators "Pull based Deployment" supportent Kubernetes aujourd'hui. Les “push based deployments” étant plus faciles/traditionnels à implémenter supportent toute infrastructure pouvant être décrite de manière déclarative.
Pourquoi une organisation doit adopter les pratiques GitOps ?
D’un point de vue stratégique, il y a plusieurs raisons qui peuvent amener une organisation à adopter la pratique du GitOps.
Déploiements Continus
Les déploiements automatisés impliquent forcément des déploiements plus fréquents et plus rapides. GitOps facilite le processus de déploiement d’infrastructure, car tous les changements se passent sur Git et il n’y a plus besoin de gérer des outils en plus pour mettre à jour votre infrastructure.
Rollback
Toutes les opérations sont tracées et historisées sur Git. Il est toujours possible de retrouver à partir de quel déploiement (ou commit) un dysfonctionnement est apparu et de retirer la modification correspondante. Ceci réduit énormément le MTTR (Mean-time-to-repair), en particulier sur des architectures microservices.
Sécurité
GitOps repose sur la sécurisation du repository Git. Tandis que les équipes ont les droits d'écriture et passent par un processus de peer-review via des pull-requests, le processus chargé de déployer sur l’environnement cible nécessite seulement des droits de lecture (et en particulier pour des stratégies de Pull). Le fait d'utiliser des branches bien protégées pour des environnements de production ( accessibles en écriture à des profils restreints) et d’avoir une stratégie de gestion de secrets augmentent le niveau de sécurité des déploiements. Ceci permettra de ne pas exposer les secrets via la CI/CD (facile à garantir en mode PULL) et de faciliter les audits du code Git car c’est la seule source de vérité.
Auto-documentation
Étant donné que l'état d’infrastructure est documenté sur Git, tous les membres de l'équipe peuvent suivre et comprendre l'évolution de l’infrastructure. Ce repository Git représente en lui-même une documentation maintenue enrichie avec les messages des commits.
Comment se préparer pour faire du GitOps ?
Avant de faire du GitOps, toute organisation doit adopter un certain nombre de pratiques afin d’augmenter son niveau de maturité et tirer les meilleurs bénéfices du GitOps.
La culture de peer-review
Les code reviews ont un rôle très important dans le cycle de développement des applications de manière générale, en particulier dans des environnements gérés via des pipelines CI/CD. Un bon processus de code review permet d'éviter une mauvaise qualité de code et empêche le déploiement du code en question. L’objectif est de mettre en place un standard de revue de code qui maintient un niveau élevé de qualité de code et conforme à la politique de l’organisation.
L’observabilité
Tandis que le monitoring permet de connaître l'état de l’application, la mise en place d’une plateforme d’observabilité (Monitoring, logging et tracing…) donne une visibilité complète des métriques, une compréhension complète des patterns et axes d'amélioration de notre architecture. GitOps permet à son tour une flexibilité de déploiement automatisé d’infrastructure avec des éventuelles possibilités de rollback en s'appuyant sur des alertes remontées. Par conséquent, la mise en place des briques d’observabilité sera nécessaire pour détecter les éventuelles erreurs sur des mises à jour d’infrastructure et les changements de configurations.
La culture DevOps
GitOps partage les mêmes principes d’automatisation que DevOps. Aujourd'hui, beaucoup d’organisations n’arrivent toujours pas à adopter la culture DevOps au sein de leurs équipes. Ce manque de maturité peut être dû à des raisons organisationnelles ou managériales diverses. DevOps n’est pas limité aux outils, mais c’est toute une culture d’entreprise qui favorise les équipes à travailler ensemble et de manière efficace pour casser les silos, réduire les TTM, et fluidifier les cycles de développement. Une organisation ne peut donc pas profiter de tous les bénéfices du GitOps sans une culture DevOps assez mature.
Les tests
Tout comme DevOps, incorporer des pratiques GitOps requiert toute une stratégie de tests au niveau de l’organisation. Le niveau d’automatisation de déploiement infrastructure exige un niveau de tests assez robuste sur les pipelines. Même si les possibilités de rollbacks sont un peu plus faciles à implémenter, les tests d’infrastructure assurent une excellence opérationnelle et une fiabilité de l’infrastructure déployée.
Takeaway ?
GitOps est un très bon workflow qui permet de gérer efficacement le provisionnement d’infrastructures. Toutefois, il faut que l’organisation ait comme prérequis une bonne maturité DevOps et un ensemble de bonnes pratiques mises en place avant de l’adopter. À présent, il ne tient qu'à vous d'expérimenter GitOps au sein de vos équipes. Ceci vous permettra de juger de sa pertinence au sein de votre organisation et de forger votre opinion dessus
