Share via

Tutoriel : Implémenter une CI/CD avec GitOps à l’aide de clusters Kubernetes avec Azure Arc

  • Article

Important

Ce tutoriel utilise GitOps avec Flux v1. GitOps avec Flux v2 est désormais disponible pour les clusters AKS (Azure Kubernetes Service) et Kubernetes avec Azure Arc. Accédez au tutoriel pour GitOps avec Flux v2. Nous vous recommandons de migrer vers Flux v2 dès que possible.

La prise en charge des ressources de configuration du cluster basées sur Flux v1, créées avant le 1er janvier 2024, s’achève le 24 mai 2025. À compter du 1er janvier 2024, vous ne pourrez plus créer de ressources de configuration de cluster basées sur Flux v1.

Dans ce tutoriel, vous allez configurer une solution CI/CD à l’aide de GitOps avec des clusters Kubernetes avec Azure Arc. À l’aide de l’exemple d’application Azure Vote, vous allez :

  • Créer un cluster Kubernetes avec Azure Arc.
  • Connecter votre application et les référentiels GitOps à Azure Repos.
  • Importer des pipelines CI/CD.
  • Connecter votre instance d’Azure Container Registry (ACR) à Azure DevOps et Kubernetes.
  • Créer des groupes de variables d’environnement.
  • Déployer les environnements dev et stage.
  • Tester les environnements d’application.

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

Azure Cloud Shell

Azure héberge Azure Cloud Shell, un environnement d’interpréteur de commandes interactif que vous pouvez utiliser dans votre navigateur. Vous pouvez utiliser Bash ou PowerShell avec Cloud Shell pour utiliser les services Azure. Vous pouvez utiliser les commandes préinstallées Cloud Shell pour exécuter le code de cet article sans avoir à installer quoi que ce soit dans votre environnement local.

Pour démarrer Azure Cloud Shell :

Option Exemple/Lien
Sélectionnez Essayer dans le coin supérieur droite d’un bloc de codes ou de commandes. La sélection de Essayer ne copie pas automatiquement le code ni la commande dans Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Accédez à https://shell.azure.com ou sélectionnez le bouton Lancer Cloud Shell pour ouvrir Cloud Shell dans votre navigateur. Button to launch Azure Cloud Shell.
Sélectionnez le bouton Cloud Shell dans la barre de menus en haut à droite du portail Azure. Screenshot that shows the Cloud Shell button in the Azure portal

Pour utiliser Azure Cloud Shell :

  1. Démarrez Cloud Shell.

  2. Sélectionnez le bouton Copier sur un bloc de codes (ou un bloc de commandes) pour copier le code ou la commande.

  3. Collez le code ou la commande dans la session Cloud Shell en sélectionnant Ctrl+Maj+V sur Windows et Linux ou en sélectionnant Cmd+Maj+V sur macOS.

  4. Sélectionnez Entrée pour exécuter le code ou la commande.

Avant de commencer

Ce tutoriel suppose que vous maîtrisez Azure DevOps, Azure Repos et Pipelines, ainsi qu’Azure CLI.

Importer des applications et des référentiels GitOps dans Azure Repos

Importez un référentiel d’application et un référentiel GitOps dans Azure Repos. Pour ce tutoriel, utilisez les exemples de référentiels suivants :

En savoir plus sur l’importation de référentiels Git.

Notes

L’importation et l’utilisation de deux référentiels distincts pour le référentiel d’application et celui GitOps peuvent améliorer la sécurité et la simplicité. Les autorisations et la visibilité du référentiel d’application et celui GitOps peuvent être paramétrées individuellement. Par exemple, l’administrateur de cluster peut considérer que les modifications du code d’application ne sont pas pertinentes pour l’état souhaité du cluster. À l’inverse, un développeur d’applications n’a pas besoin de connaître les paramètres spécifiques de chaque environnement : un ensemble de valeurs de test qui couvrent les paramètres peut suffire.

Connecter le référentiel GitOps

Pour déployer votre application en continu, connectez le référentiel d’application à votre cluster à l’aide de GitOps. Votre référentiel GitOps arc-cicd-demo-gitops contient les ressources de base permettant de faire fonctionner votre application sur votre cluster arc-cicd-cluster.

Le référentiel GitOps initial contient uniquement un manifeste qui crée les espaces de noms dev et stage correspondant aux environnements de déploiement.

La connexion GitOps que vous créez effectuera automatiquement les actions suivantes :

  • Synchroniser les manifestes dans le répertoire de manifestes.
  • Mettre à jour l’état du cluster.

Le workflow CI/CD remplit le répertoire de manifestes avec des manifestes supplémentaires pour déployer l’application.

  1. Créez une nouvelle connexion GitOps à votre référentiel arc-cicd-demo-gitops récemment importé dans Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. Assurez-vous que le flux utilise uniquement le répertoire arc-cicd-cluster/manifests comme chemin de base. Définissez le chemin d’accès à l’aide du paramètre d’opérateur suivant :

    --git-path=arc-cicd-cluster/manifests

    Notes

    Si vous utilisez une chaîne de connexion HTTPS et que vous rencontrez des problèmes de connexion, veillez à omettre le préfixe du nom d’utilisateur dans l’URL. Par exemple, pour https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops, alice@ doit être été supprimé. --https-user spécifie l’utilisateur à la place, par exemple --https-user alice.

  3. Vérifiez l’état du déploiement dans Portail Azure.

    • Si le déploiement est réussi, vous verrez les espaces de noms dev et stage créés dans votre cluster.

Importer des pipelines CI/CD

Maintenant que vous avez synchronisé une connexion GitOps, vous devez importer les pipelines CI/CD qui créent les manifestes.

Le référentiel d’application contient un dossier .pipeline avec les pipelines que vous utiliserez pour les demandes de tirage (PR, pull request), l’intégration continue et le déploiement continu. Importez et renommez les trois pipelines fournis dans l’exemple de référentiel :

Nom du fichier de pipeline Description
.pipelines/az-vote-pr-pipeline.yaml Pipeline PR de l’application, nommé arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Pipeline CI de l’application, nommé arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Pipeline CD de l’application, nommé arc-cicd-demo-src CD

Connecter votre ACR

Vos pipelines et votre cluster utiliseront ACR pour stocker et récupérer les images Docker.

Connecter ACR à Azure DevOps

Pendant le processus d’intégration continue, vous allez déployer vos conteneurs d’application dans un registre. Commencez par créer une connexion au service Azure :

  1. Dans Azure DevOps, ouvrez la page Connexions de service à partir de la page des paramètres du projet. Dans TFS, ouvrez la page Services à partir de l’icône Paramètres dans la barre de menu supérieure.
  2. Choisissez + Nouvelle connexion de service, puis sélectionnez le type de connexion de service dont vous avez besoin.
  3. Renseignez les paramètres de la connexion de service. Pour ce didacticiel :
    • Nommez la connexion de service arc-demo-acr.
    • Sélectionnez myResourceGroup comme groupe de ressources.
  4. Sélectionnez Accorder une autorisation d’accès à tous les pipelines.
    • Cette option autorise les fichiers de pipeline YAML pour les connexions de service.
  5. Choisissez OK pour créer la connexion.

Connecter ACR à Kubernetes

Autorisez votre cluster Kubernetes à extraire des images de votre ACR. S’il est privé, l’authentification est requise.

Connecter ACR à des clusters AKS existants

Intégrez un ACR existant à des clusters AKS existants à l’aide de la commande suivante :

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Créer un secret d’extraction d’image

Pour connecter des clusters non AKS et locaux à votre ACR, créez un secret d’extraction d’image. Kubernetes utilise un secret d’extraction d’image pour stocker les informations nécessaires pour s’authentifier auprès de votre registre.

Créez un secret d’extraction d’image avec la commande kubectl suivante. Répétez l’opération pour les espaces de noms dev et stage.

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Pour éviter d’avoir à définir un imagePullSecret pour chaque pod, envisagez d’ajouter l’imagePullSecret au compte de service dans les espaces de noms dev et stage. Pour plus d’informations, consultez le tutoriel Kubernetes.

Créer des groupes de variables d’environnement

Groupe de variables du référentiel d’application

Créez un groupe de variables nommé az-vote-app-dev. Définissez les valeurs suivantes :

Variable Valeur
AZ_ACR_NAME (votre instance ACR, par exemple .azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (votre connexion au service Azure, qui doit être arc-demo-acr comme indiqué plus haut dans le tutoriel)
AZURE_VOTE_IMAGE_REPO Le chemin d’accès complet au référentiel d’application Azure Vote, par exemple azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Dev
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Nom de votre organisation Azure DevOps
PROJECT_NAME Nom du projet GitOps dans Azure DevOps
REPO_URL URL complète pour le référentiel GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev

Groupe de variables d’environnement stage

  1. Clonez le groupe de variables az-vote-app-dev.
  2. Remplacez le nom par az-vote-app-stage.
  3. Vérifiez les valeurs suivantes pour les variables correspondantes :
Variable Valeur
ENVIRONMENT_NAME Étape
TARGET_NAMESPACE stage

Vous êtes maintenant prêt à déployer sur les environnements dev et stage.

Accorder des autorisations supplémentaires au service de build

Le pipeline CD utilise le jeton de sécurité du build en cours d’exécution pour s’authentifier auprès du référentiel GitOps. Des autorisations supplémentaires sont nécessaires pour que le pipeline crée une branche, envoie des modifications et crée des demandes de tirage (pull).

  1. Accédez à Project settings à partir de la page principale du projet Azure DevOps.
  2. Sélectionnez Repositories.
  3. Sélectionnez <GitOps Repo Name>.
  4. Sélectionnez Security.
  5. Pour <Project Name> Build Service (<Organization Name>), autorisez Contribute, Contribute to pull requests et Create branch.

Pour plus d'informations, consultez les pages suivantes :

Déployer l’environnement dev pour la première fois

Une fois les pipelines CI et CD créés, exécutez le pipeline CI pour déployer l’application pour la première fois.

Pipeline d’intégration continue

Lors de l’exécution initiale du pipeline CI, vous pouvez obtenir une erreur d’autorisation de ressources lors de la lecture du nom de la connexion de service.

  1. Vérifiez que la variable à laquelle vous accédez est AZURE_SUBSCRIPTION.
  2. Autorisez l’utilisation.
  3. Exécutez à nouveau le pipeline.

Le pipeline CI :

  • S’assure que la modification de l’application réussit tous les contrôles de qualité automatisés pour le déploiement.
  • Effectue toute validation supplémentaire qui n’a pas pu être réalisée dans le pipeline PR.
    • Spécifiquement pour GitOps, le pipeline publie également les artefacts pour la validation qui sera déployée par le pipeline CD.
  • Vérifie que l’image Docker a changé et que la nouvelle image est envoyée (push).

Pipeline de déploiement continu

Pendant l’exécution du pipeline CD initial, vous êtes invité à accorder au pipeline l’accès au dépôt GitOps. Sélectionnez Afficher lorsque vous êtes invité à indiquer que le pipeline a besoin de l’autorisation d’accéder à une ressource. Sélectionnez ensuite Autoriser pour accorder l’autorisation d’utiliser le dépôt GitOps pour les exécutions actuelles et futures du pipeline.

L’exécution réussie du pipeline CI déclenche le pipeline CD pour terminer le processus de déploiement. Le déploiement dans chaque environnement se fera de manière incrémentielle.

Conseil

Si le pipeline CD ne se déclenche pas automatiquement :

  1. Vérifiez que le nom correspond au déclencheur de branche dans .pipelines/az-vote-cd-pipeline.yaml.
    • Elle doit avoir la valeur arc-cicd-demo-src CI.
  2. Relancez le pipeline CI.

Une fois que les modifications du modèle et du manifeste du repo GitOps ont été générées, le pipeline de CD crée une validation, l’envoie (push) et crée une PR pour approbation.

  1. Ouvrez le lien PR fourni dans la sortie de la tâche Create PR.

  2. Vérifiez les modifications apportées au référentiel GitOps. Ce qui suit doit s’afficher :

    • Des modifications de haut niveau du modèle Helm.
    • Des manifestes Kubernetes de bas niveau qui montrent les modifications sous-jacentes à l’état souhaité. Flux déploie ces manifestes.

  3. Si tout semble correct, approuvez et terminez la PR.

  4. Après quelques minutes, Flux prend en compte la modification et commence le déploiement.

  5. Transférez le port localement en utilisant kubectl et assurez-vous que l’application fonctionne correctement à l’aide de la commande suivante :

    kubectl port-forward -n dev svc/azure-vote-front 8080:80

  6. Affichez l’application Azure Vote dans votre navigateur à l’adresse http://localhost:8080/.

  7. Votez pour vos favoris et préparez-vous à apporter des modifications à l’application.

Configurer les approbations d’environnement

Lors du déploiement d’une application, vous pouvez non seulement apporter des modifications au code ou aux modèles, mais vous pouvez également mettre involontairement le cluster dans un état incorrect.

Si l’environnement dev révèle un arrêt après le déploiement, empêchez sa progression vers les environnements ultérieurs à l’aide d’approbations d’environnement.

  1. Dans votre projet Azure DevOps, accédez à l’environnement qui doit être protégé.
  2. Accédez à Approbations et vérifications pour la ressource.
  3. Sélectionnez Create (Créer).
  4. Indiquez les approbateurs et un message facultatif.
  5. Sélectionnez à nouveau Créer pour terminer l’ajout de la vérification d’approbation manuelle.

Pour plus d’informations, consultez le tutoriel Définir l’approbation et les vérifications.

La prochaine fois que le pipeline CD s’exécutera, il sera suspendu après la création de la demande de tirage (pull request) de GitOps. Vérifiez que la modification a été correctement synchronisée et qu’elle transmet les fonctionnalités de base. Approuvez la vérification du pipeline pour permettre le passage de la modification à l’environnement suivant.

Effectuer un changement d’application

Avec cet ensemble de ligne de base de modèles et de manifestes représentant l’état du cluster, vous allez apporter une petite modification à l’application.

  1. Dans le dépôt arc-cicd-demo-src, modifiez le fichier azure-vote/src/azure-vote-front/config_file.cfg.

  2. Puisque « Cats vs Dogs » ne reçoit pas suffisamment de votes, remplacez-le par « Tabs vs Spaces » pour augmenter le nombre de votes.

  3. Validez la modification dans une nouvelle branche, envoyez-la (push) et créez une demande de tirage (pull request).

    • Il s’agit du processus de développement classique qui démarrera le cycle de vie CI/CD.

Pipeline de validation de la demande de tirage (pull request)

Le pipeline PR est la première ligne de défense contre une modification défectueuse. Les vérifications habituelles de la qualité du code d’application comprennent le linting et l’analyse statique. Du point de vue de GitOps, vous devez également garantir la même qualité pour l’infrastructure résultante à déployer.

Le Dockerfile et les charts Helm de l’application peuvent utiliser le linting de la même façon que l’application.

Les erreurs trouvées pendant le linting vont de :

  • de fichiers YAML incorrectement formatés à
  • des suggestions de meilleures pratiques, telles que la définition des limites d’UC et de mémoire pour votre application.

Notes

Pour tirer le meilleur parti du linting Helm dans une application réelle, vous devez substituer des valeurs qui sont raisonnablement similaires à celles utilisées dans un environnement réel.

Les erreurs détectées pendant l’exécution du pipeline apparaissent dans la section des résultats du test. Vous pouvez ici :

  • Suivre les statistiques utiles relatives aux types d’erreur.
  • Rechercher la première validation sur laquelle elles ont été détectées.
  • Créer un rapport des appels de procédure des liens de style vers les sections de code qui ont provoqué l’erreur.

Une fois l’exécution du pipeline terminée, vous êtes assuré de la qualité du code de l’application et du modèle qui le déploiera. Vous pouvez maintenant approuver et terminer la PR. Le pipeline CI s’exécutera à nouveau, régénérant les modèles et les manifestes, avant de déclencher le pipeline CD.

Conseil

Dans un environnement réel, n’oubliez pas de définir des stratégies de branche pour garantir que la PR réussit vos vérifications de la qualité. Pour plus d’informations, consultez l’article Définir des stratégies de branche.

Approbations du processus de déploiement continu

Une exécution réussie du pipeline CI déclenche le pipeline CD pour terminer le processus de déploiement. À l’instar de la première fois où vous pouvez utiliser le pipeline CD, le déploiement dans chaque environnement se fera de manière incrémentielle. Cette fois-ci, le pipeline vous demande d’approuver chaque environnement de déploiement.

  1. Approuvez le déploiement dans l’environnement dev.
  2. Une fois que les modifications du modèle et du manifeste du repo GitOps ont été générées, le pipeline de CD crée une validation, l’envoie (push) et crée une PR pour approbation.
  3. Ouvrez le lien PR fourni dans la tâche.
  4. Vérifiez les modifications apportées au référentiel GitOps. Ce qui suit doit s’afficher :
    • Des modifications de haut niveau du modèle Helm.
    • Des manifestes Kubernetes de bas niveau qui montrent les modifications sous-jacentes à l’état souhaité.
  5. Si tout semble correct, approuvez et terminez la PR.
  6. Attendez la fin du déploiement.
  7. En guise de test de vérification de build basique, accédez à la page de l’application et vérifiez que l’application de vote affiche désormais Tabs vs Spaces.
    • Transférez le port localement en utilisant kubectl et assurez-vous que l’application fonctionne correctement à l’aide de la commande suivante : kubectl port-forward -n dev svc/azure-vote-front 8080:80.
    • Affichez l’application Azure Vote dans votre navigateur à l’adresse http://localhost:8080/ et vérifiez que les options de vote sont remplacées par Tabs vs Spaces.
  8. Répétez les étapes 1 à 7 pour l’environnement stage.

Votre déploiement est maintenant terminé. Ceci termine le workflow CI/CD.

Nettoyer les ressources

Si vous ne pensez pas continuer à utiliser cette application, supprimez toutes les ressources en procédant comme suit :

  1. Supprimez la connexion de configuration d’Azure Arc GitOps :

    az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. Supprimez l’espace de noms dev :

    • kubectl delete namespace dev

  3. Supprimez l’espace de noms stage :

    • kubectl delete namespace stage

Étapes suivantes

Dans ce tutoriel, vous avez configuré un workflow CI/CD complet qui implémente DevOps du développement de l’application au déploiement. Les modifications apportées à l’application déclenchent automatiquement la validation et le déploiement, avec des approbations manuelles.

Passez à notre article conceptuel pour en savoir plus sur GitOps et les configurations avec Kubernetes avec Azure Arc.

Workflow CI/CD avec GitOps – Kubernetes avec Azure Arc