Comprendre les principes OpenGitOps pour de meilleurs workflows logiciels – CloudSavvy IT
GitOps décrit une manière d’exploiter et de gérer un logiciel à l’aide de méthodologies enracinées dans le système de contrôle de version Git. L’utilisation de flux de travail basés sur GitOps facilite le développement, le déploiement, la maintenance et la collaboration sur des logiciels en exigeant que les caractéristiques du système soient définies sous forme de fichiers dans un référentiel Git.
Le rôle de Git en tant que source unique de vérité est impliqué par la terminologie. Cependant, la mise en œuvre réelle des processus pilotés par 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 pour définir les principes qui conduisent à des systèmes GitOps reproductibles.
Dans cet article, nous verrons quels sont les principes, pourquoi ils sont importants et comment vous pouvez les utiliser pour créer des logiciels évolutifs et maintenables. Les normes ont été développées en utilisant les informations de plus de 90 entreprises leaders et parties intéressées du groupe de travail GitOps.
Sommaire
1. É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 à 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. Ceci est plus facile à maintenir et plus facile à raisonner au fil du temps ; les contributeurs n’ont qu’à décrire le système tel qu’il devrait apparaître à présentsupprimant le besoin d’écrire des migrations qui effectuent des changements d’état.
Ne pas définir les étapes exactes qui permettent d’atteindre l’état permet de gagner du temps de développement et d’augmenter 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 Infrastructure-as-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 plate-forme d’orchestration de conteneurs Kubernetes est un autre exemple de système déclaratif.
2. Versionné et immuable
Le deuxième principe OpenGitOps stipule que l’état de votre système doit être entièrement versionné tout au long de sa durée de vie. C’est là que Git entre vraiment en jeu, vous permettant de valider vos fichiers de configuration, de fusionner les modifications d’autres collaborateurs et de faire évoluer votre état au fil du temps.
Combinée à des définitions d’état déclaratives, la gestion des versions vous offre un moyen garanti de restaurer le système en cas de problème. 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é. le seul La méthode d’application des modifications à votre infrastructure doit être la modification de fichiers dans votre référentiel. En suivant ce principe, vous pouvez affirmer que l’état du système reflète réellement les déclarations dans votre source. Muter l’état en modifiant directement les composants de votre infrastructure est à éviter car cela créera des décalages entre l’état réel du système et l’état « souhaité » dans votre référentiel de gestion.
3. Agents basés sur l’attraction
Le but ultime de GitOps est d’automatiser au maximum la gestion des systèmes. L’utilisation d’une approche basée sur l’extraction pour appliquer les changements facilite cela. Les agents exécutés au sein de votre infrastructure doivent périodiquement extraire l’état actuel de votre référentiel Git et appliquer les modifications.
Les modèles de déploiement traditionnels basés sur le push fonctionnent généralement en envoyant des modifications à votre infrastructure dans le cadre d’un script de pipeline CI/CD. Même si cela semble être automatisé, c’est une étape supplémentaire qui crée un point de couplage entre votre référentiel source et l’infrastructure. Dans un modèle basé sur l’extraction, un agent à l’intérieur de l’environnement interroge votre référentiel source et détecte automatiquement les modifications.
Ce modèle crée une infrastructure autosuffisante qui est moins sensible à la « dérive » de l’état. La dérive se produit lorsque des modifications au sein de l’environnement introduisent des écarts 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 tant que votre prochaine exécution de script n’initierait pas un autre push. Les méthodes basées sur l’extraction minimisent la dérive en interrogeant régulièrement et en réappliquant le dernier état.
L’utilisation d’un agent pull est également un avantage en matière de sécurité. Les approches basées sur le push 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 code 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 un chemin d’accès à celle-ci. Vous pouvez renforcer les contrôles de votre pare-feu pour autoriser tous les accès externes à l’environnement.
De même, vous n’avez plus besoin de générer des identifiants permettant d’accéder à votre infrastructure. La compromission d’un serveur CI utilisé dans un modèle push pourrait entraîner la fuite des clés qui sécurisent vos environnements en direct. Inverser ce flux en donnant aux agents pull un jeton d’accès pour votre plateforme d’hébergement Git est moins risqué que d’ouvrir vos environnements à un accès externe.
4. Réconciliation continue
Le dernier principe d’OpenGitOps concerne la réconciliation continue. Ceci est rendu possible par l’utilisation combinée de définitions d’état déclaratives avec des agents basés sur l’extraction.
Vos agents surveillent en permanence l’état de vos systèmes. Ils prennent des mesures pour réconcilier les environnements avec l’état déclaré à mesure que des changements sont commis ou qu’une 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 autonome.
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 « définir et oublier », les agents GitOps sont des composants actifs qui travaillent en permanence 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 OpenGitOps décrivent quatre caractéristiques communes des systèmes qui sont gérés efficacement à l’aide d’un flux de travail 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 référentiel Git. Il s’agit d’une méthodologie cohérente pour définir, mettre en œuvre et maintenir un système ; alors que les référentiels Git sont vitaux pour la gestion des versions, d’autres composants tels que les agents logiciels basés sur l’extraction libèrent tout le potentiel de la stratégie.
L’adoption efficace d’un flux de travail GitOps qui intègre les principes OpenGitOps peut augmenter le débit, améliorer la santé du déploiement et réduire le temps passé à exploiter et à entretenir votre infrastructure. L’approche simplifie l’inspection de l’état du système et la réalisation ou l’annulation de modifications à l’aide de Git et de votre éditeur de code préféré. Il appartient ensuite à l’intégration des agents de votre infrastructure de détecter et d’appliquer ces changements, en éliminant l’interaction humaine avec les déploiements et les risques que cela implique.