Qu’est-ce que «GitOps» et pourquoi est-ce important? –

GitOps est une approche de l’infrastructure qui prend les meilleures pratiques de développement logiciel et les applique aux systèmes informatiques. GitOps s’appuie sur le modèle Infrastructure as Code pour créer un modèle d’infrastructure automatisé collaboratif et versionné comme votre code.

Une équipe d’opérations moderne lancera régulièrement de nouveaux services pour chaque déploiement. Les instances de conteneur, les bases de données et l’équipement réseau doivent être disponibles pour que les déploiements réussissent.

GitOps définit les ressources à provisionner en tant que fichiers qui existent dans un référentiel Git. Cela permet à tous les membres de l’équipe d’inspecter et de contribuer à l’infrastructure qui sera provisionnée. Vous pouvez utiliser des pipelines CI pour vérifier votre configuration et finalement la pousser vers votre plate-forme cloud.

Un référentiel d’infrastructure finit par ressembler beaucoup à un référentiel de logiciels. Vous créez une branche pour chaque modification, mettez à jour vos fichiers de configuration, effectuez une révision et fusionnez dans votre branche principale. Un outil automatisé, tel qu’Ansible ou Terraform, applique ensuite les modifications à votre environnement. Le flux de travail est le même modèle de branchement versionné que les développeurs utilisent.

Qu’est-ce que Git?

Le Git dans GitOps fait référence au système de contrôle de version de Git. Git est devenu l’outil de contrôle de source de choix pour la plupart des développeurs. Il a un modèle de stockage décentralisé et met l’accent sur l’utilisation d’agences locales pour faire évoluer les changements.

Les systèmes de contrôle de version facilitent l’itération de votre travail. Vous pouvez aborder des composants autonomes en parallèle, à l’aide de branches, avant de fusionner dans une branche principale qui représente la version «publiée» de votre projet. Vous poussez votre code vers un référentiel partagé, souvent sur un service comme GitHub ou GitLab, pour le partager avec d’autres.

Infrastructure déclarative

La plus grande force de GitOps réside dans son rôle de source de vérité. Tout le monde peut découvrir à quoi ressemble votre infrastructure en se référant aux fichiers de votre référentiel Git. Vous aurez un ensemble de fichiers de configuration qui définissent les caractéristiques de votre système.

Les fichiers de configuration sont généralement déclaratif dans la nature – ils décrivent le système au présent. Vous «déclarez» qu’il devrait y avoir cinq serveurs dans votre architecture, au lieu de fournir une liste de commandes qui démarrent directement cinq serveurs. Votre outil de provisioning convertit vos instructions en une séquence de commandes qui déplacent votre infrastructure vers l’état souhaité.

C’est là que l’intégration continue (CI) entre en jeu. Un développeur de logiciels exécutera des pipelines automatisés pour exécuter des tests unitaires, effectuer une analyse statique et, éventuellement, effectuer un déploiement en production. Un pipeline d’équipe d’infrastructure typique vérifiera vos fichiers de configuration pour les erreurs de syntaxe avant de les transmettre à un agent qui applique les modifications à vos systèmes.

Capacité à vérifier

Le fait de pouvoir utiliser des pipelines CI pour appliquer des modifications d’infrastructure vous permet de vérifier que ces modifications fonctionneront réellement comme prévu. GitOps offre également la possibilité d’une vérification continue où les agents de votre infrastructure surveillent en permanence les écarts.

Le référentiel est la seule source de vérité. Il s’ensuit que toute différence observée dans le système réel est une erreur qui doit être corrigée. Un agent ayant accès au référentiel et aux ressources provisionnées peut prendre des mesures pour corriger l’état actuel s’il ne correspond plus à vos déclarations.

GitOps vous aide à observer votre infrastructure. Les fichiers de configuration déclaratifs expliquent comment vos systèmes sont entrés dans leur état actuel. Vous pouvez inspecter les commits Git du référentiel pour comprendre comment l’infrastructure a évolué au fil du temps.

GitOps peut également offrir un moyen d’annuler les changements d’infrastructure. Dans sa forme la plus simple, le retour à un commit précédent restaure une version précédente de vos fichiers de configuration. Cependant, les appliquer en fait peut être difficile. Alors que le code peut être rétabli en écrasant simplement le déploiement actuel, «inverser» la création – ou la suppression – de l’infrastructure est beaucoup moins simple.

Vous devrez évaluer l’agent de déploiement que vous utilisez pour déterminer si les restaurations sont une possibilité réaliste. Si un déploiement sur place n’est pas possible, vous pouvez au moins annuler les validations dans votre référentiel et les redéployer dans un environnement vierge. Vous utiliseriez ensuite vos procédures de restauration pour rétablir vos données.

Défis avec GitOps

Le manque de maturité est le plus gros obstacle à l’adoption de GitOps. Le terme reste opaque pour les équipes d’exploitation qui pourraient être relativement inexpérimentées avec les workflows contrôlés par version.

De nombreuses équipes d’infrastructure seront habituées aux pratiques de travail qu’elles ont perfectionnées au cours des deux dernières décennies. Ils SSH dans les serveurs, apportent leurs modifications et les documentent dans un wiki géré de manière centralisée. C’est incontrôlé, mais c’est simple et ça marche.

GitOps résout le manque de contrôle et peut améliorer la visibilité de l’état des systèmes. En même temps, il y a une courbe d’apprentissage qui implique un flux de travail structuré et un ensemble d’outils très différent. L’accès SSH direct n’est plus approprié. Au lieu de cela, vous apportez des modifications en modifiant les fichiers et en attendant qu’un pipeline CI les applique.

Obtenir l’adhésion des équipes pertinentes peut être le plus gros problème lors de l’introduction de GitOps dans une nouvelle organisation. Soyez prêt à ce que les décideurs comprennent mal où se situe la valeur ou ne la reconnaissent pas complètement. Certains seront frustrés d’avoir à valider, fusionner et demander l’approbation des modifications qu’ils pourraient réaliser manuellement en utilisant une commande SSH rapide. GitOps reste là où DevOps était il y a quelques années, attendant de voir une adoption généralisée en dehors de la littérature technique.

Mis à part le refoulement organisationnel, GitOps présente également des faiblesses pratiques. Un défi commun est le déploiement dans plusieurs environnements différents. Une approche courante consiste à attribuer à chaque environnement sa propre branche dans le référentiel. Cela devient rapidement maladroit si vous avez beaucoup d’environnements. Une approche alternative pourrait être basée sur plusieurs référentiels, peut-être en utilisant des sous-modules Git, mais cela ne fait que déplacer la redondance ailleurs.

GitOps est encore un concept jeune, et il n’y a pas de modèles établis pour son implémentation. Sans architecture de référence, vous devrez expérimenter de manière indépendante. Cela s’ajoute à la liste des inconnues pour les organisations évaluant l’adéquation du modèle.

Résumé

GitOps est une approche de gestion de l’infrastructure informatique qui utilise un référentiel Git comme source de vérité. Vous écrivez des fichiers de configuration déclaratifs qui décrivent les ressources que vous souhaitez provisionner. Un système automatisé prend ces fichiers et les utilise pour faire évoluer l’état de votre infrastructure.

En tant que concept, GitOps a beaucoup de sens. Il réduit l’écart entre les équipes de développement et les équipes opérationnelles en unifiant le flux de travail. Vous bénéficiez d’une plus grande visibilité sur votre infrastructure et de la possibilité d’effectuer des versions et d’auditer les modifications.

Pourtant, GitOps reste difficile à implémenter dans de nombreux cas. Cela nécessite l’adhésion de l’organisation, l’acceptation de certaines inefficacités inhérentes et un engagement à résoudre les problèmes techniques que vous ne prévoyez pas nécessairement. Les organisations qui optent pour GitOps peuvent s’attendre à voir une cohérence et une standardisation plus fortes. Mais pour beaucoup d’autres, les avantages fournis ne sont pas encore une incitation suffisante pour jeter les commandes CLI dans le terminal d’un administrateur système.