Tutoriel NGINX : comment utiliser GitHub Actions pour automatiser les déploiements Canary de microservices

Christopher Harrison

Cet article fait partie d’une série de quatre tutoriels qui vous aident à mettre en pratique les concepts de Microservices March 2023 : commencez à déployer des microservices :

• Comment déployer et configurer des microservices
• Comment gérer les secrets de manière sécurisée dans les conteneurs
• Comment utiliser GitHub Actions pour automatiser les déploiements Canary de microservices (cet article)
• Comment utiliser le traçage OpenTelemetry pour comprendre vos microservices

L’automatisation des déploiements est essentielle à la réussite de la plupart des projets. Cependant, il ne suffit pas de déployer votre code. Vous devez également veiller à limiter (voire éliminer) les interruptions de service et être en mesure de revenir rapidement à la version précédente en cas d’échec. La combinaison du déploiement canari et du déploiement bleu-vert est une approche courante pour s’assurer que le nouveau code est viable. Cette stratégie comprend deux étapes :

• Étape 1 : déploiement canari pour effectuer des tests de manière isolée – Déployez votre code sur un nœud, un serveur ou un conteneur isolé, en dehors de votre environnement, puis testez-le pour vous assurer qu’il fonctionne comme prévu.
• Étape 2 : déploiement bleu-vert pour effectuer des tests en production – Si le code fonctionne dans le déploiement Canary, déployez-le sur des serveurs (ou des nœuds ou conteneurs) nouvellement créés dans votre environnement de production, parallèlement aux serveurs de la version actuelle. Redirigez ensuite une partie du trafic de production vers la nouvelle version afin de vérifier qu’elle continue de fonctionner correctement sous une charge plus élevée. Le plus souvent, vous commencez par diriger un faible pourcentage du trafic (10 %, par exemple) vers la nouvelle version, puis vous l’augmentez progressivement jusqu’à ce que celle-ci reçoive l’intégralité du trafic. La taille des paliers dépend de votre degré de confiance dans la capacité de la nouvelle version à gérer le trafic ; vous pouvez même basculer entièrement vers la nouvelle version en une seule étape.

Si vous ne connaissez pas les différents cas d’usage de la répartition du trafic entre plusieurs versions d’une application ou d’un site web (fractionnement du trafic), consultez l’article Comment améliorer la résilience dans Kubernetes grâce à une gestion avancée du trafic sur notre blog afin de mieux comprendre les concepts de déploiement bleu-vert, de publication Canary, de test A/B, de limitation du débit, de disjoncteur et bien plus encore. Bien que cet article porte spécifiquement sur Kubernetes, ces concepts s’appliquent largement aux applications basées sur des microservices.

Présentation du tutoriel

Dans ce tutoriel, nous vous montrons comment automatiser la première étape d’un déploiement bleu-vert avec version Canary à l’aide de GitHub Actions. Au fil des quatre défis du tutoriel, vous utilisez Microsoft Azure Container Apps pour déployer une nouvelle version de votre application, puis Azure Traffic Manager pour transférer le trafic de l’ancien environnement vers le nouveau :

• Créer et déployer une application conteneur NGINX
• Configurer les autorisations pour automatiser les déploiements d’Azure Container Apps
• Créer un déploiement canari bleu-vert avec une GitHub Action
• Tester le workflow GitHub Actions

Remarque : Bien que ce tutoriel utilise Azure Container Apps, les concepts et techniques présentés peuvent s’appliquer à n’importe quel hébergeur cloud.

Prérequis et configuration

Prérequis

Si vous souhaitez suivre ce tutoriel dans votre propre environnement, vous aurez besoin des éléments suivants :

• Un compte Azure. Nous vous recommandons d’utiliser un compte qui n’est pas lié à votre organisation, car vous pourriez rencontrer des problèmes d’autorisations avec un compte professionnel.
• L’interface de ligne de commande Azure.
• La CLI GitHub, si vous souhaitez l’utiliser à la place de l’interface graphique web de GitHub (ou en complément de celle-ci).

Configuration

Créez et configurez les ressources de base nécessaires. Dupliquez et clonez le dépôt du tutoriel, connectez-vous à Azure CLI et installez l’extension pour Azure Container Apps.

1. Dans votre répertoire personnel, créez le répertoire microservices-march. (Vous pouvez également utiliser un autre nom de répertoire et adapter les instructions en conséquence.) Remarque : tout au long du tutoriel, l’invite de commande Linux est omise afin de faciliter le copier-coller des commandes dans votre terminal.

mkdir ~/microservices-marchcd ~/microservices-march

1. Dupliquez (fork) et clonez le dépôt de la plateforme Microservices March sur votre compte GitHub personnel, à l’aide de l’interface en ligne de commande ou de l’interface graphique de GitHub.
   • Si vous utilisez l’interface graphique de GitHub :
     1. Cliquez sur « Fork » dans le coin supérieur droit de la fenêtre, puis sélectionnez votre compte GitHub personnel dans le menu « Owner ».
        
     2. Clonez le dépôt en local en remplaçant par le nom de votre compte <your_GitHub_account>:

git clone https://github.com/<your_GitHub_account>/platform.gitcd platform

• Si vous utilisez l’interface en ligne de commande GitHub, exécutez :

gh repo fork microservices-march/platform -–clone

1. Connectez-vous à Azure CLI. Suivez les instructions pour vous connecter à l’aide d’un navigateur :

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

1. Installez l’extension « containerapp » :

az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.

Défi 1 : créer et déployer une application conteneurisée NGINX

Dans ce premier défi, vous créez une application de conteneur Azure NGINX qui servira de version initiale de l’application et de référence pour le déploiement canari bleu-vert. Azure Container Apps est un service Microsoft Azure qui permet d’exécuter facilement du code applicatif empaqueté dans un conteneur, au sein d’un environnement de conteneurs prêt pour la production.

1. Créez un groupe de ressources Azure pour l’application conteneurisée :

az group create --name my-container-app-rg --location westus{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

1. Déployez le conteneur sur Azure Container Apps (cette étape peut prendre un certain temps) :

az containerapp up --resource-group my-container-app-rg --name my-container-app --source ./ingress --ingress external --target-port 80 --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

1. Dans la sortie de l’étape 2, recherchez le nom et l’URL de l’application conteneur que vous avez créée dans l’Azure Container Registry (ACR). Ils sont surlignés en orange dans l’exemple de sortie. Dans les commandes utilisées tout au long de ce tutoriel, remplacez les variables indiquées par les valeurs de votre sortie (qui seront différentes de celles de l’exemple de sortie de l’étape 2) :
   • Nom de l’application conteneur – Dans la clé image.registry, la chaîne de caractères précédant .azurecr.io. Dans l’exemple de sortie de l’étape 2, il s’agit de cac085021b77acr. Remplacez <ACR_name> par cette chaîne de caractères dans les commandes suivantes.
   • URL de l’application conteneur – L’URL figurant sur la ligne qui commence par Container app created. Dans l’exemple de sortie de l’étape 2, il s’agit de https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/. Remplacez <ACR_URL> par cette URL dans les commandes suivantes.
2. Activez les révisions pour l’application conteneur, comme requis pour un déploiement bleu-vert :

az containerapp revision set-mode --name my-container-app --resource-group my-container-app-rg --mode multiple
"Multiple"

1. (Facultatif) Vérifiez que le déploiement fonctionne en interrogeant le point de terminaison /health dans le conteneur :

curl <ACR_URL>/healthOK

Défi 2 : configurer les autorisations pour automatiser les déploiements d’Azure Container Apps

Dans ce défi, vous obtenez le jeton JSON qui vous permet d’automatiser les déploiements d’applications conteneurisées Azure.

Vous commencez par obtenir l’ID d’Azure Container Registry (ACR), puis l’ID du principal de votre identité managée. Vous attribuez ensuite à l’identité managée le rôle Azure intégré pour ACR et configurez l’application conteneur afin qu’elle utilise cette identité. Enfin, vous obtenez les informations d’identification JSON de l’identité managée, que GitHub Actions utilisera pour s’authentifier auprès d’Azure.

Bien que cette série d’étapes puisse sembler fastidieuse, vous ne devez les effectuer qu’une seule fois lors de la création d’une nouvelle application, et vous pouvez entièrement automatiser le processus à l’aide de scripts. Dans ce tutoriel, vous les effectuez manuellement afin de vous familiariser avec elles.

Remarque : Ce processus de création d’identifiants pour le déploiement est propre à Azure.

1. Recherchez l’ID de principal de votre identité managée. Il apparaît dans la colonne PrincipalID de la sortie (qui est répartie sur deux lignes pour plus de lisibilité). Vous remplacerez <managed_identity_principal_ID> par cette valeur à l’étape 3 :

az containerapp identity assign --name my-container-app --resource-group my-container-app-rg --system-assigned --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

1. Recherchez l’ID de ressource de l’application conteneur dans ACR, en remplaçant <ACR_name> par le nom que vous avez noté à l’étape 3 du Défi 1. Vous remplacerez <ACR_resource_ID> par cette valeur à l’étape suivante :

az acr show --name <ACR_name> --query id --output tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

1. Attribuez le rôle Azure intégré pour ACR à l’identité managée de l’application conteneur, en remplaçant « <managed_identity_principal_ID> » par l’identité managée obtenue à l’étape 1 et « <ACR_resource_ID> » par l’ID de ressource obtenu à l’étape 2 :

az role assignment create --assignee <managed_identity_principal_ID> --role AcrPull --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

1. Configurez l’application conteneur afin qu’elle utilise l’identité managée lors de l’extraction d’images depuis ACR, en remplaçant « <ACR_name> » par le nom de l’application conteneur que vous avez noté à l’étape 3 du Défi 1 (et également utilisé à l’étape 2 ci-dessus) :

az containerapp registry set --name my-container-app --resource-group my-container-app-rg --server <ACR_name>.azurecr.io --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

1. Recherchez votre ID d’abonnement Azure.

az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97c

1. Créez un jeton JSON contenant les informations d’identification à utiliser par l’action GitHub, en remplaçant <subscription_ID> par l’ID de votre abonnement Azure. Enregistrez la sortie afin de la coller comme valeur du secret nommé AZURE_CREDENTIALS dans Ajouter des secrets à votre dépôt GitHub. Vous pouvez ignorer sans risque l’avertissement indiquant que --sdk-auth est obsolète ; il s’agit d’un problème connu :

az ad sp create-for-rbac --name my-container-app-rbac --role contributor --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg --sdk-auth --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Défi 3 : créer une action GitHub de déploiement bleu-vert avec version Canary

Dans ce défi, vous allez ajouter des secrets à votre dépôt GitHub (afin de gérer les données sensibles dans vos workflows GitHub Actions), créer un fichier de workflow GitHub Actions, puis exécuter le workflow GitHub Actions.

Pour une présentation détaillée de la gestion des secrets, consultez le deuxième tutoriel de Microservices March 23, « Comment gérer les secrets de manière sécurisée dans les conteneurs », sur notre blog.

Ajouter des secrets à votre dépôt GitHub

Pour déployer une nouvelle version de l’application, vous devez créer une série de secrets dans le dépôt GitHub que vous avez dupliqué dans la section « Configuration ». Ces secrets correspondent aux identifiants JSON de l’identité managée créée dans le cadre du Défi 2, ainsi qu’à certains paramètres sensibles propres au déploiement, nécessaires pour déployer de nouvelles versions de l’image NGINX sur Azure. Dans la section suivante, vous utiliserez ces secrets dans une GitHub Action afin d’automatiser le déploiement bleu-vert avec version Canary.

• Si vous utilisez l’interface graphique de GitHub :
  1. Accédez au dépôt GitHub que vous avez forké.
  2. Sélectionnez « Settings > Secrets and variables > Actions ».
  3. Cliquez sur « New repository secret ».
  4. Saisissez les valeurs suivantes dans les champs indiqués :
     • Nom – AZURE_CREDENTIALS
     • Secret – Les identifiants JSON obtenus à l’étape 6 du Défi 2
  5. Cliquez sur « Ajouter un secret ».
  6. Répétez trois fois les étapes 3 à 5 pour créer les secrets répertoriés dans le tableau. Saisissez respectivement les valeurs des colonnes Nom du secret et Valeur du secret dans les champs Nom et Secret de l’interface graphique. Pour le troisième secret, remplacez <ACR_name> par le nom attribué à l’application conteneur que vous avez noté à l’étape 3 du Défi 1. Nom du secret Valeur du secretCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>
  7. Passez à « Créer un fichier de workflow GitHub Actions ».
• Si vous utilisez la CLI GitHub :
  1. À la racine de votre dépôt, créez un fichier temporaire.

touch ~/creds.json

1. À l’aide de l’éditeur de texte de votre choix, ouvrez creds.json et copiez-y les identifiants JSON que vous avez créés à l’étape 6 du défi 2.
2. Créez le secret :

gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json

1. Supprimez « creds.json » :

rm ~/creds.json

1. Répétez cette commande pour créer trois secrets supplémentaires :

gh secret set <secret_name> --repo <your_GitHub_account>/platform

1. Pour chaque répétition, remplacez <secret_name> par l’une des valeurs de la colonne Nom du secret du tableau. À l’invite, collez la valeur correspondante de la colonne Valeur du secret. Pour le troisième secret, remplacez <ACR_name> par le nom attribué à l’application conteneur que vous avez noté à l’étape 3 du Défi 1. Nom du secret Valeur du secretCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>

Créer un fichier de workflow GitHub Actions

Une fois l’identité managée et les secrets configurés, vous pouvez créer un fichier de workflow pour une GitHub Action qui automatise le déploiement bleu-vert avec version Canary.

Remarque : Les fichiers de workflow sont définis au format YAML, dans lequel les espaces sont significatifs. Veillez à conserver l’indentation indiquée dans les étapes ci-dessous.

1. Créez un fichier pour le workflow de l’Action.
   • Si vous utilisez l’interface graphique de GitHub :
     1. Accédez à votre dépôt GitHub.
     2. Sélectionnez « Actions > New workflow > Skip this and set up a workflow yourself ».
   • Si vous utilisez la CLI GitHub, créez le répertoire « .github/workflows », puis créez un fichier nommé « main.yml » :

mkdir .github/workflowstouch .github/workflows/main.yml

1. À l’aide de votre éditeur de texte préféré, ajoutez le contenu du workflow dans le fichier « main.yml ». La méthode la plus simple consiste à copier le texte figurant dans « Fichier complet du workflow ». Vous pouvez également créer le fichier manuellement en ajoutant les extraits de code annotés à cette étape. Remarque : les fichiers de workflow sont définis au format YAML, dans lequel les espaces sont significatifs. Si vous copiez les extraits de code, veillez à conserver l’indentation (et, pour plus de sûreté, comparez votre fichier au « Fichier complet du workflow »).
   • Définissez le nom du workflow :

name: Deploy to Azure

• Configurez le workflow pour qu’il s’exécute lorsqu’un push ou une pull request est effectué sur la branche principale :

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

• Dans la section jobs, définissez le job build-deploy, qui récupère le code, se connecte à Azure et déploie l’application sur Azure Container Apps :

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

• Définissez le job test-deployment, qui récupère l’URL de préproduction de la révision nouvellement déployée et utilise une GitHub Action pour interroger le point de terminaison de l’API /health afin de vérifier que la nouvelle révision répond. Si le contrôle d’intégrité réussit, Azure Traffic Manager est mis à jour sur l’application conteneur afin de diriger tout le trafic vers le conteneur nouvellement déployé. Remarque : veillez à mettre en retrait la clé test-deployment au même niveau que la clé build-deploy définie dans le point précédent :

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Fichier de workflow complet

Voici le texte complet du fichier de workflow de l’Action.

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} 
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Exécuter le workflow de l’action

• Si vous utilisez l’interface graphique de GitHub :
  1. Cliquez sur « Start commit », ajoutez un message de commit si vous le souhaitez, puis sélectionnez « Commit new file » dans la boîte de dialogue. Le nouveau fichier de workflow est fusionné dans la branche principale et son exécution commence.
  2. Cliquez sur « Actions » pour suivre la progression du workflow.
• Si vous utilisez la CLI GitHub :
  1. Ajoutez « main.yml » à la zone de préparation de Git :

git add .github/workflows/main.yml

1. Validez le fichier :

git commit -m "feat: create GitHub Actions workflow"

1. Envoyez vos modifications sur GitHub :

git push

1. Suivez la progression du workflow :

gh workflow view main.yml --repo <your_GitHub_account>/platform

Défi 4 : tester le workflow GitHub Actions

Dans ce défi, vous testez le workflow. Vous simulez d’abord une mise à jour réussie de votre équilibreur de charge Ingress et vérifiez que l’application a bien été mise à jour. Vous simulez ensuite l’échec d’une mise à jour (qui entraîne une erreur interne du serveur) et vérifiez que l’application publiée reste inchangée.

Effectuer une mise à jour réussie

Créez une mise à jour réussie et observez le bon déroulement du workflow.

• Si vous utilisez l’interface graphique de GitHub :
  1. Sélectionnez « Code > ingress > default.conf.template ».
  2. Ouvrez « default.conf.template » pour le modifier en sélectionnant l’icône en forme de crayon dont l’infobulle indique « Modifier ce fichier ».
  3. Dans le bloc location /health situé vers la fin du fichier, modifiez la directive return comme indiqué :

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

1. Dans la boîte de dialogue, sélectionnez « Créer une branche pour ce commit et lancer une demande de tirage », puis « Proposer les modifications ».
2. Cliquez sur « Créer une pull request » pour accéder au modèle de pull request.
3. Cliquez à nouveau sur « Créer une pull request » pour créer la pull request.
4. Cliquez sur « Actions » pour suivre la progression du workflow.
5. Une fois le workflow terminé, accédez à votre application conteneur via le point de terminaison <ACR_URL>/health, où <ACR_URL> correspond à l’URL que vous avez notée à l’étape 3 du Défi 1. Vous remarquerez le message « Successful Update! ».
6. Vous pouvez confirmer le message en ouvrant une session de terminal et en envoyant une requête de contrôle d’intégrité à l’application, en remplaçant à nouveau « <ACR_URL> » par la valeur que vous avez notée à l’étape 3 du défi 1 :

curl <ACR_URL>/healthSuccessful Update!

1. Passez à « Effectuer une mise à jour infructueuse ».

• Si vous utilisez l’interface en ligne de commande GitHub :
  1. Créez une nouvelle branche appelée « patch-1 » :

git checkout -b patch-1

1. Dans votre éditeur de texte préféré, ouvrez ingress/default.conf.template et, dans le bloc location /health situé vers la fin du fichier, modifiez la directive return comme indiqué :

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

1. Ajoutez « default.conf.template » à la zone de préparation de Git :

git add ingress/default.conf.template

1. Validez le fichier :

git commit -m "feat: update NGINX ingress"

1. Envoyez vos modifications sur GitHub :

git push --set-upstream origin patch-1

1. Créez une demande de tirage (PR) :

gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform

1. Suivez la progression du workflow :

gh workflow view main.yml --repo <your_GitHub_account>/platform

1. Une fois le workflow terminé, envoyez une requête de contrôle d’intégrité à l’application, en remplaçant <ACR_URL> par la valeur que vous avez notée à l’étape 3 du Défi 1 :

curl <ACR_URL>/health
Successful Update!

Effectuer une mise à jour infructueuse

Créez maintenant une mise à jour qui échouera et observez l’échec du workflow. Il s’agit essentiellement de répéter les étapes de la section « Effectuer une mise à jour réussie », mais en utilisant une valeur différente pour la directive return.

• Si vous utilisez l’interface graphique de GitHub :
  1. Sélectionnez « Code > ingress > default.conf.template ».
  2. En haut à gauche, sélectionnez « main », puis le nom de la branche qui se termine par « patch-1 » et que vous avez créée dans la section précédente.
  3. Ouvrez « default.conf.template » pour le modifier en sélectionnant l’icône en forme de crayon dont l’infobulle indique « Modifier ce fichier ».
  4. Modifiez la directive « return » comme indiqué :

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

1. Sélectionnez « Valider directement dans la branche -patch-1 », puis « Valider les modifications ».
2. Sélectionnez « Actions » pour suivre la progression du workflow. Notez que le workflow s’exécute à nouveau lorsque les fichiers de la PR sont mis à jour.
3. Une fois le workflow terminé, accédez à votre application conteneur via le point de terminaison <ACR_URL>/health, où <ACR_URL> correspond à l’URL que vous avez notée à l’étape 3 du Défi 1. Le message affiché est Successful Update! (le même qu’après la précédente mise à jour réussie). Bien que cela puisse sembler paradoxal, cela confirme en réalité que cette mise à jour a échoué : la tentative de mise à jour a renvoyé le code d’état 500 (qui signifie Internal Server Error) et n’a donc pas été appliquée.
4. Vous pouvez confirmer le message en ouvrant une session de terminal et en envoyant une requête de contrôle d’intégrité à l’application, en remplaçant à nouveau « <ACR_URL> » par la valeur que vous avez notée à l’étape 3 du Défi 1 :

curl <ACR_URL>/healthSuccessful Update!

• Si vous utilisez la CLI GitHub :
  1. Basculez sur la branche « patch-1 » que vous avez créée dans la section précédente :

git checkout patch-1

1. Dans votre éditeur de texte préféré, ouvrez ingress/default.conf.template et modifiez à nouveau la directive return comme indiqué :

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

1. Ajoutez « default.conf.template » à la zone de préparation de Git :

git add ingress/default.conf.template

1. Validez le fichier :

git commit -m "feat: update NGINX ingress again"

1. Envoyez vos modifications sur GitHub :

git push

1. Suivez la progression du workflow :

gh workflow view main.yml --repo <your_GitHub_account>/platform

1. Une fois le workflow terminé, envoyez une requête de vérification de l’état à l’application, en remplaçant <ACR_URL> par la valeur que vous avez notée à l’étape 3 du Défi 1 :

curl <ACR_URL>/healthSuccessful Update!

1. Il peut sembler paradoxal que le message soit « Successful Update! » (le même qu’après la précédente mise à jour, qui avait réussi). Bien que cela puisse sembler paradoxal, cela confirme en réalité que cette mise à jour a échoué : la tentative de mise à jour a renvoyé le statut 500 (qui signifie « Internal Server Error ») et n’a pas été appliquée.

Nettoyage des ressources

Vous souhaiterez probablement supprimer les ressources Azure que vous avez déployées dans le tutoriel afin d’éviter d’éventuels frais par la suite :

az group delete -n my-container-app-rg -y

Vous pouvez également supprimer le fork que vous avez créé si vous le souhaitez.

• Si vous utilisez l’interface graphique de GitHub :
  1. Cliquez sur « Paramètres ».
  2. Faites défiler la page jusqu’en bas.
  3. Cliquez sur « Supprimer ce dépôt ».
  4. Saisissez « <your_GitHub_account>/platform », puis sélectionnez « Je comprends les conséquences, supprimer ce dépôt ».
• Si vous utilisez l’interface de ligne de commande GitHub :

gh repo delete <your_GitHub_account>/platform -yes

Étapes suivantes

Félicitations ! Vous avez appris à utiliser GitHub Actions pour effectuer un déploiement bleu-vert avec version Canary d’une application de microservices. Consultez ces articles de la documentation GitHub pour poursuivre votre exploration et approfondir vos connaissances en DevOps :

• À propos des workflows
• À propos de l’intégration continue avec GitHub Actions
• À propos du déploiement continu avec GitHub Actions
• À propos de la surveillance et de la résolution des problèmes

Si vous êtes prêt à essayer la deuxième étape d’un déploiement canari (les tests en production), consultez le tutoriel de Microservices March 2022, « Améliorer la disponibilité et la résilience grâce à un déploiement canari », sur notre blog. Il utilise NGINX Service Mesh pour passer progressivement à une nouvelle version de l’application. Même si vos déploiements ne sont pas encore assez complexes pour nécessiter un maillage de services, ou si vous n’utilisez pas Kubernetes, ces principes restent applicables aux déploiements plus simples qui utilisent uniquement un contrôleur Ingress ou un équilibreur de charge.

Pour poursuivre votre apprentissage des microservices, consultez Microservices March 2023. Dans l’unité 3, Accélérez les déploiements de microservices grâce à l’automatisation, vous en apprendrez davantage sur l’automatisation des déploiements.

À propos de l’auteur

Christopher Harrison

Autres articles de Christopher Harrison