GitOps décrit une façon d’exploiter et de gérer les logiciels en utilisant des méthodologies ancrées dans le système de contrôle de version Git. L’utilisation de workflows basés sur GitOps facilite le développement, le déploiement, la maintenance et la collaboration sur les logiciels en exigeant que les caractéristiques du système soient définies comme des fichiers dans un dépôt Git.

Le rôle de Git en tant que source unique de vérité est implicite dans la terminologie. Cependant, la mise en œuvre effective de processus axés sur GitOps a toujours été sujette à interprétation. Cette ambiguïté a maintenant été résolue par les normes OpenGitOps, une tentative soutenue par la CNCF de définir les principes qui conduisent à des systèmes GitOps reproductibles.

Dans cet article, nous allons voir quels sont ces principes, pourquoi ils sont importants et comment vous pouvez les utiliser pour créer des logiciels évolutifs et faciles à maintenir. Les normes ont été élaborées à partir des idées de plus de 90 entreprises de premier plan et des parties intéressées au sein du groupe de travail GitOps.

État déclaratif

Le premier principe stipule que tous les systèmes gérés par GitOps doivent avoir leur état exprimé de manière déclarative. Vous devez définir ce à quoi ressemble l’état idéal au moment présent, au lieu de fournir des instructions spécifiques sur la façon d’assembler cet état.

La configuration déclarative sépare l’état souhaité d’un système de la procédure utilisée pour passer à cet état. C’est plus facile à maintenir et à raisonner dans le temps ; les contributeurs n’ont qu’à décrire le système tel qu’il devrait être maintenant, ce qui élimine le besoin d’écrire des migrations qui effectuent des changements d’état.

Le fait de ne pas définir les étapes exactes qui permettent d’atteindre l’état permet de gagner du temps de développement et d’accroître la flexibilité du déploiement. Vous pouvez démarrer une instance de votre application dans un nouvel environnement en appliquant simplement la dernière définition d’état de votre référentiel.

La configuration déclarative est couramment utilisée avec les outils d’infrastructure en tant que code tels qu’Ansible et Terraform. Vous écrivez des fichiers de configuration qui définissent les composants d’infrastructure que vous souhaitez rendre disponibles. Les outils convertissent vos déclarations en appels d’API et en commandes qui provisionnent les ressources nécessaires. La plateforme d’orchestration de conteneurs Kubernetes est un autre exemple de système déclaratif.

Versionné et immuable

Le deuxième principe d’OpenGitOps stipule que l’état de votre système doit être entièrement versionné pendant toute sa durée de vie. C’est là que Git entre vraiment en jeu, en vous permettant de livrer vos fichiers de configuration, de fusionner les changements des autres collaborateurs et de faire évoluer votre état au fil du temps.

Associé à des définitions d’état déclaratives, le versionnage vous offre un moyen garanti de rétablir le système si les choses tournent mal. L’extraction d’un ancien commit et la réapplication de vos fichiers de configuration ramèneront le système à son état à ce moment-là.

Stocker l’état de cette manière permet également de renforcer l’immuabilité. La seule méthode d’application des changements à votre infrastructure doit être la modification des fichiers dans votre référentiel. En suivant ce principe, vous pouvez garantir que l’état du système reflète réellement les déclarations de votre source. La mutation de l’état en modifiant directement les composants de votre infrastructure est à éviter car elle créera des divergences entre l’état réel du système et l’état « souhaité » dans votre référentiel de gestion.

Agents Pull-Based

Le but ultime de GitOps est d’automatiser la gestion des systèmes autant que possible. L’utilisation d’une approche basée sur les flux tirés pour appliquer les changements facilite cette tâche. Les agents s’exécutant dans votre infrastructure doivent périodiquement extraire l’état actuel de votre dépôt Git et appliquer les changements.

Les modèles traditionnels de déploiement par poussée fonctionnent généralement en envoyant les changements à votre infrastructure dans le cadre d’un script de pipeline CI/CD. Même si cela semble automatisé, il s’agit d’une étape supplémentaire qui crée un point de couplage entre votre dépôt de sources et votre infrastructure. Dans un modèle basé sur les flux tirés, un agent à l’intérieur de l’environnement interroge votre référentiel de sources et détecte automatiquement les changements.

Ce modèle crée une infrastructure autosuffisante, moins sensible à la « dérive » de l’état. La dérive se produit lorsque les changements au sein de l’environnement introduisent des divergences par rapport à l’état déclaré par votre référentiel. Dans un modèle de déploiement basé sur le « push », la dérive ne serait pas résolue avant que votre prochaine exécution de script ne déclenche un autre « push ». Les méthodes basées sur les flux tirés minimisent la dérive en interrogeant régulièrement et en réappliquant le dernier état.

L’utilisation d’un agent pull présente également un avantage en termes de sécurité. Les approches basées sur les flux poussés vous obligent à exposer votre infrastructure d’une manière ou d’une autre. Cela est nécessaire pour que votre serveur de contrôle de source puisse envoyer l’état mis à jour et exécuter les commandes qui l’appliquent. En exécutant un agent à l’intérieur de votre infrastructure, vous supprimez la nécessité de fournir une voie d’accès à celle-ci. Vous pouvez renforcer les contrôles de votre pare-feu pour autoriser tout accès externe à l’environnement.

De même, vous n’avez plus besoin de générer les informations d’identification qui permettent d’accéder à votre infrastructure. Une compromission d’un serveur CI utilisé dans un modèle basé sur le push pourrait entraîner une fuite des clés qui sécurisent vos environnements en direct. Inverser ce flux en donnant aux agents pull un jeton d’accès à votre plateforme d’hébergement Git est moins risqué que d’ouvrir vos environnements à un accès externe.

Réconciliation continue

Le dernier principe d’OpenGitOps concerne la réconciliation continue. Ce principe est rendu possible par l’utilisation combinée de définitions d’état déclaratives et d’agents basés sur les flux tirés.

Vos agents surveillent continuellement l’état de vos systèmes. Ils prennent des mesures pour réconcilier les environnements avec l’état déclaré au fur et à mesure que des changements sont apportés ou que la dérive naturelle se produit. Cela contraste avec les modèles traditionnels où les déploiements sont des processus linéaires qui démarrent, exécutent une séquence de commandes et se terminent en laissant l’infrastructure se débrouiller toute seule.

La réconciliation continue identifie les flux de travail GitOps comme des processus dynamiques qui s’adaptent aux conditions changeantes en temps réel. Loin des simples déploiements « set and forget », les agents GitOps sont des composants actifs qui travaillent constamment pour maintenir l’état souhaité. Cela vous permet de terminer la journée en étant sûr que les déploiements fonctionnent toujours comme prévu.

Conclusion

Les principes d’OpenGitOps décrivent quatre traits communs des systèmes qui sont gérés efficacement en utilisant un workflow basé sur GitOps. Ils formalisent les caractéristiques clés des implémentations réussies, offrant un point de référence aux équipes DevOps pour comparer leurs propres systèmes.

Comme le montrent ces principes, GitOps est plus que de simples fichiers de configuration dans un dépôt Git. Il s’agit d’une méthodologie cohérente pour la définition, la mise en œuvre et la maintenance d’un système ; si les dépôts Git sont essentiels pour le versionnage, d’autres composants, tels que les agents logiciels basés sur le principe du « pull », permettent de libérer tout le potentiel de la stratégie.

L’adoption efficace d’un flux de travail GitOps qui intègre les principes d’OpenGitOps peut augmenter le débit, améliorer la santé du déploiement et minimiser le temps passé à exploiter et à maintenir votre infrastructure. Cette approche permet d’inspecter facilement l’état du système et d’apporter ou de retirer des modifications à l’aide de Git et de votre éditeur de code préféré. C’est ensuite à l’agent d’intégration de votre infrastructure de détecter et d’appliquer ces changements, éliminant ainsi l’interaction humaine avec les déploiements et les risques qu’elle comporte.