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

Le terme « GitOps » désigne un ensemble de principes destiné à orienter les workflows et qui permet de mettre en œuvre le déploiement continu pour les applications cloud-native. Ce modèle aide les équipes à gérer la configuration des clusters et les déploiements d'applications en appliquant l'automatisation à des processus manuels. Par exemple, le GitOps peut faciliter la gestion des clusters Red Hat^® OpenShift^® Container Platform dans des environnements Kubernetes à plusieurs clusters. Le GitOps automatise les déploiements, qu'ils soient simples ou complexes, ce qui renforce l'efficacité des workflows d'applications.

Le modèle GitOps aide au déploiement des nouvelles applications, ou à la mise à jour des applications existantes. Il suffit de mettre à jour le référentiel, et le workflow GitOps automatise tout le reste. 

Le GitOps convient tout particulièrement aux cas suivants :

• Gestion des déploiements hybrides et multicloud dans des clouds publics et privés
• Gouvernance de plusieurs clusters et gestion du cycle de vie des applications
• Gestion sécurisée des secrets à l'échelle du déploiement

Ces fonctions aident à surmonter les difficultés liées à une approche multicloud, comme le besoin de cohérence, de sécurité et de collaboration lorsque les charges de travail sont déplacées entre différents environnements (de cloud public ou privé, et même sur site). 

Dans le modèle GitOps, le référentiel Git constitue l'unique source de vérité pour la configuration du système et des applications. Il contient une description déclarative de l'infrastructure pour l'environnement, qui fonctionne en tandem avec les processus automatisés gérés par les outils GitOps comme Argo CD. Cette approche d'automatisation permet de s'assurer que l'état réel de l'environnement est bien conforme à l'état décrit. Il est également possible de consulter la liste des changements d'état du système à partir du référentiel, car l'historique Git intègre un suivi des modifications. 

De plus, le stockage de l'infrastructure et des configurations sous forme de code contribue à limiter l'expansion incontrôlée de l'environnement. Les configurations des clusters et applications peuvent en effet être stockées sous forme de code dans des référentiels Git. 

Les entreprises ont besoin de développer, de déployer et d'exploiter leurs applications dans un cloud hybride ouvert de manière stable, simple et sécurisée. Une stratégie hybride, qui intègre des déploiements multicloud, s'avère alors indispensable. 

L'approche multicloud s'accompagne de défis de taille. Par exemple, chaque fournisseur de solutions cloud propose des outils différents, qui ne sont pas tous interopérables. La migration des charges de travail peut alors s'avérer coûteuse et compliquée. Ce manque de portabilité engendre également des risques pour la sécurité et des problèmes de confidentialité des données. 

La technologie Kubernetes permet de relever bon nombre de ces défis. Avec Kubernetes, il est possible d'exécuter plusieurs clusters dans différents environnements cloud, y compris sur site. Les charges de travail peuvent être facilement déplacées d'un environnement à un autre, en évitant les problèmes de migration et de sécurité. 

Avec ce type de déploiement, les charges de travail peuvent être exécutées sur plusieurs clusters et dans différents clouds, privés ou publics. Si cette stratégie permet de résoudre les difficultés mentionnées précédemment, elle nécessite également l'adoption d'une approche de type IaC (Infrastructure as Code). Autrement dit, une stratégie multicloud moderne repose nécessairement sur le GitOps. 

Comme nous l'avons vu, l'approche GitOps repose sur l'utilisation de référentiels Git comme unique source de vérité pour distribuer l'infrastructure en tant que code. Le code soumis passe tout d'abord par un processus d'intégration continue (CI), tandis que les exigences sont vérifiées et appliquées durant le processus de distribution continue (CD). Toutes les modifications apportées au code font l'objet d'un suivi, ce qui facilite le contrôle de versions et la révision. 

Le modèle GitOps favorise donc la collaboration entre les équipes chargées de l'infrastructure afin d'accélérer le développement. Il apporte de la cohérence à l'approche multicloud grâce à des processus automatisés, par opposition aux processus manuels qui peuvent être coûteux et sujets aux erreurs. 

Les entreprises qui mettent en œuvre une approche multicloud ont besoin de cohérence et de sécurité dans tous leurs environnements. Ce qu'il leur faut, c'est une solution GitOps telle que Red Hat OpenShift GitOps.

Red Hat OpenShift GitOps est un opérateur qui se charge de l'installation et de la configuration des instances Argo CD. Il gère la configuration de l'infrastructure et les déploiements d'applications, en organisant le déploiement autour de ces référentiels de configuration. Le processus repose sur deux référentiels fondamentaux :

• Le référentiel de l'application contenant le code source
• Le référentiel de configuration de l'environnement, qui définit l'état souhaité de l'application

Pour gérer les ressources des clusters, Red Hat OpenShift GitOps utilise Argo CD, un outil Open Source utile à l'étape de déploiement continu du processus CI/CD des applications. Argo CD sert de contrôleur pour Red Hat OpenShift GitOps : il surveille les descriptions d'état et les configurations de l'application, telles que définies dans le référentiel Git. Cet outil compare l'état défini et l'état réel, et signale chaque écart de configuration constaté par rapport à la description. 

Les administrateurs peuvent ensuite resynchroniser les configurations avec l'état défini, de façon manuelle ou automatisée. Lors d'une resynchronisation automatisée, la configuration s'« autorépare ».

La solution Red Hat OpenShift GitOps, avec ses processus automatisés, offre de nombreuses possibilités :

• Maintien de la cohérence de l'état des clusters lors des étapes de configuration, surveillance et stockage
• Mise en œuvre de configurations modifiées, ou rétablissement de configurations précédentes, dans plusieurs clusters
• Association de modèles de configuration à plusieurs environnements
• Déploiement d'applications dans plusieurs clusters, jusqu'à la mise en production

Les opérateurs se sont imposés comme la méthode privilégiée pour la mise en paquet, le déploiement et la gestion des services sur le plan de contrôle d'OpenShift Container Platform. L'opérateur GitOps Primer, par exemple, permet d'exporter des objets Kubernetes pour les partager entre plusieurs clusters, équipes et environnements. Le modèle GitOps repose en partie sur ces opérateurs pour renforcer la cohérence, la sécurité et la collaboration dans le cadre d'une approche multicloud. 

Les opérateurs s'intègrent aux API Kubernetes et aux interfaces en ligne de commande pour faciliter la surveillance des applications, les contrôles d'intégrité, la gestion des mises à jour à distance, ainsi que pour s'assurer que l'application reste à l'état souhaité.

La solution OpenShift Container Platform inclut deux types d'opérateurs, gérés par deux systèmes différents :

• Opérateurs de cluster : ces opérateurs sont installés par défaut pour remplir des fonctions de cluster. Ils sont gérés à l'aide de l'outil CVO (Cluster Version Operator).
• Opérateurs complémentaires facultatifs : ces opérateurs peuvent être mis à la disposition des utilisateurs, qui pourront les exécuter dans leurs applications. Ils sont gérés avec l'outil OLM (Operator Lifecycle Manager).

Les opérateurs servent à créer des applications pour la surveillance des services exécutés dans le cluster. Ils mettent en œuvre et automatisent les opérations d'installation et de configuration, ainsi que la mise à l'échelle automatique et la création de sauvegardes. Toutes ces activités sont regroupées dans un composant logiciel qui s'exécute dans le cluster.

Les opérateurs apportent plusieurs avantages :

• Processus reproductibles pour les installations et mises à niveau
• Contrôles d'intégrité constants de chaque composant du système
• Mises à jour à distance des composants OpenShift
• Connaissances accumulées par des ingénieurs qui travaillent sur le terrain, accessibles à tous les utilisateurs

GitOps Primer est un opérateur qui s'exécute sur le cluster OpenShift et permet aux équipes de développement d'exporter tous les objets Kubernetes dans un espace de noms. Grâce au fichier .zip portable généré, il est possible d'effectuer les tâches suivantes :

• Transférer les objets vers un autre cluster
• Partager les objets avec d'autres membres de l'équipe
• Intégrer les objets aux workflows GitOps à l'aide d'Argo CD ou du composant Red Hat Advanced Cluster Management for Kubernetes 

GitOps Primer facilite l'adoption de l'approche IaC que le GitOps apporte au multicloud.

Git fournit une source unique de vérité pour la configuration de l'infrastructure et des applications. Lors de ces deux processus de configuration, les outils GitOps ont besoin d'accéder à des ressources sensibles communément appelées « secrets » (jetons d'authentification, clés privées, etc.).

Le stockage des secrets dans le référentiel Git représente cependant une vulnérabilité pour la sécurité. Cette pratique ne doit pas être tolérée, même si le référentiel est privé et protégé par des contrôles d'accès. Une fois qu'un secret a été transmis en texte simple (ou dans un format facilement réversible), il doit être considéré comme compromis et immédiatement révoqué.

Pour résoudre ce problème, il existe deux grandes approches architecturales de la gestion des secrets pour le GitOps :

• Le chiffrement des secrets
  • Stockage des secrets dans des référentiels Git
  • Déchiffrement et transformation automatisés en secrets Kubernetes
• Le stockage de références de secrets dans des référentiels Git
  • Récupération automatisée des secrets d'après les références
  • Transformation des secrets récupérés en secrets Kubernetes

Pour en apprendre plus sur ces deux approches, consultez l'article de blog A Guide to Secrets Management with GitOps and Kubernetes.

Maintenant que vous avez compris comment fonctionne le GitOps multicloud, vous pouvez apprendre à développer des applications selon ce modèle, avec notamment :

• Argo CD et l'opérateur OpenShift GitOps
• Les vagues de synchronisation et les scripts automatiques
• L'approche CI/CD avec Red Hat Ansible^® Automation Platform et Jenkins sur OpenShift

Voici d'autres articles concernant la solution OpenShift GitOps :

• Un modèle validé, qu'est-ce que c'est ?
• Argo CD, qu'est-ce que c'est ?
• L'approche CI/CD, qu'est-ce que c'est ?