Le GitOps, qu'est-ce que c'est ?

Le modèle GitOps est un ensemble de pratiques pour la gestion des configurations de l'infrastructure et des applications, qui optimisent les processus existants et améliorent le cycle de vie des applications.

Cette approche repose sur l'utilisation de référentiels Git comme seule source de vérité pour fournir une infrastructure sous forme de code, ou IaC (Infrastructure-as-Code). Cette pratique consiste à gérer et provisionner une infrastructure à l'aide de lignes de code plutôt que de processus manuels. L'IaC implique la création de fichiers de configuration qui contiennent les caractéristiques de l'infrastructure et assurent le provisionnement du même environnement à chaque fois. Il s'agit d'une partie importante de la mise en œuvre des pratiques DevOps et de CI/CD (intégration et distribution continues). 

Avec le GitOps, il est nécessaire de déclarer l'état souhaité du système. Les versions de l'ensemble du code source et des fichiers de configuration peuvent être contrôlées dans Git à l'aide d'outils déclaratifs. Toutes les modifications apportées au code font l'objet d'un suivi, ce qui facilite les mises à jour et le contrôle de versions en cas de restauration.

L'approche GitOps apporte les avantages suivants :

• Un workflow standard pour le développement d'applications
• Une sécurité renforcée grâce à un meilleur niveau de visibilité et d'auditabilité
• Une fiabilité optimisée grâce à la visibilité et au contrôle des versions via Git
• La cohérence entre les clusters, les clouds et les environnements sur site

Découvrir l'opérateur Red Hat OpenShift GitOps

Les approches GitOps et DevOps reposent sur des principes et des objectifs communs. Le DevOps encourage le changement culturel en permettant aux équipes de développement et d'exploitation de travailler ensemble.

Le GitOps fournit des outils et un framework pour adopter les pratiques DevOps, notamment la collaboration, les pipelines de CI/CD et le contrôle des versions, et les applique à l'automatisation de l'infrastructure, au déploiement des applications ainsi qu'aux pratiques d'ingénierie de plateforme, telles que les plateformes de développement interne.

L'ingénierie de plateforme vient compléter les pratiques DevOps en fournissant des outils, services et workflows standardisés qui aident les équipes de développement à créer plus efficacement des solutions logicielles. Ce modèle relativement récent décrit une pratique d'organisation des services et ressources internes, grâce à laquelle les équipes de développement peuvent créer des solutions sans avoir à gérer directement les éléments qui la composent.

Elle s'est imposée comme une approche complémentaire et essentielle pour relever les défis liés à l'adoption du DevOps à grande échelle. Les équipes d'ingénierie de plateforme assurent la création, la maintenance et l'évolution continue d'une plateforme de développement interne. Elles répondent aux besoins des équipes de développement qui sont leurs clients, en leur fournissant des fonctionnalités, outils et services courants et réutilisables, gages de valeur ajoutée. Elles sont l'intermédiaire entre les infrastructures d'entreprise et services back-end requis pour créer et distribuer des applications logicielles et les équipes de développement qui nécessitent un accès fluide. Les principes fondamentaux du modèle GitOps soutiennent également l'ingénierie de plateforme. En effet, ils fournissent une source de vérité unique pour les définitions d'infrastructure et les cycles de vie de développement d'application dont tire parti l'ingénierie de plateforme, et favorisent la collaboration et la coordination entre les équipes. 

L'adoption du GitOps implique un changement de processus, ce qui peut demander un certain temps aux équipes pour s'y adapter. Cette approche nécessite notamment un plus haut niveau de collaboration et de communication. En sollicitant régulièrement l'avis des équipes, il est possible de limiter les potentielles difficultés liées, sans toutefois les éliminer totalement.

Le GitOps reprend la philosophie et les approches de la culture DevOps et fournit un framework pour commencer à obtenir des résultats malgré les difficultés de collaboration et de communication des équipes.

Le GitOps réutilise les workflows basés sur Git que les équipes de développement connaissent déjà, ce qui permet d'appliquer les processus existants en matière de développement au déploiement, à la gestion du cycle de vie des applications et à la configuration de l'infrastructure. Les équipes de développement peuvent travailler dans les référentiels qu'ils utilisent habituellement, tandis que les équipes d'exploitation adoptent les mêmes outils et techniques pour gérer l'infrastructure. Chaque modification apportée tout au long du cycle de vie des applications est retracée dans le référentiel Git et peut être vérifiée.

En apportant des modifications via Git, les équipes de développement ont enfin la possibilité de coder à leur propre rythme, sans attendre l'intervention des équipes d'exploitation pour l'attribution ou l'approbation des ressources.

Pour les équipes d'exploitation, la transparence des changements permet de repérer et reproduire rapidement les problèmes, ce qui renforce la sécurité globale. Avec une piste d'audit à jour, les entreprises peuvent réduire le nombre de modifications non souhaitées et les corriger avant leur mise en production.

Cette possibilité de modifier le code entre le développement et la production permet aux entreprises de répondre de manière plus agile aux évolutions du secteur et du paysage concurrentiel.

De nombreux outils peuvent être utilisés ensemble pour créer un framework GitOps, comme les référentiels Git, la technologie Kubernetes, les outils de CI/CD et les outils de gestion des configurations. Afin de choisir les outils adaptés, les équipes de développement doivent identifier leurs besoins et les fonctions qui leur permettront d'obtenir le résultat souhaité. Voici quelques exemples d'outils :  

Outils d'intégration continue

La pratique de l'intégration continue consiste à intégrer automatiquement et régulièrement les modifications de code dans un référentiel de code source partagé. Au fil des mises à jour, des phases de tests automatisés se lancent afin de garantir la fiabilité des modifications du code fusionné. 

Tekton : framework natif pour Kubernetes qui permet de créer des systèmes de CI/CD. Cet outil apporte aux équipes d'ingénierie et de développement la flexibilité, les meilleures pratiques et la standardisation dont elles ont besoin pour créer, tester et déployer des environnements sur différentes plateformes cloud et dans divers systèmes sur site. 

Jenkins : serveur d'automatisation Open Source basé sur Java. Cet outil permet aux équipes de développement d'intégrer facilement leurs modifications grâce au test, à l'assemblage et au déploiement continus de projets avec un minimum de configuration. Jenkins X est une extension de l'écosystème Jenkins qui facilite l'automatisation des pipelines de CI/CD dans le cloud. 

Outils de distribution continue

L'expression « distribution continue et/ou déploiement continu » désigne un processus en deux volets qui englobe l'intégration, les tests et la distribution des modifications apportées au code. La distribution continue automatise la publication du code validé dans un référentiel à la suite de l'automatisation des versions et des tests unitaires et d'intégration dans le cadre de l'intégration continue. Prolongement de la distribution continue, le déploiement continu peut faire référence au transfert automatique des modifications depuis le référentiel vers l'environnement de production, où elles peuvent être utilisées par les clients.

Argo CD : outil de distribution continue de type déclaratif pour Kubernetes. Cet outil permet aux équipes de développement de déployer et gérer des applications sans maîtriser la technologie Kubernetes de manière détaillée ni disposer d'un accès complet au système Kubernetes. Argo CD surveille les applications en cours d'exécution pour garantir qu'elles présentent toujours l'état souhaité. 

Découvrir Argo CD

Flux : outil GitOps qui automatise le déploiement dans des clusters Kubernetes en synchronisant leur état avec les référentiels Git. Créé sur la base d'extensions de l'API Kubernetes, Flux prend en charge le déploiement d'applications et la gestion de l'infrastructure.

Pour adopter le GitOps, l'infrastructure doit pouvoir être gérée de façon déclarative. C'est pourquoi le GitOps est souvent utilisé comme modèle d'exploitation pour Kubernetes et le développement d'applications cloud-native, et permet également le déploiement continu pour Kubernetes.

Il n'est cependant pas obligatoire de recourir à Kubernetes. L'approche GitOps convient pour d'autres pipelines d'exploitation de l'infrastructure et de déploiement. L'approche GitOps permet de créer des pipelines de développement, de coder des applications, de gérer des configurations, de provisionner des clusters Kubernetes et de mettre en œuvre des déploiements sur Kubernetes ou des registres de conteneurs.

Mettre en œuvre le GitOps avec Red Hat OpenShift

Le GitOps peut être considéré comme une évolution de l'IaC qui utilise Git comme système de contrôle des versions pour les configurations de l'infrastructure. L'IaC respecte généralement une approche déclarative de la gestion de l'infrastructure en définissant l'état souhaité du système et en suivant son état réel.

Avec le GitOps, il est également nécessaire de déclarer l'état souhaité du système. Les versions de l'ensemble du code source et des fichiers de configuration peuvent être contrôlées dans Git à l'aide d'outils déclaratifs.

Les pipelines de CI/CD sont généralement déclenchés par un événement externe (du code transmis à un référentiel, par exemple). Dans le workflow GitOps, des requêtes « pull » entraînent des changements qui modifient l'état du système dans le référentiel Git. 

Le déploiement d'une nouvelle version dans le cadre d'un workflow GitOps s'effectue à l'aide d'une requête « pull » qui vient modifier l'état déclaré du cluster. L'opérateur GitOps détecte la modification et récupère le nouvel état déclaré dans Git.  

Une fois les changements validés et fusionnés, ils sont automatiquement répercutés sur l'infrastructure. Les équipes de développement peuvent continuer à utiliser leur workflow standard et leurs pratiques de CI/CD, car la distribution continue devient la responsabilité du moteur GitOps et peut s'exécuter de manière indépendante ou dans le cadre d'une solution d'intégration continue orchestrée.

L'opérateur utilisé pour le modèle GitOps est souvent un opérateur Kubernetes. L'opérateur compare l'état souhaité qui a été déclaré dans le référentiel avec l'état réel de l'infrastructure déployée, et met à jour l'infrastructure et les applications en cas de différence.

L'observabilité, c'est-à-dire la capacité d'un système à pouvoir être observé, est un concept important du GitOps. Cette capacité permet de vérifier que l'état souhaité et l'état observé (ou état réel) correspondent. L'approche GitOps offre la possibilité d'observer les ressources déployées, mais ne permet pas d'assurer une surveillance globale. C'est là qu'intervient la solution Red Hat® OpenShift® Observability, composée d'outils qui utilisent des indicateurs de mesure, des journaux, des traces et des événements pour dépasser ces limites et mettre en place des boucles de communication entre les systèmes d'applications et les référentiels Git. L'association des pratiques GitOps et de la solution OpenShift Observability permet d'obtenir des données sur les systèmes d'applications via la surveillance, l'analyse et la résolution des problèmes. 

Grâce aux requêtes « pull » et à un système de contrôle des versions tel que Git, les équipes bénéficient d'une bonne visibilité sur le processus de déploiement. Elles peuvent ainsi voir et suivre les changements apportés à un système, accéder à un journal d'audit et restaurer des versions précédentes en cas de problème.

Les workflows GitOps augmentent la productivité et accélèrent le développement et le déploiement, tout en améliorant la stabilité et la fiabilité des systèmes.

En savoir plus sur les workflows GitOps

Nous proposons aux entreprises une gamme de produits qui facilitent la mise en œuvre et l'exécution des workflows GitOps. La solution Red Hat OpenShift offre une plateforme d'applications unifiée que les équipes d'administration peuvent configurer et gérer selon des principes GitOps pour renforcer la cohérence des clusters Kubernetes et des cycles de développement. Cette solution regroupe l'administration et la gestion des applications réparties entre les ressources sur site et dans un cloud public pour :

• vérifier que les clusters présentent des états similaires (configurations, surveillance, stockage), en précisant les contraintes des applications dès le début du cycle de développement ;
• restaurer une modification du code dans plusieurs clusters en récupérant ces derniers à partir d'un état connu ;
• déployer une modification envoyée dans Git sur plusieurs clusters Red Hat OpenShift ;
• associer des configurations modélisées dans le cloud hybride.

L'opérateur Red Hat OpenShift GitOps fournit un workflow qui intègre des référentiels Git, des outils de CI/CD et Kubernetes. Il permet de développer des logiciels de manière plus rapide, sûre et évolutive, sans dégrader la qualité. Il permet également aux entreprises de créer et d'intégrer des workflows de distribution continue déclaratifs et basés sur Git directement sur leur plateforme de développement d'applications. Avant, le pipeline de CI/CD était toujours déployé avec un seul et même outil tel que Jenkins ou Tekton. Désormais, on utilise Jenkins ou Tekton pour la CI et OpenShift GitOps comme moteur de CD. Nous participons à des projets Open Source comme Argo CD afin de mettre en œuvre un framework pour le GitOps. Inclus avec Red Hat OpenShift Platform Plus, l'agent Argo CD Agent permet de faire évoluer la gestion des environnements informatiques composés de clusters multiples tout en profitant toujours de l'expérience unifiée qu'offrent les déploiements centralisés. Après avoir installé l'opérateur Red Hat OpenShift GitOps, les entreprises peuvent développer de nouveaux outils avec Argo pour gérer les workflows GitOps au sein des déploiements Red Hat OpenShift existants.

OpenShift GitOps est disponible pour les services cloud, les solutions autogérées et l'edge computing. Les services cloud gérés tels que Red Hat OpenShift Service on AWS, Microsoft Azure Red Hat OpenShift et Red Hat OpenShift Dedicated permettent aux entreprises d'augmenter l'efficacité opérationnelle, de se recentrer sur l'innovation et de développer, déployer et mettre à l'échelle rapidement des applications. 

Les éditions autogérées d'OpenShift, telles que Red Hat OpenShift Virtualization Engine, sont des versions de Red Hat OpenShift axées sur la virtualisation pour déployer, gérer et mettre à l'échelle des machines virtuelles. Que ce soit pour un environnement géré ou autogéré, nous proposons des méthodes claires pour mettre à jour OpenShift et ainsi garantir que les clusters restent à jour et pris en charge. 

La solution OpenShift GitOps permet le déploiement automatisé de machines virtuelles et peut être associée à OpenShift Virtualization Engine pour aider les utilisateurs à gérer et migrer leurs machines virtuelles, en fonction de leurs besoins en matière de virtualisation. Notre version de MicroShift apporte la puissance et l'évolutivité de Kubernetes à la périphérie du réseau. Cette solution permet aux équipes de développer une version de leurs applications, puis de les exécuter là où elles sont utiles, au plus près de la source de données ou de l'utilisateur final.

Le service Red Hat Advanced Cluster Management for Kubernetes permet la gestion de clusters multiples pour le cycle de vie des clusters Kubernetes. Il repose sur un framework de souscription et de canaux de distribution, ainsi que sur des règles de placement, pour déployer automatiquement des applications dans un modèle d'état souhaité dans plusieurs clusters. Il utilise OpenShift GitOps comme moteur GitOps et inclut des fonctions permettant de gérer des ensembles d'applications, des instances Argo et des configurations de clusters GitOps, ainsi que de déployer des politiques. 

La solution Red Hat Ansible® Automation Platform se charge de faire passer les systèmes à l'état souhaité, quel que soit leur état actuel. Les playbooks Ansible, rédigés en YAML, décrivent l'état souhaité des systèmes. Ils sont généralement stockés dans un système de contrôle de source. Ansible peut considérablement améliorer l'efficacité des workflows GitOps. Dans la mesure où Argo et OpenShift GitOps s'appuient exclusivement sur Kubernetes, l'outil Ansible peut être utilisé pour l'automatisation en dehors de Kubernetes, notamment pour les actions impératives. Grâce à l'intégration des solutions Red Hat Advanced Cluster Management, Red Hat OpenShift GitOps et Red Hat Ansible Automation Platform, les équipes DevOps peuvent gérer les configurations à grande échelle afin d'optimiser les pipelines de CI/CD.

Découvrir des exemples d'application des pratiques GitOps sur Kubernetes