Qu’est-ce que GitOps basé sur des agents et en quoi diffère-t-il de CI/CD ? – Informatique CloudSavvy

GitOps est une méthodologie de développement qui préconise l’utilisation de fichiers versionnés dans des référentiels de contrôle de code source pour définir et gérer votre infrastructure. Exprimer votre architecture sous forme de fichiers déclaratifs permet d’inspecter la configuration actuelle de votre système, de fusionner les modifications de plusieurs contributeurs et de revenir à un état antérieur.

Jusqu’à présent, cette approche ressemble à Infrastructure as Code (IaC). GitOps est cependant plus qu’un simple IaC : une implémentation réussie intégrera un automatique mécanisme pour appliquer vos fichiers de configuration aux composants de l’infrastructure en direct. La fusion des modifications devrait entraîner une transition de l’état de votre infrastructure vers celui décrit par le contenu révisé du référentiel.

Cela nécessite un pont entre votre plate-forme de contrôle de source et votre fournisseur d’infrastructure, permettant la communication de l’état actuel entre les deux. Il existe différentes manières de mettre en œuvre ce pont, chacune plaçant un ensemble unique de responsabilités sur les plates-formes impliquées. Dans cet article, nous examinerons le modèle de déploiement basé sur l’agent (ou basé sur l’extraction), puis le comparerons à une approche basée sur le push.

Qu’est-ce qu’un agent ?

GitOps basé sur un agent fait référence à l’exécution d’un processus au sein de votre infrastructure qui facilite vos déploiements. Le processus est chargé de maintenir la communication avec la plate-forme de contrôle de code source qui héberge vos fichiers IaC.

Un agent est un actif partie de votre infrastructure. Il se connectera périodiquement à votre référentiel Git, vérifiera les modifications et extraira de nouveaux commits dans votre environnement de déploiement. L’agent prendra ensuite des mesures pour appliquer les modifications récupérées à son environnement, déclenchant la transition d’état appropriée.

Les agents peuvent fournir des fonctionnalités supplémentaires telles que la surveillance intégrée du déploiement, la journalisation et les alertes. Ceux-ci vous tiennent informés en permanence de l’activité au sein de votre infrastructure. L’agent gère l’intégration avec vos outils existants pour afficher les informations pertinentes aux endroits appropriés.

Le modèle d’agent diffère de la vision conventionnelle de l’intégration continue et du déploiement continu (CI/CD) en supprimant le concept de pipeline lié au déclencheur. Au lieu de cela, il existe une boucle de réconciliation automatisée qui récupère les modifications dès qu’elles sont disponibles. Nouveaux commits et fusions uniquement indirectement provoquer une modification de votre infrastructure. Il peut s’écouler un certain temps avant que l’agent n’acquière les nouvelles données.

Plusieurs fournisseurs proposent des agents qui peuvent être utilisés pour mettre en œuvre des workflows GitOps. GitLab préconise désormais l’approche comme son moyen préféré de déploiement sur Kubernetes, via l’agent GitLab pour Kubernetes. L’agent se connecte à une instance GitLab depuis votre cluster, puis facilite la communication bidirectionnelle pour déployer les modifications et renvoyer les informations à vos référentiels.

Flux by Weaveworks est une autre option qui fonctionne avec n’importe quel référentiel Git et inclut des fonctionnalités d’alerte. Flux est désormais un projet d’incubateur au sein de la Cloud Native Computing Foundation (CNCF). Il fonctionne comme un opérateur Kubernetes qui récupère les modifications apportées à vos référentiels Git connectés.

Avantages des agents

GitOps basé sur des agents présente de multiples avantages qui le rendent attrayant pour une variété de parties prenantes. Il y a d’abord la distinction claire entre les responsabilités : votre plate-forme de contrôle de source est inchangée et n’a pas à se préoccuper des connexions à votre infrastructure. L’agent doit être fourni avec les informations d’identification du référentiel, mais il est par ailleurs autosuffisant. Une fois qu’il est en cours d’exécution, il se concentre étroitement sur la détection et l’application des modifications.

Cette séparation des préoccupations peut vous aider à identifier les problèmes et à justifier les échecs de déploiement. Vous pouvez généralement jeter immédiatement la plate-forme de contrôle de code source. Si c’est le cas et que votre branche principale contient les modifications correctes, les écarts dans l’état réel de votre infrastructure doivent être dus à un problème de synchronisation des agents.

Les agents offrent également un degré d’automatisation plus élevé que les GitOps basés sur Push. Pour adopter avec succès un flux basé sur Push, vous devrez configurer votre référentiel avec des informations d’identification pour votre infrastructure et créer des pipelines CI qui exécutent les scripts appropriés pour transmettre vos modifications. Ces scripts devront être copiés dans tous vos projets, conservés au fil du temps et manipulés avec soin pour protéger vos informations d’identification sensibles.

Les systèmes basés sur des agents ne présentent pas ces problèmes. Une fois qu’un agent est installé, vous bénéficiez d’un modèle de déploiement robuste moins susceptible de changer. Il y a beaucoup moins de variables concernant la connexion à un référentiel Git que l’accès réussi à un environnement de production comme un cluster Kubernetes. Il est donc logique de tirer les changements du système le plus simple vers le plus complexe.

Un autre avantage est l’impact positif des agents sur la sécurité. Ils courent à l’intérieur votre infrastructure afin d’éviter de l’ouvrir à l’extérieur. Bien que vous deviez exposer votre référentiel Git, cela est beaucoup moins risqué que de fournir une porte dans votre environnement de production. L’exposition d’un jeton de projet GitHub est uniquement susceptible de divulguer le code source et vos fichiers IaC – un événement grave mais qui n’a rien à voir avec l’idée de perdre un jeton de compte Kubernetes de production. Cela pourrait entraîner un vol de données, une extorsion ultérieure et une compromission irrécupérable du système.

Qu’en est-il des GitOps basés sur le push ?

La stratégie alternative est le modèle basé sur Push où les changements sont apportés à votre infrastructure par votre plate-forme de contrôle source ou un système intermédiaire. La communication est initiée par quelque chose qui s’exécute en dehors de l’environnement de déploiement. Les poussées forcent l’infrastructure à recevoir un nouvel état du serveur de contrôle.

GitOps basé sur le push est généralement implémenté dans vos pipelines CI. Vous utilisez ce modèle si vous avez un pipeline configuré avec une connexion de cluster Kubernetes et utilisez kubectl apply pour créer des déploiements. Un autre exemple est un pipeline qui s’exécute rsync pour synchroniser le contenu de votre référentiel avec un hôte distant.

Les limites de cette approche résident dans son incapacité à offrir les avantages associés aux agents que nous avons évoqués ci-dessus. Vous devez configurer manuellement chaque référentiel avec une connexion d’infrastructure appropriée, ouvrir vos environnements à un accès externe et assumer la responsabilité de la maintenance de vos scripts de déploiement au fil du temps.

Cependant, GitOps basé sur le push présente encore des avantages uniques. Un facteur important est sa familiarité inhérente : vous pouvez continuer à utiliser les outils que vous connaissez déjà et sur lesquels vous vous appuyez pour le développement, tels que kubectl, helmet docker. Cela permet de minimiser les différences entre les déploiements locaux et en direct.

La gestion des erreurs peut également être plus simple. Les approches basées sur le push ont tendance à se sentir plus synchrones, ce qui peut être utile pour identifier la séquence d’événements menant à un échec. Alors que les agents vous donnent un point de départ clair (l’agent lui-même), il vous reste ensuite à filtrer les événements correspondant aux activités de cet agent. Ces événements peuvent couvrir des dizaines de projets distincts et de cycles de réconciliation. Pouvoir démarrer à partir d’une exécution de pipeline CI spécifique peut donc être utile pour fournir un retour immédiat lors du débogage.

Enfin, il y a un argument selon lequel le modèle basé sur Push est en fait plus adaptable aux futurs changements d’infrastructure. Adopter Pulls signifie que vous couplez votre système aux attentes spécifiques de votre agent sélectionné. Cela peut rapidement compliquer les choses si vous devez déployer sur une nouvelle plate-forme où cet agent n’est pas pris en charge. Une approche basée sur des scripts Push est ici plus flexible. Il vous permet de répondre à plusieurs environnements distincts en incorporant une logique conditionnelle qui prend les bonnes mesures pour la plate-forme cible.

Sommaire

GitOps basé sur un agent fait référence à l’exécution d’un composant actif au sein de votre infrastructure qui accède à votre référentiel source pour récupérer et appliquer les modifications. Cela inverse le modèle basé sur Push où vous exécutez des scripts dans des pipelines CI pour créer des déploiements et appliquer des changements d’état.

Le flux de travail Push est courant, facile à comprendre et présente des attraits importants. Cependant, les « extractions » axées sur les agents attirent de plus en plus l’attention dans l’écosystème du cloud à mesure que les fournisseurs et les développeurs en viennent à reconnaître leurs avantages.

L’adoption d’une approche basée sur l’extraction peut réduire la maintenance au fil du temps, améliorer la sécurité de vos environnements et vous aider à identifier les défaillances lorsque les modifications ne sont pas appliquées. Les agents peuvent également simplifier la configuration de fonctionnalités périphériques telles que les alertes et l’agrégation de métriques, accélérant ainsi votre chemin d’adoption DevOps sans assembler manuellement des scripts CI complexes.