Tutoriel : Implémenter CI/CD avec GitOps (Flux v2)

Article
11/05/2024

Dans ce tutoriel, vous allez configurer une solution de CI/CD à l’aide de GitOps avec Flux v2 et des clusters Kubernetes compatibles avec Azure Arc ou Azure Kubernetes Service (AKS). À l’aide de l’exemple d’application Azure Vote, vous allez :

Créer un cluster Kubernetes avec Azure Arc ou AKS.
Connecter vos référentiels d’application et GitOps à Azure Repos ou GitHub.
Implémenter un flux de CI/CD avec Azure Pipelines ou GitHub.
Connecter votre instance d’Azure Container Registry à Azure DevOps et Kubernetes.
Créer des groupes de variables d’environnement ou des secrets.
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.
Accédez à https://shell.azure.com ou sélectionnez le bouton Lancer Cloud Shell pour ouvrir Cloud Shell dans votre navigateur.
Sélectionnez le bouton Cloud Shell dans la barre de menus en haut à droite du portail Azure.

Pour utiliser Azure Cloud Shell :

Démarrez Cloud Shell.
Sélectionnez le bouton Copier sur un bloc de codes (ou un bloc de commandes) pour copier le code ou la commande.
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.
Sélectionnez Entrée pour exécuter le code ou la commande.

Prérequis

Suivez le tutoriel précédent pour apprendre à déployer GitOps pour votre environnement CI/CD.
Connaissez les avantages et l’architecture de cette fonctionnalité.
Vérifiez que vous disposez des éléments suivants :
- Un cluster Kubernetes avec Azure Arc connecté nommé arc-cicd-cluster.
- Une instance d’Azure Container Registry connectée avec une intégration AKS ou une authentification de cluster non AKS.
Installez les versions les plus récentes des extensions CLI Kubernetes avec Azure Arc et de configuration Kubernetes suivantes :
```
az extension add --name connectedk8s
az extension add --name k8s-configuration
```
- Pour mettre à jour ces extensions vers la dernière version, exécutez les commandes suivantes :
```
az extension update --name connectedk8s
az extension update --name k8s-configuration
```

Connecter Azure Container Registry à Kubernetes

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

Connecter Azure Container Registry à des clusters AKS existants

Intégrez une instance Azure Container Registry existante à 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 instance Azure Container Registry, 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.

Selon l’orchestrateur de CI/CD que vous préférez, vous pouvez suivre les instructions soit pour Azure DevOps, soit pour GitHub.

Implémenter la CI/CD avec Azure DevOps

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

Veillez à effectuer d’abord les étapes suivantes :

Connectez-vous à Azure DevOps Services.
Vérifiez que vous disposez d’autorisations « Administrateur de build » et « Administrateur de projet » pour Azure Repos et Azure Pipelines.

Importer des référentiels d’application et 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 :

Référentiel d’application arc-cicd-demo-src
- URL : https://github.com/Azure/arc-cicd-demo-src
- Contient l’exemple d’application Azure Vote que vous allez déployer à l’aide de GitOps.
- Importer le référentiel avec le nom arc-cicd-demo-src
Référentiel GitOps arc-cicd-demo-gitops
- URL : https://github.com/Azure/arc-cicd-demo-gitops
- Fonctionne comme base pour les ressources de cluster qui hébergent l’application Azure Vote.
- Importer le référentiel avec le nom arc-cicd-demo-gitops

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.

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

az k8s-configuration flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace flux-system \
   --resource-group myResourceGroup \
   -u 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 \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

Conseil

Pour un cluster AKS (plutôt qu’un cluster avec Arc), utilisez -cluster-type managedClusters.

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.
- Vous pouvez également confirmer que dans la page du portail Azure de votre cluster, une configuration cluster-config est créée sous l’onglet fGitOps.

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 dépôt d’applications contient un dossier .pipeline avec les pipelines utilisés pour les demandes de tirage (pull request), l’intégration continue (CI) et le déploiement continu (CD). 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 Azure Container Registry à Azure DevOps

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

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.
Choisissez + Nouvelle connexion de service, puis sélectionnez le type de connexion de service dont vous avez besoin.
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.
Sélectionnez Accorder une autorisation d’accès à tous les pipelines.
- Cette option autorise les fichiers de pipeline YAML pour les connexions de service.
Choisissez OK pour créer la connexion.

Configurer la connexion de service de demande de tirage (pull request)

Le pipeline de CD manipule les demandes de tirage (pull request) dans le référentiel GitOps. Pour ce faire, il a besoin d’une connexion de service. Pour configurer cette connexion :

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.
Choisissez + Nouvelle connexion de service, puis sélectionnez le type Generic.
Renseignez les paramètres de la connexion de service. Pour ce didacticiel :
- URL du serveur https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
- Laissez le nom d’utilisateur et le mot de passe vides.
- Nommez la connexion de service azdo-pr-connection.
Sélectionnez Accorder une autorisation d’accès à tous les pipelines.
- Cette option autorise les fichiers de pipeline YAML pour les connexions de service.
Choisissez OK pour créer la connexion.

Installer le connecteur GitOps

Ajoutez le référentiel du connecteur GitOps aux référentiels Helm :

   helm repo add gitops-connector https://azure.github.io/gitops-connector/

Installez le connecteur sur le cluster :

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=AZDO \
      --set ciCdOrchestratorType=AZDO \
      --set gitOpsOperatorType=FLUX \
      --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
      --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
      --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --set orchestratorPAT=<Azure Repos PAT token>

Notes

Azure Repos PAT token doit avoir les autorisations Build: Read & execute et Code: Full.

Configurez Flux pour envoyer des notifications au connecteur GitOps :

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config 
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Pour plus d’informations sur l’installation, reportez-vous au référentiel du connecteur GitOps.

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
AZURE_SUBSCRIPTION	(votre connexion au service Azure, qui doit être arc-demo-acr comme indiqué plus haut dans le tutoriel)
AZ_ACR_NAME	Nom Azure ACR, par exemple arc-demo-acr
ENVIRONMENT_NAME	Dev
MANIFESTS_BRANCH	`master`
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 du référentiel GitOps
SRC_FOLDER	`azure-vote`
TARGET_CLUSTER	`arc-cicd-cluster`
TARGET_NAMESPACE	`dev`
VOTE_APP_TITLE	Application de vote
AKS_RESOURCE_GROUP	Groupe de ressources AKS. Nécessaire pour les tests automatisés
AKS_NAME	Nom AKS. Nécessaire pour les tests automatisés

Groupe de variables d’environnement stage

Clonez le groupe de variables az-vote-app-dev.
Remplacez le nom par az-vote-app-stage.
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.

Création d’environnements

Dans le projet Azure DevOps, créez les environnements Dev et Stage. Pour plus d’informations, consultez Créer et cibler un environnement.

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).

Accédez à Project settings à partir de la page principale du projet Azure DevOps.
Sélectionnez Repos/Repositories.
Sélectionnez Security.
Pour <Project Name> Build Service (<Organization Name>) et Project Collection Build Service (<Organization Name>) (entrez dans le champ de recherche, si nécessaire), autorisez Contribute, Contribute to pull requests et Create branch.
Accédez à Pipelines/Settings
Désactiver l’option Protect access to repositories in YAML pipelines

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.

Vérifiez que la variable à laquelle vous accédez est AZURE_SUBSCRIPTION.
Autorisez l’utilisation.
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 de déploiement continu (CD) initial, vous devez accorder au pipeline l’accès au dépôt GitOps. Sélectionnez Afficher lorsque vous êtes invité à accorder au pipeline 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 :

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.
Relancez le pipeline CI.

Une fois que les changements du modèle et du manifeste du dépôt GitOps ont été générées, le pipeline de déploiement continu crée un commit, l’envoie (par push) et crée une demande de tirage (pull request) pour approbation.

Recherchez la demande de tirage (pull request) créée par le pipeline dans le référentiel GitOps.
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.
Si tout semble correct, approuvez et terminez la PR.
Après quelques minutes, Flux prend en compte la modification et commence le déploiement.
Supervisez l’état du commit Git sous l’onglet Historique des commits. Une fois qu’il a la valeur succeeded, le pipeline de déploiement continu (CD) commence les tests automatisés.
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/.
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.

Dans votre projet Azure DevOps, accédez à l’environnement qui doit être protégé.
Accédez à Approbations et vérifications pour la ressource.
Sélectionnez Create (Créer).
Indiquez les approbateurs et un message facultatif.
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.

Dans le référentiel arc-cicd-demo-src, modifiez le fichier azure-vote/src/azure-vote-front/config_file.cfg.
Puisque « Cats vs Dogs » ne reçoit pas suffisamment de votes, remplacez-le par « Tabs vs Spaces » pour augmenter le nombre de votes.
Validez la modification dans une nouvelle branche, envoyez-la (push) et créez une demande de tirage (pull request). Cette séquence d’étapes constitue le du processus de développement classique qui démarre le cycle de vie d’intégration continue et de livraison continue (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 détectées pendant le linting vont des fichiers YAML mal mis en forme aux suggestions de bonnes pratiques, comme la définition de limites de processeur 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éploie. 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 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. Cette fois-ci, le pipeline vous demande d’approuver chaque environnement de déploiement.

Approuvez le déploiement dans l’environnement dev.
Une fois que les changements du modèle et du manifeste du dépôt GitOps ont été générées, le pipeline de déploiement continu crée un commit, l’envoie (par push) et crée une demande de tirage (pull request) pour approbation.
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é.
Si tout semble correct, approuvez et terminez la PR.
Attendez la fin du déploiement.
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.
Répétez les étapes 1 à 7 pour l’environnement stage.

Le déploiement est maintenant terminé.

Pour obtenir une présentation détaillée de toutes les étapes et techniques implémentées dans les workflows CI/CD utilisés dans ce tutoriel, consultez le diagramme de flux GitOps pour Azure DevOps.

Implémenter la CI/CD avec GitHub

Ce tutoriel suppose que vous connaissez déjà GitHub et GitHub Actions.

Dupliquer (fork) des référentiels d’application et GitOps

Dupliquez (fork) un référentiel d’application et un référentiel GitOps. Pour ce tutoriel, utilisez les exemples de référentiels suivants :

Référentiel d’application arc-cicd-demo-src
- URL : https://github.com/Azure/arc-cicd-demo-src
- Contient l’exemple d’application Azure Vote que vous allez déployer à l’aide de GitOps.
Référentiel GitOps arc-cicd-demo-gitops
- URL : https://github.com/Azure/arc-cicd-demo-gitops
- Fonctionne comme base pour les ressources de cluster qui hébergent l’application Azure Vote.

Connecter le référentiel GitOps

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.

Créez une nouvelle connexion GitOps à votre référentiel arc-cicd-demo-gitops récemment dupliqué (fork) dans GitHub.

az k8s-configuration flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace cluster-config \
   --resource-group myResourceGroup \
   -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

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.

Installer le connecteur GitOps

Ajoutez le référentiel du connecteur GitOps aux référentiels Helm :

   helm repo add gitops-connector https://azure.github.io/gitops-connector/

Installez le connecteur sur le cluster :

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=GITHUB \
      --set ciCdOrchestratorType=GITHUB \
      --set gitOpsOperatorType=FLUX \
      --set gitHubGitOpsRepoName=arc-cicd-demo-src \
      --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
      --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
      --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
      --set orchestratorPAT=<GitHub PAT token>

Configurez Flux pour envoyer des notifications au connecteur GitOps :

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Pour plus d’informations sur l’installation, reportez-vous au référentiel du connecteur GitOps.

Créer des secrets GitHub

Créer des secrets de référentiel GitHub

Secret	Valeur
AZURE_CREDENTIALS	Informations d’identification pour Azure au format suivant : {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME	Nom Azure ACR, par exemple arc-demo-acr
MANIFESTS_BRANCH	`master`
MANIFESTS_FOLDER	`arc-cicd-cluster`
MANIFESTS_REPO	`https://github.com/your-organization/arc-cicd-demo-gitops`
VOTE_APP_TITLE	Application de vote
AKS_RESOURCE_GROUP	Groupe de ressources AKS. Nécessaire pour les tests automatisés
AKS_NAME	Nom AKS. Nécessaire pour les tests automatisés
Jeton d’accès personnel	Jeton d’accès personnel de GitHub avec l’autorisation d’adresser une demande de tirage (pull request) au référentiel GitOps

Créer des secrets d’environnement GitHub

Créez un environnement az-vote-app-dev en utilisant les secrets suivants :

Secret	Valeur
ENVIRONMENT_NAME	Dev
TARGET_NAMESPACE	`dev`

Créez un environnement az-vote-app-stage en utilisant les secrets suivants :

Secret	Valeur
ENVIRONMENT_NAME	Étape
TARGET_NAMESPACE	`stage`

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

Flux de travail de développement CI/CD

Pour démarrer le workflow de développement CI/CD, modifiez le code source. Dans le référentiel d’application, mettez à jour les valeurs dans le fichier .azure-vote/src/azure-vote-front/config_file.cfg et envoyez (push) les modifications au référentiel.

Le flux de travail de développement CI/CD :

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.
Vérifie que l’image Docker a changé et que la nouvelle image est envoyée (push).
Publie les artefacts (étiquettes d’image Docker, modèles de manifeste, utilitaires) qui seront utilisés par les étapes de CD suivantes.
Déploie l’application dans l’environnement de développement.
- Génère des manifestes dans le dépôt GitOps.
- Crée une demande de tirage (pull request) dans le dépôt GitOps pour approbation.

Recherchez la demande de tirage (pull request) créée par le pipeline dans le référentiel GitOps.
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.
Si tout semble correct, approuvez et terminez la PR.
Après quelques minutes, Flux prend en compte la modification et commence le déploiement.
Supervisez l’état du commit Git sous l’onglet Historique des commits. Une fois qu’il a la valeur succeeded, le workflow CD Stage démarre.
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/.
Votez pour vos favoris et préparez-vous à apporter des modifications à l’application.

Flux de travail de l’étape de CD

Le flux de travail de l’étape de CD démarre automatiquement une fois que Flux a déployé correctement l’application dans l’environnement de développement et notifie GitHub Actions via le connecteur GitOps.

Le flux de travail de l’étape de CD :

Exécute les test de détection de fumée d’application sur l’environnement de développement
Déploie l’application dans l’environnement intermédiaire
- Génère des manifestes dans le référentiel GitOps
- Crée une demande de tirage (pull request) dans le référentiel GitOps pour approbation

Une fois que les demandes de tirage (pull request) des manifestes à l’environnement de préproduction sont fusionnés et que le flux applique correctement tous les changements, l’état du commit Git est mis à jour dans le dépôt GitOps. Le déploiement est maintenant terminé.

Pour obtenir une présentation détaillée de toutes les étapes et techniques implémentées dans les workflows CI/CD utilisés dans ce tutoriel, consultez le diagramme de flux GitOps pour GitHub.

Nettoyer les ressources

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

Supprimez la connexion de configuration d’Azure Arc GitOps :

az k8s-configuration flux delete \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --resource-group myResourceGroup \
      -t connectedClusters --yes

Supprimez le connecteur GitOps :

helm uninstall gitops-connector -n flux-system
kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system

É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.

Concept : processus CD avec GitOps Exemple d’implémentation : Explorer le flux CI/CD avec GitOps

Partage via

Tutoriel : Implémenter CI/CD avec GitOps (Flux v2)

Azure Cloud Shell

Prérequis

Connecter Azure Container Registry à Kubernetes

Connecter Azure Container Registry à des clusters AKS existants

Créer un secret d’extraction d’image

Implémenter la CI/CD avec Azure DevOps

Importer des référentiels d’application et GitOps dans Azure Repos

Connecter le référentiel GitOps

Importer des pipelines CI/CD

Connecter Azure Container Registry à Azure DevOps

Configurer la connexion de service de demande de tirage (pull request)

Installer le connecteur GitOps

Créer des groupes de variables d’environnement

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

Groupe de variables d’environnement stage

Création d’environnements

Accorder des autorisations supplémentaires au service de build

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

Pipeline d’intégration continue

Pipeline de déploiement continu

Configurer les approbations d’environnement

Effectuer un changement d’application

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

Approbations du processus de déploiement continu

Implémenter la CI/CD avec GitHub

Dupliquer (fork) des référentiels d’application et GitOps

Connecter le référentiel GitOps

Installer le connecteur GitOps

Créer des secrets GitHub

Créer des secrets de référentiel GitHub

Créer des secrets d’environnement GitHub

Flux de travail de développement CI/CD

Flux de travail de l’étape de CD

Nettoyer les ressources

Étapes suivantes

Commentaires

Ressources supplémentaires