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

Le GitOps désigne un ensemble de pratiques de gestion des configurations de l'infrastructure et des applications, qui permettent de développer les processus existants et d'améliorer le cycle de vie des applications.

Cette approche repose sur l'utilisation de référentiels Git comme unique 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 d'intégration et de distribution continues (CI/CD). 

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, clouds et 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 et au déploiement des applications.

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.

L'utilisation de Git pour gérer les modifications permet aux équipes de développement de coder à leur propre rythme, au lieu d'attendre que les équipes d'exploitation attribuent ou approuvent les ressources demandées.

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 fur et à mesure 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 conçu pour 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

La distribution et le déploiement continus désignent un processus en deux volets qui englobe l'intégration, les tests et la distribution des modifications apportées au code. La distribution continue consiste à automatiser la publication du code validé dans un référentiel, suite à 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 renvoyer 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 sur 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. Elle 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 déployer des applications sur Kubernetes ou avec 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 CD devient la responsabilité du moteur GitOps et peut s'exécuter de manière indépendante ou dans le cadre d'une solution de CI 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 entreprises 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 est 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 intégrant des référentiels Git, des outils de CI/CD et Kubernetes. Il permet de développer des logiciels plus rapidement et de manière plus sûre et évolutive, sans sacrifier la qualité. Il permet également aux entreprises de créer et d'intégrer des workflows de CD 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.Grâce à l'opérateur Red Hat OpenShift GitOps, les entreprises peuvent développer de nouveaux outils avec Argo pour gérer le 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é des processus d'exploitation, de se recentrer sur l'innovation et de créer, 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. 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 virtualisation. Notre version de MicroShift apporte la puissance et l'évolutivité de Kubernetes en 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 simultanée du cycle de vie de plusieurs 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é sur 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