Exercice : créer le pipeline de déploiement

  • 10 minutes

Maintenant que les charts Helm sont créés, vous disposez de tous les outils nécessaires pour déployer l’application sur AKS avec GitHub Actions. Dans cette unité, vous terminez le pipeline CI/CD en effectuant les étapes de déploiement finales.

Diagram that shows the procession from triggers, through three build steps, to the deploy step in a pipeline.

Les étapes de déploiement sont les suivantes :

  • Créer le travail de déploiement.
  • Configurer Open ID Connect (OIDC).
  • Déployer l’application avec Helm.
  • Exécuter le déploiement en production.

Ajouter le travail de déploiement

  1. Dans GitHub, accédez à votre duplication (fork) du référentiel.

  2. Développez le répertoire .github/workflows et ouvrez le fichier build-staging.yml pour modification.

  3. Ajoutez un nouveau travail deploy à la fin du fichier, après le travail build_push_image, comme suit. Veillez à faire correspondre la mise en retrait.

    Le travail a trois clés : runs-on, needs et permissions.

    • Pour runs-on, utilisez ubuntu-20.04 afin d’être cohérent avec l’autre travail.
    • Pour needs, utilisez le nom du premier travail, build_push_image, afin que l’application ne soit déployée qu’une fois l’image générée.
    • Pour permissions, ajoutez deux arguments nommés id-token et contents. Définissez id-token sur write et contents sur read afin d’accorder à GitHub Actions l’accès pour envoyer des requêtes et lire le contenu du dépôt.

  4. Ajoutez - uses: actions/checkout@v2 en guise de première étape du travail.

    Le travail deploy ajouté doit ressembler au code suivant :

          deploy:
        runs-on: ubuntu-20.04
        needs: build_push_image
        permissions:
          id-token: write
          contents: read

        steps:
          - uses: actions/checkout@v2

Ajouter l’étape Installer Helm

Utilisez une action GitHub pour télécharger et installer la version v3.3.1 de Helm.

  1. Dans le volet droit de la page d’édition, recherchez Programme d’installation de l’outil Helm. Sélectionnez le premier résultat publié par Azure.

    Screenshot that shows the search results for the Helm installer action.

  2. Sélectionnez l’icône de copie afin de copier le YAML d’utilisation.

    Screenshot that shows the copy function after selecting the Helm installer action.

  3. Copiez et collez le YAML sous la clé uses dans build-staging.yml.

  4. Remplacez le nom de l’étape Helm tool installer par Install Helm, puis épinglez la clé version à v3.3.1.

        steps:
      - uses: actions/checkout@v2

      - name: Install Helm
        uses: Azure/setup-helm@v1
        with:
          version: v3.3.1

Ajouter l’étape d’authentification de connexion Azure

Utilisez OIDC afin d’authentifier GitHub Actions pour accéder à AKS.

  1. Dans le volet droit, recherchez Connexion Azure et sélectionnez Connexion Azure publié par Azure.

    Screenshot that shows results for the Azure Login search.

  2. Sélectionnez l’icône de copie pour copier le YAML d’utilisation, puis collez-le sous l’étape Install Helm dans build-staging.yml.

  3. Remplacez le nom de l’étape Azure Login par Sign in to Azure with OIDC.

  4. Azure Login nécessite trois paramètres pour s’authentifier : client-id, tenant-id et subscription-id. Remplissez ces paramètres avec des espaces réservés pour les secrets que vous définirez ultérieurement.

          - name: Sign in to Azure with OIDC
        uses: Azure/login@v1.5.1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

  5. Dans le volet droit, recherchez définir le contexte et sélectionnez Définir le contexte Azure Kubernetes publié par Azure.

    Screenshot that shows the results for a Set Context search.

  6. Sélectionnez l’icône de copie pour copier le YAML d’utilisation, puis collez-le sous l’étape Sign in to Azure with OIDC dans build-staging.yml. Renseignez les paramètres resource-group et cluster-name avec des espaces réservés pour les secrets que vous avez définis dans une unité antérieure.

          - name: Azure Kubernetes set context
        uses: Azure/aks-set-context@v3
        with:
          resource-group: ${{ secrets.RESOURCE_GROUP }}
          cluster-name: ${{ secrets.CLUSTER_NAME }}

    Votre fichier build-staging.yml doit ressembler à l’exemple suivant :

    name: Build and push the latest build to staging

    on:
      push:
        branches: [ main ]

    jobs:
      build_push_image:
        runs-on: ubuntu-20.04

        steps:
          - uses: actions/checkout@v2

          - name: Set up Buildx
            uses: docker/setup-buildx-action@v3.0.0

          - name: Docker Login
            uses: docker/login-action@v3.0.0
            with:
              registry: ${{ secrets.ACR_NAME }}
              username: ${{ secrets.ACR_LOGIN }}
              password: ${{ secrets.ACR_PASSWORD }}

          - name: Build and push staging images
            uses: docker/build-push-action@v5.0.0
            with:
              context: .
              push: true
              tags: ${{secrets.ACR_NAME}}/contoso-website:latest

      deploy:
        runs-on: ubuntu-20.04
        needs: build_push_image # Will wait for the execution of the previous job
        permissions:
          id-token: write # This is required for requesting the JWT
          contents: read  # This is required for actions/checkout

        steps:
          - uses: actions/checkout@v2

          - name: Install Helm
            uses: Azure/setup-helm@v1
            with:
              version: v3.3.1

          - name: Sign in to Azure with OIDC
            uses: Azure/login@v1.5.1
            with:
              client-id: ${{ secrets.AZURE_CLIENT_ID }}
              tenant-id: ${{ secrets.AZURE_TENANT_ID }}
              subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

          - name: Azure Kubernetes set context
            uses: Azure/aks-set-context@v3
            with:
              resource-group: ${{ secrets.RESOURCE_GROUP }}
              cluster-name: ${{ secrets.CLUSTER_NAME }}

Configurer Open ID Connect (OIDC)

Affectez des valeurs à vos secrets en créant un principal de service et des certificats pour se connecter avec OIDC.

Créer le principal de service

  1. Dans Azure Cloud Shell, exécutez az account showet enregistrez la valeur id à partir de la sortie.

  2. Créez un principal de service en exécutant la commande suivante, en remplaçant la valeur id de la commande précédente par $SUBSCRIPTION_ID :

    az ad sp create-for-rbac --scopes /subscriptions/$SUBSCRIPTION_ID --role Contributor

  3. Copiez la sortie JSON et enregistrez-la pour l’étape suivante.

Définir les secrets

Sur la page de votre dépôt GitHub, sélectionnez l’onglet Paramètres, puis sélectionnez Secrets et variables>Actions dans le menu de gauche. Définissez les trois nouveaux secrets suivants qui utilisent la sortie des étapes précédentes.

  • AZURE_CLIENT_ID : valeur "appId" de la sortie az ad sp create-for-rbac
  • AZURE_TENANT_ID : valeur "tenant" de la sortie az ad sp create-for-rbac
  • AZURE_SUBSCRIPTION_ID : valeur id de la sortie az account show

Pour chaque secret :

  1. Sélectionnez New repository secret (Nouveau secret de dépôt).
  2. Pour Nom, entrez le nom du secret.
  3. Pour Secret, entrez la valeur.
  4. Sélectionnez Ajouter un secret.

Ajouter des informations d’identification fédérées

Créez des certificats fédérés pour autoriser GitHub Actions à accéder à l’application.

  1. Dans le portail Azure, accédez à Inscriptions d’applications.

  2. Recherchez et sélectionnez l’application qui correspond à la valeur displayName retournée à l’étape az ad sp create-for-rbac précédente. Par défaut, le nom de l’application utilise l’horodatage de la création du principal de service.

  3. Vérifiez que les valeurs ID de l’application (ID client), ID de l’objet (ID d’objet de l’application) et ID de l’annuaire (ID de locataire) correspondent à la sortie JSON précédente.

  4. Dans le menu de navigation de gauche, sélectionnez Certificats et secrets.

  5. Dans l’écran Certificats et secrets, sélectionnez l’onglet Informations d’identification fédérées.

  6. Sélectionnez Ajouter des informations d’identification.

  7. Pour ajouter les informations d’identification intermédiaires, dans l’écran Ajouter des informations d’identification, sélectionnez ou entrez les informations suivantes :

    • Scénario d’informations d’identification fédérées : sélectionnez GitHub Actions déployant des ressources Azure.
    • Organisation : entrez votre nom d’utilisateur GitHub.
    • Dépôt : entrez mslearn-aks-deployment-pipeline-github-actions.
    • Type d’entité : sélectionnez Branche.
    • Nom de la branche GitHub : entrez main.
    • Nom : entrez staging-cred.
    • Description : entrez Tests.

  8. Sélectionnez Ajouter.

    Screenshot of the Add credential screen for the GitHub Actions staging credential.

  9. Pour ajouter les informations d’identification de production, sélectionnez à nouveau Ajouter des informations d’identification et, dans l’écran Ajouter des informations d’identification, entrez toutes les mêmes valeurs que pour les informations d’identification précédentes, sauf :

    • Type d’entité : sélectionnez Balise.
    • Nom de la balise GitHub : entrez v2.0.0, car à l’étape suivante, vous déploierez la version 2.
    • Nom : entrez prod-cred.

  10. Sélectionnez Ajouter.

Déployer l’application avec Helm

Maintenant que vous avez configuré Helm et accordé l’accès à votre cluster, vous êtes prêt à déployer l’application.

Ajouter l’étape Run Helm Deploy

  1. De retour dans le fichier build-staging.yml dans GitHub, après la dernière étape du travail deploy, créez une étape nommée Run Helm Deploy. En dessous, ajoutez une autre clé nomméerun.

              - name: Run Helm Deploy
            run:

  2. Vous pouvez utiliser la clé run pour exécuter n’importe quelle commande shell à l’intérieur du conteneur. Ce pipeline utilise la clé run pour exécuter la commande Helm suivante :

    helm upgrade --install --create-namespace --atomic --wait 
    --namespace staging contoso-website \
    ./kubernetes/contoso-website \
    --set image.repository=${{ secrets.ACR_NAME }} \
    --set dns.name=${{ secrets.DNS_NAME }}

    Comprendre ce que fait chaque paramètre :

    Paramètre Action ou valeur
    helm upgrade Met à niveau une version installée.
    --install Installe la mise en production si elle n’existe pas.
    --create-namespace Crée l’espace de noms dans l’indicateur --namespace s’il n’existe pas.
    --atomic Si la mise en production échoue, supprime toutes les charges de travail installées.
    --wait Attendre la fin de la mise en production et retourne le statut OK.
    --namespace staging contoso-website Déploie la mise en production contoso-website dans l’espace de noms staging.
    ./kubernetes/contoso-website Emplacement du répertoire du chart.
    --set image.repository Met à jour la valeur de la clé image.repository dans le fichier values.yamlpour cette mise en production uniquement.
    --set dns.name Met à jour la clé dns.name dans le fichier values.yamlpour cette mise en production uniquement.

  3. Ajoutez la commande au fichier et définissez-la pour qu’elle s’exécute, en commençant par le caractère |. L’étape Run Helm deploy doit correspondre à cet exemple :

      ...
      - name: Run Helm Deploy
        run: |
          helm upgrade \
            --install \
            --create-namespace \
            --atomic \
            --wait \
            --namespace staging \
            contoso-website \
            ./kubernetes/contoso-website \
            --set image.repository=${{ secrets.ACR_NAME }} \
            --set dns.name=${{ secrets.DNS_NAME }}

    Votre fichier build-staging.yml terminé doit ressembler à l’exemple suivant :

    name: Build and push the latest build to staging

    on:
      push:
        branches: [ main ]

    jobs:
      build_push_image:
        runs-on: ubuntu-20.04

        steps:
          - uses: actions/checkout@v2

          - name: Set up Buildx
            uses: docker/setup-buildx-action@v3.0.0

          - name: Docker Login
            uses: docker/login-action@v3.0.0
            with:
              registry: ${{ secrets.ACR_NAME }}
              username: ${{ secrets.ACR_LOGIN }}
              password: ${{ secrets.ACR_PASSWORD }}

          - name: Build and push staging images
            uses: docker/build-push-action@v5.0.0
            with:
              context: .
              push: true
              tags: ${{secrets.ACR_NAME}}/contoso-website:latest

      deploy:
        runs-on: ubuntu-20.04
        needs: build_push_image # Waits for the execution of the previous job
        permissions:
          id-token: write # Required for requesting the JWT
          contents: read  # Required for actions/checkout

        steps:
          - uses: actions/checkout@v2

          - name: Install Helm
            uses: Azure/setup-helm@v1
            with:
              version: v3.3.1

          - name: Sign in to Azure with OIDC
            uses: Azure/login@v1.5.1
            with:
              client-id: ${{ secrets.AZURE_CLIENT_ID }}
              tenant-id: ${{ secrets.AZURE_TENANT_ID }}
              subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

          - name: Azure Kubernetes set context
            uses: Azure/aks-set-context@v3
            with:
              resource-group: ${{ secrets.RESOURCE_GROUP }}
              cluster-name: ${{ secrets.CLUSTER_NAME }}

          - name: Run Helm Deploy
            run: |
              helm upgrade \
                --install \
                --create-namespace \
                --atomic \
                --wait \
                --namespace staging \
                contoso-website \
                ./kubernetes/contoso-website \
                --set image.repository=${{ secrets.ACR_NAME }} \
                --set dns.name=${{ secrets.DNS_NAME }}

Définir le secret DNS_NAME

  1. Sous un nouvel onglet de navigateur, accédez à votre fourche du dépôt, sélectionnez l’onglet Paramètres, puis sélectionnez Secrets et variables>Actions dans le menu de gauche.

  2. Sélectionnez New repository secret (Nouveau secret de dépôt).

  3. Pour Nom, entrez DNS_NAME.

  4. Pour Secret, entrez la valeur Nom de la zone DNS AKS obtenue à partir de la sortie du script d’installation d’origine.

    Si vous n’avez pas cette valeur, exécutez la commande suivante dans Cloud Shell, en remplaçant <resource-group-name> et <aks-cluster-name> par vos valeurs :

    az aks show -g <resource-group-name> -n <aks-cluster-name> -o tsv --query addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName

  5. Sélectionnez Ajouter un secret.

Commiter les modifications et tester le déploiement intermédiaire

  1. Pour commiter vos modifications, sélectionnez Commiter les modifications. Entrez une description du commit, puis sélectionnez Commiter les modifications.

  2. Sélectionnez l’onglet Actions pour voir la build en cours d’exécution.

  3. Une fois la build réussie, dans votre navigateur, accédez à contoso-staging.<aks-dns-zone-name> pour confirmer que le site web s’affiche.

Exécuter le déploiement en production

L’étape suivante consiste à créer le workflow de production.

  1. Dans le répertoire .github/workflows de votre dépôt, ouvrez le fichier build-production.yml pour modification.

  2. Copiez le travail deploy à partir du pipeline intermédiaire et collez-le sous la dernière ligne du fichier build-production.yml.

  3. Modifiez l’étape Run Helm Deploy pour effectuer le déploiement dans l’espace de noms de production en changeant l’indicateur --namespace de staging en production.

  4. À la fin de la commande Helm, ajoutez un nouveau paramètre, --set image.tag=${GITHUB_REF##*/}.

    Vous utilisez ici une fonctionnalité de Bash appelée expansion de paramètre. L’extension ${ENV##<wildcard><character>} retourne la dernière occurrence de la chaîne après character.

    Dans ce cas, vous souhaitez obtenir uniquement le nom de la balise, qui est représenté par le runtime GitHub Actions, GITHUB_REF. Les branches sont refs/heads/<branch>, tandis que les balises sont refs/tags/<tag>.

    L’idée est de supprimer refs/tags/ pour ne récupérer que le nom de la balise. Vous devez donc passer ${GITHUB_REF##*/} afin de retourner tout ce qui se trouve après le dernier caractère / dans la variable d’environnement GITHUB_REF.

    Votre fichier build-production.yml final doit ressembler à l’exemple suivant :

    name: Build and push the tagged build to production

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read  # This is required for actions/checkout

on:
  push:
    tags:
      - 'v*'

jobs:
  build_push_image:
    runs-on: ubuntu-20.04

    steps:
      - uses: actions/checkout@v2

      - name: Fetch latest version
        id: fetch_version
        run: echo ::set-output name=TAG::${GITHUB_REF#refs/tags/}

      - name: Set up Buildx
        uses: docker/setup-buildx-action@v3.0.0

      - name: Docker Login
        uses: docker/login-action@v3.0.0
        with:
          registry: ${{ secrets.ACR_NAME }}
          username: ${{ secrets.ACR_LOGIN }}
          password: ${{ secrets.ACR_PASSWORD }}

      - name: Build and push production images
        uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: ${{secrets.ACR_NAME}}/contoso-website:latest,${{secrets.ACR_NAME}}/contoso-website:${{ steps.fetch_version.outputs.TAG }}

  deploy:
    runs-on: ubuntu-20.04
    needs: build_push_image

    steps:
      - uses: actions/checkout@v2

      - name: Install Helm
        uses: Azure/setup-helm@v1
        with:
          version: v3.3.1

      - name: Login to Azure with OIDC
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Azure Kubernetes set context
        uses: Azure/aks-set-context@v3
        with:
          resource-group: ${{ secrets.RESOURCE_GROUP }}
          cluster-name: ${{ secrets.CLUSTER_NAME }}

      - name: Run Helm Deploy
        run: |
          helm upgrade \
            --install \
            --create-namespace \
            --atomic \
            --wait \
            --namespace production \
            contoso-website \
            ./kubernetes/contoso-website \
            --set image.repository=${{ secrets.ACR_NAME }} \
            --set dns.name=${{ secrets.DNS_NAME }} \
            --set image.tag=${GITHUB_REF##*/}

  5. Pour commiter vos modifications, sélectionnez Commiter les modifications. Entrez une description du commit, puis sélectionnez Commiter les modifications.

Modifications de production

Chaque fois que vous exécutez le workflow de production, vous devez mettre à jour le certificat fédéré avec la version de balise correspondante, comme ceci :

  1. Dans le portail Azure, accédez à la page de votre application et sélectionnez Certificats et secrets dans le volet de navigation gauche.

  2. Sélectionnez l’onglet Informations d’identification fédérées.

  3. Sélectionnez les informations d’identification prod-cred.

  4. Dans l’écran Modifier des informations d’identification, en regard de En fonction de la sélection, incrémentez le numéro de balise vers un nouveau chiffre v.x.x.x, tel que v.2.0.1.

  5. Sélectionnez Mettre à jour.

  6. Dans Cloud Shell, exécutez git pull pour récupérer les dernières modifications. Exécutez ensuite la commande suivante pour baliser et envoyer (push) les modifications, en remplaçant l’espace réservé par votre nouvelle balise de version :

    git tag -a v<new version tag> -m 'Create new production deployment' && git push --tags

  7. À l’invite, fournissez le PAT des exercices précédents comme mot de passe.

  8. Dans GitHub, ouvrez l’onglet Actions pour voir le processus en cours d’exécution.

  9. Une fois le workflow terminé, pour tester le déploiement de production, accédez à contoso-production.<aks-dns-zone-name>dans votre navigateur et confirmez que le site web s’affiche.

Passez à l’unité suivante pour supprimer vos ressources afin qu’elles ne continuent pas à entraîner des frais.