GitOps, qu’est-ce que c’est ?

L’accent est mis sur l’automatisation des opérations, pilotée par les référentiels Git. Bien qu’inclus dans le titre, Git n’est pas le seul référentiel qui peut être utilisé. Ce sont les interfaces fournies par Git qui automatisent les opérations. GitOps finit par utiliser les informations extraites des métadonnées de build pour déterminer les paquets à construire déclenchés par un changement de code particulier :

Au cœur du modèle GitOps se trouve l’utilisation du modèle de contrôleur. Cela est en outre facilité par le patron opérateur d’un point de vue Kubernetes ou OpenShift, où les opérateurs sont des extensions logicielles utilisant des ressources personnalisées pour gérer des applications et leurs composants.

Il serait regrettable de ne pas mentionner Argo CD, un outil GitOps qui facilite les workflows GitOps. Argo CD est un outil déclaratif open source pour l’ intégration continue et le déploiement continu (CI/CD) des applications. En tant que contrôleur Kubernetes, Argo CD supervise en permanence les définitions et configurations des applications actives, comparant leur état réel sur le cluster à l’état souhaité tel que défini dans un dépôt Git.

Mais GitOps n’est pas un produit, un plugin ou une plateforme unique. Les workflows GitOps aident les équipes à gérer l’infrastructure informatique via des processus qu’elles utilisent déjà dans l’application. Selon un blog GitLab, GitOps nécessite trois composants principaux : GitOps = IaC + PRs ou MRs + CI/CD

• IaC: Infrastructure as Code (IaC) repose sur la pratique consistant à stocker la totalité des configurations d’infrastructure sous forme de code. GitOps utilise un dépôt Git comme source d’information unique pour les définitions d'infrastructure. Git assure le suivi de toutes les modifications apportées à la gestion du code.
  
  
• PR ou MR : GitOps utilise les pull requests (PR) ou les merge requests (MR) comme mécanisme de changement pour toutes les mises à jour de l’infrastructure. Cet espace permet aux équipes de collaborer via des avis et des commentaires, et constitue le point central des approbations formelles.
  
  
• CI/CD : GitOps automatise les mises à jour de l’infrastructure à l’aide d’un workflow Git avec intégration continue (CI) et livraison continue (CD). Lorsque du nouveau code est fusionné, le pipeline CI/CD exécute la modification dans l’environnement. Toute dérive de configuration, telle que les modifications manuelles ou les erreurs, est remplacée par l’automatisation GitOps, ce qui permet à l’environnement de converger vers l’état souhaité défini dans Git, assurant ainsi des opérations continues (CO) :

Les opérateurs Red Hat OpenShift simplifient l’installation et l’orchestration automatisée des workloads complexes. Ils aident à encoder la logique opérationnelle humaine pour gérer les services exécutés comme des applications natives Kubernetes, facilitant ainsi les opérations jour 2. L’opérateur est un logiciel exécuté dans un pod du cluster, interagissant avec le serveur API Kubernetes. Un opérateur OpenShift est essentiellement un contrôleur personnalisé et, de ce fait, peut être un contrôleur spécifique à une application.

Red Hat OpenShift facilite la tâche des développeurs qui souhaitent utiliser GitOps en fournissant les opérateurs nécessaires. Une fois déployés, ces opérateurs peuvent être consultés dans la section « Opérateurs installés » de la console OpenShift. L’opérateur Red Hat OpenShift GitOps est l’opérateur amont pour ArgoCD, et l’opérateur Red Hat OpenShift Pipelines, également déployé, est l’opérateur amont pour Tekton. Voir la figure 3 :

Les opérateurs et les API associées peuvent ensuite être utilisés pour lancer un ou plusieurs pipelines GitOps pouvant être déployés dans différents environnements en extrayant la configuration souhaitée de Git. Ces environnements peuvent être les environnements classiques de développement, de test et de production, mais peuvent également couvrir des environnements géographiques tels que le cloud d’entreprise, les réseaux de télécommunications ou les nœuds de calcul en périphérie.

Les ressources de déploiement sont classées en trois domaines : infrastructure, services et applications. Ces domaines facilitent la séparation et la gestion du déploiement des ressources connexes :

• Infrastructure : l’endroit où sont définis les espaces de noms et les unités de stockage nécessaires.
• Services : l’endroit où les différents opérateurs nécessaires à la configuration des instances sont décrits.
• Applications : l’endroit où sont répertoriées les applications à déployer.

L’edge computing se traduit par une prolifération des clusters OpenShift ou Kubernetes dans la plupart des centres informatiques. Il a le potentiel d’atteindre une échelle massive de centaines, voire de milliers de déploiements par client. En conséquence, les services informatiques des entreprises doivent gérer de multiples clusters d’exécution de conteneurs indépendants ou coopératifs exécutés sur site et/ou sur des clouds publics.

GitOps offre aux entreprises axées sur l’edge computing et l’IdO l’avantage majeur de pouvoir s’assurer que les clusters ont le même état souhaité (déployer une modification et annuler une modification sur plusieurs clouds).

La méthodologie GitOps est applicable à la périphérie du réseau (network edge) puisque l’un des principaux défis auxquels sont confrontés les fournisseurs de services de communication (CSP) est d’administrer l’orchestration, l’automatisation et la gestion de leurs réseaux. Bien que la 5G soit une aubaine pour les consommateurs, les réseaux définis par logiciel (SDN), le découpage du réseau avec différentes bandes passantes et un déploiement plus rapide compliquent la tâche des opérateurs de télécommunications.

Le pipeline de déploiement automatisé est l’un des moyens par lesquels les CSP peuvent fournir plus rapidement des services aux clients. Disposer d’un référentiel central et d’une approche déclarative pour le provisionnement de l’infrastructure de conteneurs permet d’accélérer la mise sur le marché des nouvelles fonctionnalités et des demandes de modifications. Une telle méthodologie facilitera le provisionnement des VNF (Virtual Network Functions) et des CNF (Cloud-Native Network Functions) à la périphérie du réseau. La conteneurisation des composants du réseau permet de gérer de telles fonctions. Enfin, comme toute l’activité de configuration est enregistrée et stockée dans Git, la capacité de suivre les modifications à des fins de conformité et d’audit est essentielle. Vous trouverez dans les références quelques articles de blog de WeaveWorks à ce sujet :

GitOps permet aux entreprises de déployer sur plusieurs cibles simultanément. Il permet des déploiements ultra-précis. Ce procédé est particulièrement utile pour déployer des applications sur des centaines, voire des dizaines de milliers de nœuds en périphérie aux formes, formats et protocoles de communication différents, notamment dans le cas de petits clusters edge utilisant un processeur Intel NUC ou NVIDIA Jetson.

Le cadre des exigences GitOps s’avère utile pour déployer des applications et utiliser le référentiel Git comme source d’information unique. Les équipes ITOps recherchent le déploiement autonome d’application, la gestion et les opérations des nœuds edge, qui sont facilités par l’utilisation d’opérateurs Red Hat OpenShift.

L’avantage du GitOps est évident en périphérie de réseau et en périphérie d’entreprise. Les dispositifs en périphérie distante constituent un défi distinct, la capacité de stockage et de calcul de certains d’entre eux étant insuffisante pour permettre l’hébergement de services GitOps et l’exécution d’applications.

La publication de distributions Kubernetes légères, telles que K3s et K0s, est destinée aux cas d’utilisation IdO et edge. La possibilité de déployer une distribution Kubernetes légère sur un appareil de périphérie nous permet d’exécuter un outil GitOps comme Argo CD. Les appareils peuvent alors adopter le modèle d’extraction qui consiste à interroger un référentiel Git pour obtenir l’état souhaité et à le synchroniser avec l’état de production du cluster.