GitOps est-il la toute dernière nouveauté dans DevOps ?
De nombreuses organisations considèrent désormais que DevOps fait partie de leur stratégie de transformation digitale, car il encourage une culture de responsabilité partagée, de transparence et de feedback plus rapide. Pourtant, le fossé entre les équipes de développement et les équipes opérationnelles se réduit, tout comme le fossé entre les processus.
C'est également le cas de Git, le système de contrôle de version le plus utilisé dans le monde aujourd'hui. Les entreprises adoptent les méthodologies et les outils DevOps, ce qui a entraîné une évolution vers GitOps, ainsi qu'un ensemble de pratiques permettant aux développeurs d'effectuer davantage de tâches liées aux opérations informatiques.
Qu'est-ce que GitOps ?
À l'origine, GitOps consiste en une infrastructure basée sur le code et des procédures opérationnelles qui s'appuient sur Git comme système de contrôle de version. Il s'agit d'une évolution d'Infrastructure-as-Code (IaC) et d'une bonne pratique DevOps qui s'appuie sur Git en tant que source de référence unique et que mécanisme de contrôle pour créer, mettre à jour et supprimer l'architecture du système. Plus simplement, il s'agit de la pratique consistant à utiliser les pull requests Git pour vérifier et déployer automatiquement les modifications de l'infrastructure système.
En plus de Git en tant que mécanisme DevOps clé, GitOps est également utilisé pour décrire les outils qui enrichissent les fonctionnalités par défaut de Git. Ces outils ont été principalement utilisés avec des modèles opérationnels pour les infrastructures et les apps basées sur Kubernetes. La communauté DevOps développe et discute actuellement de l'application des outils GitOps à d'autres plateformes non Kubernetes, telles que Terraform.
GitOps garantit que l'infrastructure cloud d'un système est immédiatement reproductible en fonction de l'état d'un dépôt Git. Les pull requests modifient l'état du dépôt Git. Une fois approuvées et mergées, les pull requests reconfigurent et synchronisent automatiquement l'infrastructure active avec l'état du dépôt. Ce workflow de synchronisation en direct des pull requests est l'essence même de GitOps.
Ressource connexe
Fiche de révision sur Git
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
L'histoire de GitOps
Git est un outil essentiel pour le développement logiciel qui permet des workflows de pull request et de revue de code. Les pull requests favorisent la visibilité des changements apportés à une base de code, et encouragent la communication, la discussion et la revue des changements.
Les pull requests sont une caractéristique essentielle du développement logiciel collaboratif, et ont changé la façon dont les équipes et les entreprises créent des logiciels. Les pull requests apportent transparence et mesurabilité à un processus autrefois opaque. Les pull requests Git ont permis l'évolution des processus DevOps vers le développement logiciel. Les administrateurs système, qui hésitaient généralement à changer, adoptent désormais de nouvelles pratiques de développement logiciel comme Agile et DevOps.
L'administration des systèmes en tant que métier a une histoire peu reluisante. Auparavant, les administrateurs système géraient le matériel manuellement en se connectant à des machines et en les provisionnant dans un rack de serveurs physiques ou via une API de provisionnement dans le cloud. Outre le processus de provisionnement manuel, il était habituel de devoir réaliser beaucoup de tâches de configuration manuelles. Les administrateurs conservaient des collections personnalisées de scripts et de configurations impératives, les assemblaient et les plaçaient à divers endroits. Ces scripts pouvaient être interrompus à tout moment ou se perdre. La collaboration était difficile, car les chaînes d'outils personnalisés n'étaient pas régulièrement documentées ou partagées.
Le mouvement DevOps est né de ce véritable bourbier qu'est l'administration des systèmes. DevOps a emprunté les meilleures idées de l'ingénierie logicielle et les a appliquées à l'administration des systèmes, où les outils bricolés se sont transformés en code avec contrôle de version.
L'IaC est l'une des plus grandes révélations de DevOps. Auparavant, les administrateurs système privilégiaient les scripts impératifs personnalisés pour configurer les systèmes. Un logiciel impératif suit une séquence d'étapes pour atteindre un état souhaité, par exemple :
Un logiciel impératif comporte souvent des risques d'erreur, et il peut facilement tomber en panne lorsque la séquence des événements est modifiée. Le développement logiciel moderne s'est éloigné des modèles impératifs au profit des modèles déclaratifs.
Un logiciel déclaratif suit une déclaration d'un état attendu au lieu d'une séquence de commandes. Voici une comparaison entre les instructions DevOps impératives et déclaratives.
Les instructions impératives peuvent être formulées de la manière suivante :
- Installer un système d'exploitation sur cette machine
- Installer ces dépendances
- Télécharger le code à partir de cette URL
- Déplacer le code vers ce répertoire
- Effectuer ces opérations 3 fois pour 3 autres machines
La version déclarative de ces instructions serait simplement la suivante : 4 machines disposent d'un logiciel provenant de cette URL, installé dans ce répertoire.
L'IaC encourage et promeut les outils d'administration système déclaratifs par rapport aux solutions impératives personnalisées. Cela a conduit à l'émergence de technologies comme les conteneurs Docker, Ansible, Terraform et Kubernetes, qui utilisent des fichiers de configuration déclaratifs statiques. Les avantages de cette solution sont la lisibilité pour l'homme, ainsi qu'un état cohérent et reproductible. Ces fichiers de configuration ont naturellement été ajoutés à Git pour le suivi et la revue. Cela ressemble à GitOps, mais ce n'est pas tout à fait la même chose.
À ce stade de l'histoire de DevOps, bon nombre des problèmes traditionnels d'administration des systèmes ont été résolus. Les fichiers et outils de configuration sont désormais stockés dans un emplacement central, documentés et accessibles par de nombreux membres de l'équipe. Les commits et les pull requests ont été utilisés pour suivre les changements apportés à la configuration, et favoriser la discussion et la revue collaboratives. Le seul problème qui subsiste à ce stade ? La configuration semble encore déconnectée du système réel. Une fois qu'une pull request de configuration est approuvée et mergée dans le dépôt, le système réel est manuellement mis à jour pour correspondre à l'état du dépôt statique. C'est exactement le problème que GitOps résout.
L'idée de GitOps a d'abord été développée et partagée par WeaveWorks, une société de gestion Kubernetes d'entreprise. Elle a depuis proliféré dans toute la communauté DevOps. GitOps est une extension de l'IaC et de la configuration déclarative mentionnée ci-dessus. GitOps ajoute un peu de magie au workflow des pull requests qui synchronise l'état du système réel avec celui du dépôt de configuration statique.
Les avantages de GitOps
GitOps shares many of the same benefits as an agile feature branch software development workflow. The first major benefit is ease of adoption due to the usage of common tools. Git is the de facto standard of version control systems and is a common software development tool for most developers and software teams. This makes it easy for developers familiar with Git to become cross functional contributors and participate in GitOps.
L'utilisation d'un système de contrôle de version permet à une équipe de suivre toutes les modifications apportées à la configuration d'un système. Cela fournit une « source de référence » et une piste d'audit précieuse pour vérifier si quelque chose est cassé ou se comporte de manière inattendue. Les équipes peuvent consulter l'historique GitOps et voir quand une régression a été introduite. En outre, cette piste d'audit peut être utilisée comme référence pour les audits de conformité ou de sécurité. L'historique GitOps peut être utilisé comme preuve lorsque des éléments tels que les certificats de chiffrement sont modifiés ou mis à jour.
GitOps renforce la transparence et la clarté de l'infrastructure d'une organisation grâce à un dépôt central. Le fait de contenir toutes les configurations des systèmes dans un dépôt central permet de dimensionner les contributions des membres de l'équipe. Les pull requests effectuées via des services Git hébergés tels que Bitbucket disposent d'outils riches pour la revue du code et les commentaires de discussion. Cela crée des boucles de communication passives qui permettent à l'ensemble de l'équipe d'ingénierie d'observer et de surveiller les changements d'infrastructure.
GitOps peut considérablement augmenter la productivité d'une équipe DevOps, en lui permettant de tester rapidement de nouvelles configurations d'infrastructure. Si les nouveaux changements ne se comportent pas comme prévu, une équipe peut utiliser l'historique Git pour rétablir les changements à un état correct connu. Cette fonction est incroyablement puissante, car elle permet l'« annulation » familière dans une infrastructure complexe.
Fonctionnement de GitOps
Les procédures GitOps sont exécutées par un système d'orchestration sous-jacent. GitOps lui-même est un modèle de bonnes pratiques agnostique. De nombreuses solutions GitOps populaires utilisent aujourd'hui principalement Kubernetes comme système d'orchestration. Certains ensembles d'outils alternatifs GitOps arrivent sur le marché et prennent en charge la manipulation directe dans Terraform.
Pour réaliser une installation complète de GitOps, une plateforme de pipeline est requise. Jenkins, Bitbucket Pipelines ou CircleCI sont des outils de pipeline populaires qui complètent GitOps. Pipelines permet d'automatiser et de combler le fossé entre les pull requests Git et le système d'orchestration. Une fois que les hooks de pipeline sont établis et déclenchés à partir de pull requests, les commandes sont exécutées sur le système d'orchestration.
Un nouveau modèle ou composant spécifiquement introduit avec GitOps est « l'opérateur » GitOps. Il s'agit d'un mécanisme qui se trouve entre le pipeline et le système d'orchestration. Une pull request démarre le pipeline qui déclenche ensuite l'opérateur. L'opérateur examine l'état du dépôt et le début de l'orchestration, et il les synchronise. L'opérateur est le composant magique de GitOps.
Exemples de GitOps
Imaginez qu'une équipe identifie un goulot d'étranglement des performances ou un pic de trafic, et qu'elle remarque que l'équilibreur de charge ne fonctionne pas comme prévu. Ses membres consultent le dépôt GitOps qui contient la configuration de l'infrastructure et trouvent un fichier spécifique qui configure et déploie l'équilibreur de charge. Ils peuvent alors le réviser sur leur site d'hébergement Git en ligne. Après revue et discussion, ils constatent que certaines des valeurs de configuration de l'équilibreur de charge ne sont pas optimales et qu'elle doivent être ajustées.
Un membre de l'équipe ouvre une nouvelle pull request qui optimise les valeurs de l'équilibreur de charge. La pull request est révisée et approuvée par un deuxième membre de l'équipe et fusionnée dans le dépôt. Le merge lance un pipeline GitOps, qui déclenche l'opérateur GitOps. L'opérateur constate que la configuration de l'équilibreur de charge a été modifiée. Il confirme avec l'outil d'orchestration des systèmes que cela ne correspond pas à ce qui existe en réalité sur le cluster de l'équipe.
L'opérateur indique au système d'orchestration de mettre à jour la configuration de l'équilibreur de charge. L'orchestrateur s'occupe du reste et déploie automatiquement le nouvel équilibreur de charge configuré. L'équipe surveille ensuite le système réel récemment mis à jour pour s'assurer qu'il revient à un état normal. Il s'agit d'un scénario GitOps idéal. Développons-le davantage pour démontrer l'utilité de GitOps.
Imaginons qu'au lieu de modifier légèrement les valeurs de l'équilibreur de charge pour qu'elles soient plus optimales, l'équipe prend la décision agressive de déployer un tout nouveau type d'équilibreur de charge. Ses membres estiment que l'équilibreur de charge actuel est fondamentalement défectueux et souhaitent essayer une autre option. Le workflow est le même que la modification de la valeur. L'équipe crée une pull request qui introduit une toute nouvelle configuration d'équilibrage de charge et supprime l'ancienne. Elle est approuvée et déployée dans le pipeline.
Malheureusement, l'équipe constate que ce nouveau type d'équilibreur de charge est incompatible avec certains autres services de son cluster. Le nouvel équilibreur de charge provoque des défaillances de trafic critiques et arrête les opérations des utilisateurs. Heureusement, comme l'équipe dispose d'un pipeline GitOps complet, elle peut rapidement annuler ces modifications de l'équilibreur de charge. Elle effectuera une autre pull request qui ramènera le dépôt à l'ancien équilibreur de charge fonctionnel connu. Cela sera à nouveau noté par le pipeline GitOps et déployé automatiquement. Cela permettra d'améliorer rapidement l'infrastructure et d'améliorer le score de fiabilité de l'équipe.
Résumé
GitOps est un modèle de workflow incroyablement puissant pour la gestion d'une infrastructure cloud moderne. Bien que principalement axée sur la gestion des clusters Kubernetes, la communauté DevOps applique et publie des solutions GitOps sur d'autres systèmes non Kubernetes. GitOps peut apporter de nombreux avantages à une équipe d'ingénieurs, notamment une communication, une visibilité, une stabilité et une fiabilité du système améliorées. L'une des principales exigences pour une expérience GitOps est une plateforme Git hébergée moderne telle que Bitbucket.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
