Workflow CI/CD avec GitOps (Flux v2)

Les déploiements Kubernetes modernes contiennent plusieurs applications, clusters et environnements. GitOps vous permet de gérer ces configurations complexes plus facilement, en effectuant le suivi de l’état souhaité des environnements Kubernetes avec Git. En utilisant les outils Git courants pour déclarer l’état des clusters, vous pouvez augmenter la responsabilité, faciliter l’investigation des défaillances et activer l’automatisation pour gérer les environnements.

Cet article décrit comment GitOps s’inscrit dans le cycle de vie complet des modifications d’application avec Azure Arc, Azure Repos et Azure Pipelines. Il fournit également un exemple de changement d’application unique dans des environnements Kubernetes contrôlés par GitOps.

Architecture

Ce diagramme montre le workflow CI/CD pour une application déployée dans un ou plusieurs environnements Kubernetes.

Référentiel du code de l’application

Le référentiel d’application contient le code d’application sur lequel les développeurs travaillent au cours de leur boucle interne. Les modèles de déploiement d’application résident dans ce référentiel sous forme générique, comme Helm ou Kustomize. Les valeurs propres à l’environnement ne sont pas stockées dans le référentiel.

Les modifications apportées à ce référentiel appellent un pipeline de demande de tirage (pull request) ou d’intégration continue qui démarre le processus de déploiement.

Registre de conteneurs

Le registre de conteneurs contient toutes les images internes et tierces utilisées dans les environnements Kubernetes. Les images d’applications internes sont étiquetées avec des étiquettes explicites et le commit Git utilisé pour générer l’image. Les images tierces peuvent être mises en cache pour améliorer la sécurité, la vitesse et la résilience. Définissez un plan à des fins de test et d’intégration en temps opportun des mises à jour de sécurité.

Pour plus d’informations, consultez Comment utiliser et gérer le contenu public à l’aide d’Azure Container Registry Tasks.

Pipeline de demande de tirage (pull request)

Les demandes de tirage (pull requests) des développeurs adressées au référentiel d’application sont contrôlées lors de l’exécution réussie du pipeline de demande de tirage (pull request). Ce pipeline exécute des contrôles de qualité de base, linting et tests unitaires par exemple, sur le code d’application. Le pipeline teste l’application et effectue le linting des Dockerfiles et des modèles Helm utilisés à des fins de déploiement dans un environnement Kubernetes. Les images Docker doivent être générées et testées, mais pas envoyées (push). Optez pour une durée de pipeline relativement courte pour permettre une itération rapide.

Pipeline d’intégration continue

Le pipeline d’intégration continue d’application exécute toutes les étapes du pipeline de demande de tirage (pull request) et développe les contrôles de test et de déploiement. Vous pouvez exécuter le pipeline pour chaque commit sur la branche primaire ou à une cadence régulière avec un groupe de commits.

À ce stade, des tests d’application qui consomment trop d’opérations pour le pipeline PR peuvent être effectués, notamment :

• Envoi d’images vers le registre de conteneurs
• Génération d’images, linting et test
• Génération de modèles de fichiers YAML bruts

À la fin de la build CI, les artefacts sont générés. Ces artefacts peuvent être utilisés par l’étape CD a des fins de consommation en préparation du déploiement.

Extension de cluster Flux

Flux est un agent qui s’exécute dans chaque cluster en tant qu’extension de cluster. Cette extension de cluster Flux est responsable de la maintenance de l’état souhaité. L’agent interroge le référentiel GitOps à un intervalle défini par l’utilisateur, puis rapproche l’état du cluster avec l’état déclaré dans le référentiel Git.

Pour plus d’informations, consultez Tutoriel : Déployer des applications à l’aide de GitOps avec Flux v2.

Pipeline de déploiement continu

Le pipeline de déploiement continu est automatiquement déclenché par les builds d’intégration continue qui ont abouti. Dans cet environnement de pipeline, les valeurs spécifiques à l’environnement sont remplacées dans les modèles publiés précédemment, et une nouvelle demande de tirage est déclenchée sur le référentiel GitOps avec ces valeurs. Cette demande de tirage contient les modifications proposées à l’état souhaité d’un ou plusieurs clusters Kubernetes. Les administrateurs de cluster examinent la demande de tirage de modification de l’état et approuvent la fusion vers le référentiel GitOps. Le pipeline attend la fusion de la demande de tirage, après quoi Flux se synchronise et applique les modifications d’état.

Référentiel GitOps

Le référentiel GitOps représente l’état souhaité actuel de tous les environnements entre les clusters. Toute modification apportée à ce référentiel est récupérée par le service Flux dans chaque cluster et déployée. Les modifications apportées à l’état souhaité des clusters sont présentées sous la forme de demandes de tirage, qui sont ensuite révisées et enfin fusionnées lors de l’approbation des modifications. Ces demandes de tirage contiennent les modifications apportées aux modèles de déploiement et aux manifestes de rendu Kubernetes qui en résultent. Les manifestes de bas niveau permettent une inspection plus minutieuse des modifications généralement invisibles au niveau du modèle.

Connecteur GitOps

Le connecteur GitOps crée une connexion entre l’agent Flux et le pipeline de dépôt GitOps/CD. Pendant que les modifications sont appliquées au cluster, Flux notifie le connecteur GitOps de chaque modification de phase et de chaque contrôle d’intégrité effectué. Ce composant sert d’adaptateur. Il comprend comment communiquer avec un référentiel Git et met à jour l’état du commit Git pour que la progression de la synchronisation soit visible dans le référentiel GitOps. Une fois le déploiement terminé (qu’il réussisse ou échoue), le connecteur indique au pipeline CD de continuer afin que le pipeline puisse effectuer les activités postérieures au déploiement, comme le test d’intégration.

Clusters Kubernetes

Au moins un cluster Kubernetes avec Azure Arc ou un cluster Azure Kubernetes Service dessert les différents environnements dont l’application a besoin. Par exemple, un cluster unique peut desservir un environnement de développement et d’assurance qualité par le biais de différents espaces de noms. Un deuxième cluster permet une séparation plus aisée des environnements et un contrôle plus précis.

Exemple de flux de travail

En tant que développeur d’applications, Alice :

• Écrit le code de l’application.
• Détermine comment exécuter l’application dans un conteneur Docker.
• Définit les modèles qui exécutent le conteneur et les services dépendants dans un cluster Kubernetes.

Alice souhaite s’assurer que l’application peut s’exécuter dans plusieurs environnements, mais elle ne connaît pas les paramètres propres à chaque environnement.

Supposons qu’Alice souhaite apporter une modification d’application qui modifie l’image Docker utilisée dans le modèle de déploiement d’application.

1. Alice modifie le modèle de déploiement, l’envoie (push) à une branche distante appelée alice dans le référentiel de l’application, puis ouvre une demande de tirage pour révision sur la branche main.

2. Alice demande à son équipe de vérifier la modification.

   • Le pipeline de demande de tirage (pull request) exécute la validation.
   • Après l’exécution d’un pipeline de demande de tirage et l’approbation de l’équipe, la modification est fusionnée.

3. Le pipeline d’intégration continue démarre et valide la modification d’Alice et son exécution est menée à bien.

   • La modification peut être déployée en toute sécurité sur le cluster, et les artefacts sont enregistrés dans l’exécution du pipeline d’intégration continue.

4. La réussite de l’exécution d’un pipeline d’intégration continue déclenche le pipeline de déploiement continu.

   • Le pipeline de déploiement continu récupère les artefacts stockés par l’exécution du pipeline d’intégration continue d’Alice.
   • Le pipeline de déploiement continu remplace les modèles par des valeurs spécifiques de l’environnement, et étend les modifications apportées à l’état du cluster existant dans le dépôt GitOps.
   • Le pipeline de déploiement continu crée une demande de tirage sur la branche production du référentiel GitOps avec les modifications souhaitées de l’état du cluster.

5. L’équipe d’Alice vérifie et approuve sa demande de tirage (pull request).

   • La modification est fusionnée dans la branche cible correspondant à l’environnement.

6. En quelques minutes, Flux remarque qu’une modification a été apportée au référentiel GitOps et tire (pull) la modification d’Alice.

   • L’image Docker ayant changé, le pod d’application requiert une mise à jour.
   • Flux applique la modification au cluster.
   • Flux signale l’état du déploiement dans le référentiel GitOps via le connecteur GitOps.

7. Le pipeline de déploiement continu exécute des tests automatisés pour vérifier que le nouveau déploiement s’est terminé correctement et fonctionne comme prévu.

   Remarque

   Pour plus d’environnements ciblés pour le déploiement, le pipeline de déploiement continu itère en créant une demande de tirage (pull request) pour l’environnement suivant et répète les étapes 4 à 7. Le processus requiert une approbation supplémentaire pour les déploiements ou environnements plus risqués, comme une modification liée à la sécurité ou un environnement de production.

8. Lorsque tous les environnements ont reçu des déploiements réussis, le pipeline prend fin.

Étapes suivantes

• Parcourez notre tutoriel pour implémenter CI/CD avec GitOps.
• Découvrez la création de connexions entre votre cluster et un référentiel Git à l’aide de configurations Flux.