GitOps at the Edge
Ces deux dernières années, nous avons vu de plus en plus d’entreprises adopter GitOps, une méthodologie DevOps qui utilise Git comme référentiel.
GitOps existe depuis quelques années maintenant, mais il a récemment gagné du terrain en raison des conteneurs et de la complexité entourant le déploiement et la gestion cohérents des environnements d’exécution de conteneurs.
Quel est le problème que GitOps tente de résoudre ? GitOps automatise les opérations logicielles afin que les entreprises puissent s’améliorer dans le domaine de l’ingénierie logicielle. Il permet aux équipes chargées des applications de publier plus fréquemment et d’exploiter les applications cloud natives plus efficacement.
Ce blog aborde la question de l’application de GitOps aux topologies edge, en particulier à la création de pipelines CI/CD permettant de déployer des applications sur des appareils edge éloignés. Rappelons que l’edge englobe les appareils edge jusqu’au cloud, avec l’edge d’entreprise et l’edge réseau tout au long du parcours.
GitOps est une pratique DevOps qui utilise Git comme source unique d’information unique où l’état de configuration souhaité est stocké. 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 :
Essentiellement, le modèle GitOps utilise le modèle de contrôleur. Cette démarche est également facilitée par le modèle d’opérateur du point de vue de Kubernetes ou OpenShift, dans lequel les opérateurs sont des extensions logicielles qui utilisent des ressources personnalisées pour gérer les applications et leurs composants.
Mentionnons également 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) d’applications. Implémenté en tant que contrôleur Kubernetes, Argo CD surveille en permanence les définitions et configurations d’application en cours d’exécution, en comparant l’état actuel du cluster à l’état souhaité défini dans un référentiel 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 : l’infrastructure en tant que code (IaC) est une pratique qui consiste à conserver toute la configuration de l’infrastructure stockée sous forme de code. GitOps utilise un référentiel Git comme source d’information unique pour les définitions d’infrastructure. Git suit toutes les modifications relatives à la gestion du code.
- PRs ou MRs : GitOps utilise les pull requests (PR) ou merge requests (MR) comme mécanisme de changement pour toutes les mises à jour de l’infrastructure. C’est là que les équipes peuvent collaborer via des avis et des commentaires et que les approbations formelles ont lieu.
- 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.
Dans un article de blog précédent, nous avons abordé la question de DevOps dans le domaine de l’edge computing ; ici, nous voyons comment GitOps peut être appliqué dans l’edge computing. Nous avons évoqué les trois facettes de l’edge computing :
- Périphérie d’entreprise (enterprise edge)
- Périphérie du réseau (network edge)
- Appareil de périphérie (device edge ou far edge)
Sans oublier le cloud ou le centre de données de l’entreprise. Examinons ces domaines en détail. Outre les environnements edge, la figure 4 décrit également les trois domaines GitOps : infrastructure, services et application.
Cloud/centre de données de l’entreprise
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).
Périphérie du réseau (network edge)
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 :
Périphérie d’entreprise (enterprise edge)
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 framework 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 ont tout intérêt à utiliser les opérateurs Red Hat OpenShift pour faciliter le déploiement d’applications, la gestion et l’exploitation autonomes des nœuds en périphérie.
Appareil de périphérie (device edge ou far edge)
L’avantage de GitOps est évident à la périphérie du réseau et de l’entreprise. Les appareils « ear edge » présentent un défi différent, car la capacité de stockage et de calcul de certains d’entre eux n’est pas suffisante pour héberger des services GitOps et exécuter des 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.
En utilisant GitOps, vous résolvez les problèmes liés à la prolifération de la configuration de l’infrastructure et des applications. L’opérateur GitOps intégré à Red Hat OpenShift facilite l’implémentation d’un pipeline piloté par Argo CD. Les clients d’IBM Cloud Paks, y compris IBM Cloud Pak for Network Automation, peuvent utiliser les opérateurs Red Hat pour installer des ressources et employer le frameworks GitOps pour automatiser et contrôler le processus de déploiement.
IBM Cloud Native Toolkit est un excellent point de départ. Il s’agit d’une collection d’actifs open source destinés au développement d’applications et au déploiement d’opérations.
Un merci tout particulier à Hollis Chui et Kavitha Bade pour la révision de cet article.