BLOG | NGINX

Tutoriel NGINX : Comment utiliser les actions GitHub pour automatiser les déploiements de microservices Canary

NGINX-Partie-de-F5-horiz-black-type-RGB
Miniature de Christopher Harrison
Christopher Harrison
Publié le 21 mars 2023

Cet article est l'un des quatre tutoriels qui vous aident à mettre en pratique les concepts de Microservices de mars 2023 : Commencez à fournir des microservices :

 

L’automatisation des déploiements est essentielle au succès de la plupart des projets. Cependant, il ne suffit pas de déployer votre code. Vous devez également vous assurer que les temps d’arrêt sont limités (ou éliminés) et que vous devez pouvoir revenir rapidement en arrière en cas de panne. La combinaison du déploiement Canary et du déploiement bleu-vert est une approche courante pour garantir la viabilité du nouveau code. Cette stratégie comprend deux étapes :

  • Étape 1 : Déploiement Canary pour tester de manière isolée – Déployez votre code sur un nœud, un serveur ou un conteneur isolé en dehors de votre environnement et testez pour vous assurer que le code fonctionne comme prévu.
  • Étape 2 : Déploiement bleu-vert pour tester en production – En supposant que le code fonctionne dans le déploiement Canary, portez le code vers les serveurs nouvellement créés (ou les nœuds ou les conteneurs) dans votre environnement de production aux côtés des serveurs de la version actuelle. Ensuite, redirigez une partie du trafic de production vers la nouvelle version pour tester si elle continue de bien fonctionner sous une charge plus élevée. Le plus souvent, vous commencez par diriger un petit pourcentage (10 %, par exemple) vers la nouvelle version et l’augmentez progressivement jusqu’à ce que la nouvelle version reçoive tout le trafic. La taille des incréments dépend de votre degré de confiance dans la capacité de la nouvelle version à gérer le trafic ; vous pouvez même passer complètement à la nouvelle version en une seule étape.

Si vous n'êtes pas familier avec les différents cas d'utilisation de la distribution du trafic entre différentes versions d'une application ou d'un site Web ( répartition du trafic ), lisez Comment améliorer la résilience dans Kubernetes avec la gestion avancée du trafic sur notre blog pour acquérir une compréhension conceptuelle des déploiements bleu-vert, des versions Canary, des tests A/B, de la limitation du débit, de la coupure de circuit, etc. Bien que le blog soit spécifique à Kubernetes, les concepts sont largement applicables aux applications de microservices.

Présentation du didacticiel

Dans ce tutoriel, nous montrons comment automatiser la première étape d’un déploiement Canary Blue-Green à l’aide de GitHub Actions . Dans les quatre défis du didacticiel, vous utilisez Microsoft Azure Container Apps pour déployer une nouvelle version de votre application, puis utilisez Azure Traffic Manager pour déplacer le trafic de l'ancien environnement vers le nouvel environnement :

Note: Bien que ce didacticiel utilise Azure Container Apps, les concepts et techniques peuvent être appliqués à n’importe quel hôte basé sur le cloud.

Prérequis et configuration

Prérequis

Si vous souhaitez réaliser ce tutoriel dans votre propre environnement, vous avez besoin de :

Installation

Créez et configurez les ressources de base nécessaires. Créez un fork et clonez le référentiel pour le didacticiel, 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 nom de répertoire différent et adapter les instructions en conséquence.)

    Note: Tout au long du didacticiel, l'invite sur la ligne de commande Linux est omise, pour faciliter la copie et le collage des commandes dans votre terminal.

    mkdir ~/microservices-marchcd ~/microservices-march

  2. Forkez et clonez le référentiel de la plateforme Microservices March sur votre compte GitHub personnel, à l'aide de la CLI ou de l'interface graphique utilisateur GitHub.

    • Si vous utilisez l'interface graphique GitHub :

      1. Cliquez sur Fork dans le coin supérieur droit de la fenêtre et sélectionnez votre compte GitHub personnel dans le menu Propriétaire .

        capture d'écran de l'interface graphique de GitHub montrant le fork du référentiel pour ce tutoriel

      2. Clonez le référentiel localement, en remplaçant votre nom de compte par <votre_compte_GitHub>:

        clone git https://github.com/<votre_compte_GitHub>/plateforme.gitcd plateforme

    • Si vous utilisez la CLI GitHub, exécutez :

      fourche de dépôt gh microservices-march/platform -–clone

  3. Connectez-vous à l'interface de ligne de commande Azure. Suivez les invites pour vous connecter à l'aide d'un navigateur :

    connexion az [ { "cloudName": « AzureCloud », « homeTenantId » : « cfd11e0f-1435-450s-bdr1-ffab73b4er8e », « id » : "60efapl2-38ad-41w8-g49a-0ecc6723l97c", "isDefault": vrai, "managedByTenants": [], "nom": « Abonnement Azure 1 », « état » : "Activé", "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "utilisateur": { "nom": "utilisateur@exemple.com", "type": "utilisateur" } } ]

  4. Installez l’extension containerapp :

    L' extension installée 'containerapp' est en version préliminaire.

Défi 1 : Créer et déployer une application conteneur NGINX

Dans ce défi initial, vous créez une application conteneur NGINX Azure comme version initiale de l’application utilisée comme base de référence pour le déploiement Canary Blue-Green. Azure Container Apps est un service Microsoft Azure que vous utilisez pour exécuter facilement du code d’application empaqueté dans un conteneur dans un environnement de conteneur prêt pour la production.

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

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

  2. 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: registre: cac085021b77acr .azurecr.io référentiel: my-container-app balise: "20230315212413756768" digest : sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... runtime-dependency : registre : registry.hub.docker.com référentiel : library/nginx tag : "1.23" digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} ID d'exécution : cf1 a réussi après 27 s Création de Containerapp my-container-app dans le groupe de ressources my-container-app-rg Ajout du mot de passe du registre en tant que secret avec le nom « ca2ffbce7810acrazurecrio-cac085021b77acr » Application conteneur créée. Accédez à votre application sur https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ ...

  3. Dans la sortie de l’étape 2, recherchez le nom et l’URL de l’application conteneur que vous avez créée dans Azure Container Registry (ACR). Ils sont surlignés en orange dans l'exemple de sortie. Vous remplacerez les valeurs de votre sortie (qui seront différentes de l'exemple de sortie de l'étape 2) par les variables indiquées dans les commandes tout au long du didacticiel :

    • Nom de l’application conteneur – Dans la clé image.registry , la chaîne de caractères avant .azurecr.io . Dans l’exemple de sortie de l’étape 2, il s’agit de cac085021b77acr .

      Remplacez cette chaîne de caractères par <ACR_nom> dans les commandes suivantes.

    • URL de l’application conteneur – L’URL sur la ligne qui commence 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 cette URL par <URL_ACR> dans les commandes suivantes.

  4. Activez les révisions pour l’application conteneur comme requis pour un déploiement bleu-vert :

    az containerapp revision set-mode \ --name mon-application-conteneur \ --resource-group mon-application-conteneur-rg \ --mode multiple "Multiple"

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

    boucle <URL_ACR>/santéD'ACCORD

Défi 2 : Configurer les autorisations pour automatiser les déploiements d'applications de conteneurs Azure

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

Vous commencez par obtenir l’ID du registre de conteneurs Azure (ACR), puis l’ID principal de votre identité gérée Azure. Vous attribuez ensuite le rôle Azure intégré pour ACR à l’identité gérée et configurez l’application conteneur pour utiliser l’identité gérée. Enfin, vous obtenez les informations d’identification JSON pour l’identité gérée, qui seront utilisées par GitHub Actions pour s’authentifier auprès d’Azure.

Bien que cet ensemble d’étapes puisse sembler fastidieux, vous n’avez besoin de les exécuter qu’une seule fois lors de la création d’une nouvelle application et vous pouvez entièrement scénariser le processus. Le didacticiel vous demande d'effectuer les étapes manuellement pour vous familiariser avec elles.

Note: Ce processus de création d’informations d’identification pour le déploiement est spécifique à Azure.

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

    az containerapp identity assign \ --name mon-application-conteneur \ --resource-group mon-application-conteneur-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ... ... ID du locataire ... ------------------------------------ ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

  2. Recherchez l’ID de ressource de l’application conteneur dans ACR, en remplaçant <ACR_nom> avec le nom que vous avez enregistré à l'étape 3 de Défi 1. Vous remplacerez cette valeur par <ID_ressource_ACR> à l’étape suivante :

    az acr afficher --nom <ACR_nom> --identifiant de requête --sortie tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

  3. Attribuez le rôle Azure intégré pour ACR à l’identité gérée de l’application conteneur, en remplaçant <identifiant_principal_d'identité_gérée> avec l’identité gérée obtenue à l’étape 1, et <ID_ressource_ACR> avec l'ID de ressource obtenu à l'étape 2 :

    attribution de rôle az créer \ --assignee <identifiant_principal_d'identité_gérée> \
--rôle AcrPull \
--scope <ID_ressource_ACR>
{
"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": "mon-application-conteneur-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/mon-application-conteneur-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" }

  4. Configurez l’application conteneur pour utiliser l’identité gérée lors de l’extraction d’images à partir d’ACR, en remplaçant <ACR_nom> avec le nom de l'application conteneur que vous avez enregistré à l'étape 3 dans Défi 1 (et également utilisé à l'étape 2 ci-dessus) :

    ensemble de registres az containerapp \ --name mon-conteneur-app \
--resource-group mon-conteneur-app-rg \
--serveur <ACR_nom>.azurecr.io \
--système d'identité
[
{
"identité": "système",
"mot de passeSecretRef": "",
"serveur": "cac085021b77acr.azurecr.io",
"nom d'utilisateur": ""
}
]

  5. Recherchez votre ID d’abonnement Azure .

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

  6. Créez un jeton JSON contenant les informations d'identification à utiliser par l'action GitHub, en remplaçant <ID_abonnement> avec votre ID d'abonnement Azure. Enregistrez la sortie pour la coller comme valeur du secret nommé AZURE_CREDENTIALS dans Ajoutez des secrets à votre référentiel GitHub. Vous pouvez ignorer en toute sécurité l'avertissement concernant l'obsolescence de --sdk-auth ; il s'agit d'un problème connu :

    L'option '--sdk- auth ' est obsolète et sera supprimée dans une future version. ... { "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 Canary Blue-Green

Dans ce défi, vous ajoutez des secrets à votre référentiel GitHub (utilisé pour gérer les données sensibles dans vos workflows GitHub Action), créez un fichier de workflow Action et exécutez le workflow Action .

Pour une introduction détaillée à la gestion des secrets, consultez le deuxième tutoriel sur les microservices du 23 mars, Comment gérer en toute sécurité les secrets dans les conteneurs sur notre blog.

Ajoutez des secrets à votre référentiel GitHub

Pour déployer une nouvelle version de l'application, vous devez créer une série de secrets dans le référentiel GitHub que vous avez créé lors de la configuration . Les secrets sont les informations d’identification JSON de l’identité gérée créée dans le défi 2 et certains paramètres sensibles spécifiques 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 action GitHub pour automatiser le déploiement Canary Blue-Green.

  • Si vous utilisez l'interface graphique GitHub :

    1. Accédez à votre référentiel GitHub forké.
    2. Sélectionnez Paramètres > Secrets et variables > Actions .
    3. Cliquez sur Nouveau secret de référentiel .

    4. Tapez les valeurs suivantes dans les champs indiqués :

      • Nom – AZURE_CREDENTIALS
      • Secret – Les informations d’identification JSON de l’étape 6 du défi 2
    5. Cliquez sur Ajouter un secret .

    6. Répétez les étapes 3 à 5 trois fois pour créer les secrets répertoriés dans le tableau. Saisissez les valeurs des colonnes Nom secret et Valeur secrète dans les champs Nom et Secret de l'interface graphique respectivement. Pour le troisième secret, remplacez <ACR_nom> avec le nom attribué à l'application conteneur que vous avez enregistrée à l'étape 3 de Défi 1.

      Nom secret Valeur secrète
      CONTENEUR_APP_NAME mon-application-conteneur
      GROUPE_RESSOURCES mon-conteneur-app-rg
      ACR_NOM <ACR_nom>
    7. Procédez à la création d’un fichier de workflow d’action GitHub .

  • Si vous utilisez l'interface de ligne de commande GitHub :

    1. À la racine de votre dépôt, créez un fichier temporaire.

      toucher ~/creds.json
    2. À l’aide de votre éditeur de texte préféré, ouvrez creds.json et copiez les informations d’identification JSON que vous avez créées à l’étape 6 du défi 2 .

    3. Créer le secret :

      ensemble secret gh AZURE_CREDENTIALS --repo <votre_compte_GitHub>/plateforme < ~/creds.json

    4. Supprimer creds.json :

      rm ~/creds.json

    5. Répétez cette commande pour créer trois autres secrets :

      ensemble secret gh <nom_secret> --repo <votre_compte_GitHub>/plate-forme

      Pour chaque répétition, remplacez <nom_secret> avec l'une des valeurs dans le Nom secret colonne dans le tableau. À l’invite, collez la valeur associée à partir de la colonne Valeur secrète . Pour le troisième secret, remplacez <ACR_nom> avec le nom attribué à l'application conteneur que vous avez enregistrée à l'étape 3 de Défi 1.

      Nom secret Valeur secrète
      CONTENEUR_APP_NAME mon-application-conteneur
      GROUPE_RESSOURCES mon-conteneur-app-rg
      ACR_NOM <ACR_nom>

Créer un fichier de workflow d'action GitHub

Une fois l’identité gérée et les secrets en place, vous pouvez créer un fichier de workflow pour une action GitHub qui automatise le déploiement Canary Blue-Green.

Note: Les fichiers de workflow sont définis au format YAML, où les espaces sont significatifs. Assurez-vous de conserver l’indentation indiquée dans les étapes ci-dessous.

  1. Créez un fichier pour le workflow Action.

    • Si vous utilisez l'interface graphique GitHub :

      1. Accédez à votre référentiel GitHub.
      2. Sélectionnez Actions > Nouveau flux de travail > Ignorer cette étape et configurer vous-même un flux de travail .

    • Si vous utilisez la CLI GitHub, créez le répertoire .github/workflows et créez un nouveau fichier appelé main.yml :

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

  2. À l’aide de votre éditeur de texte préféré, ajoutez le texte du workflow à main.yml . La méthode la plus simple consiste à copier le texte qui apparaît dans le fichier de flux de travail complet . Vous pouvez également créer le fichier manuellement en ajoutant l’ensemble d’extraits annotés à cette étape.

    Note: Les fichiers de workflow sont définis au format YAML, où les espaces sont significatifs. Si vous copiez les extraits, assurez-vous de conserver l'indentation (et pour être plus sûr, comparez votre fichier au fichier de workflow complet ).

    • Définir le nom du workflow :

      nom: Déployer sur Azure

    • Configurez le workflow à exécuter lorsqu'une demande push ou pull est envoyée à la branche principale :

      sur :
push :
branches :
- main
pull_request :
branches :
- main

    • Dans la section des tâches , définissez la tâche de build-deploy , qui extrait le code, se connecte à Azure et déploie l'application sur Azure Container App :

      tâches : build-deploy : runs-on : ubuntu-22.04 étapes : - nom : Consultez les utilisations de la base de code : actions/checkout@v3 - nom : Connectez-vous à Azure avec : azure/login@v1 et : creds :${{ secrets.AZURE_CREDENTIALS } } - nom: Créez et déployez l'application conteneur exécutez : | # Ajoutez l'extension containerapp manuellement az extension add --name containerapp --upgrade # Utilisez Azure CLI pour déployer la mise à jour 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 la tâche de test-déploiement , qui obtient l’URL de préparation de la révision nouvellement déployée et utilise une action GitHub pour envoyer un ping au point de terminaison de l’API /health afin de garantir que la nouvelle révision répond. Si la vérification de l’état réussit, Azure Traffic Manager sur l’application conteneur est mis à jour pour pointer tout le trafic vers le conteneur nouvellement déployé.

      Note: Assurez-vous de mettre en retrait la clé test-deployment au même niveau que la clé build-deploy que vous avez définie dans la puce précédente :

        test-deployment : besoins : build-deploy s'exécute sur : ubuntu-22.04 étapes : - nom : Connectez-vous à Azure avec : azure/login@v1 et : creds :${{ secrets.AZURE_CREDENTIALS } } - nom: Obtenir le nouveau nom du conteneur exécuter : | # Ajouter l'extension containerapp manuellement az extension add --name containerapp --upgrade # Obtenir le nom de la dernière révision déployée REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # Obtenir le nom de domaine complet de la dernière révision déployée REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Stocker les valeurs dans les variables d'environnement echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: ID de déploiement de test : test-deployment utilise : jtalk/url-health-check-action@v3 # Action de la place de marché pour toucher le point de terminaison avec : url : « https://${{ env.REVISION_FQDN } }/health" # Point de terminaison de préparation - nom : Déploiement réussi, exécutez : | echo « Déploiement réussi ! Activation de la nouvelle révision" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --révision-poids "${{ env.REVISION_NAME } }=100"

Fichier de flux de travail complet

Ceci est le texte complet du fichier de workflow Action.

nom: Déployer sur Azure sur : push : branches : - main pull_request : branches : - main jobs : build-deploy : runs-on : ubuntu-22.04 steps : - name : Consultez les utilisations de la base de code : actions/checkout@v3 - nom : Connectez-vous à Azure avec : azure/login@v1 et : creds :${{ secrets.AZURE_CREDENTIALS } } - nom: Créez et déployez le conteneur. Exécutez : | # Ajoutez l'extension containerapp manuellement az extension add --name containerapp -upgrade # Utilisez Azure CLI pour déployer la mise à jour 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: besoins: build-deploy runs-on: ubuntu-22.04 étapes: - nom: Connectez-vous à Azure avec : azure/login@v1 et : creds :${{ secrets.AZURE_CREDENTIALS } } - nom: Obtenir le nouveau nom du conteneur exécuter : | # Installer l'extension containerapp pour l'interface de ligne de commande Azure az extension add --name containerapp --upgrade # Obtenir le nom de la dernière révision déployée REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # Obtenir le nom de domaine complet de la dernière révision déployée REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Stocker les valeurs dans les variables d'environnement echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - name: ID de déploiement de test : test-deployment utilise : jtalk/url-health-check-action@v3 # Action de la place de marché pour toucher le point de terminaison avec : url : « https://${{ env.REVISION_FQDN } }/health" # Point de terminaison de préparation - nom : Déploiement réussi, exécutez : | echo « Déploiement réussi ! Activation de la nouvelle révision" az containerapp ingress traffic set -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --révision-poids "${{ env.REVISION_NAME } }=100"

Exécuter le workflow d'action

  • Si vous utilisez l'interface graphique GitHub :

    1. Cliquez sur Démarrer la validation , ajoutez un message de validation si vous le souhaitez et, dans la boîte de dialogue, sélectionnez Valider le nouveau fichier . Le nouveau fichier de workflow est fusionné dans la branche principale et commence à s'exécuter.
    2. Cliquez sur Actions pour surveiller la progression du flux de travail.

  • Si vous utilisez l'interface de ligne de commande GitHub :

    1. Ajoutez main.yml à la zone de préparation Git :

      git add .github/workflows/main.yml

    2. Valider le fichier :

      git commit -m "feat : créer un flux de travail GitHub Actions"

    3. Envoyez vos modifications sur GitHub :

      git push

    4. Surveiller la progression du workflow :

      vue de flux de travail gh main.yml --repo <votre_compte_GitHub>/plate-forme

Défi 4 : Tester le workflow des actions GitHub

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

Réussir une mise à jour

Créez une mise à jour réussie et regardez le flux de travail réussir.

  • Si vous utilisez l'interface graphique 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 avec l'info-bulle Modifier ce fichier .

    3. Dans le bloc d'emplacement /health près de la fin du fichier, modifiez la directive de retour comme indiqué :

      emplacement /santé {
access_log désactivé ;
retour 200 " Mise à jour réussie !\n " ;
}
    4. Dans la boîte de dialogue, sélectionnez Créer une nouvelle branche pour ce commit et démarrer une demande d'extraction , puis Proposer des modifications .
    5. Cliquez sur Créer une demande d’extraction pour accéder au modèle de demande d’extraction.
    6. Cliquez à nouveau sur Créer une demande d’extraction pour créer la demande d’extraction.
    7. Cliquez sur Actions pour surveiller la progression du flux de travail.
    8. Une fois le flux de travail terminé, accédez à votre application conteneur à l'adresse <URL_ACR>/santé point final, où le <URL_ACR> est l'URL que vous avez notée à l'étape 3 de Défi 1. Notez le message « Mise à jour réussie ! » .

    9. Vous pouvez confirmer le message en démarrant une session de terminal et en envoyant une demande de vérification de l'état à l'application, en remplaçant à nouveau <URL_ACR> avec la valeur que vous avez enregistrée à l'étape 3 de Défi 1:

      boucle <URL_ACR>/santéMise à jour réussie !
    10. Procéder à une mise à jour infructueuse .

  • Si vous utilisez l'interface de ligne de commande GitHub :

    1. Créez une nouvelle branche appelée patch-1 :

      git checkout -b patch-1

    2. Dans votre éditeur de texte préféré, ouvrez ingress/default.conf.template et dans le bloc d'emplacement /health près de la fin du fichier, modifiez la directive de retour comme indiqué :

      emplacement /santé {
access_log désactivé ;
retour 200 " Mise à jour réussie !\n " ;
}

    3. Ajoutez default.conf.template à la zone de préparation Git :

      git add ingress/default.conf.template

    4. Valider le fichier :

      git commit -m "feat: mettre à jour l'entrée NGINX"

    5. Envoyez vos modifications sur GitHub :

      git push --set-upstream origine patch-1

    6. Créer une pull request (PR) :

      gh pr create --head patch-1 --fill --repo <votre_compte_GitHub>/plate-forme

    7. Surveiller la progression du workflow :

      vue de flux de travail gh main.yml --repo <votre_compte_GitHub>/plate-forme

    8. Une fois le flux de travail terminé, envoyez une demande de contrôle de l’état à l’application, en remplaçant <URL_ACR> avec la valeur que vous avez enregistrée à l'étape 3 de Défi 1:

      boucle <URL_ACR>/santé
Mise à jour réussie !

Effectuer une mise à jour infructueuse

Créez maintenant une mise à jour infructueuse et regardez le flux de travail échouer. Cela implique essentiellement de répéter les étapes de Réaliser une mise à jour réussie , mais avec une valeur différente pour la directive de retour .

  • Si vous utilisez l'interface graphique 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 , 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 avec l'info-bulle Modifier ce fichier .

    4. Modifiez la directive de retour comme indiqué :

      emplacement /santé {
access_log désactivé ;
retour 500 "Mise à jour infructueuse !\n" ;
}
    5. Sélectionnez Valider directement dans la branche -patch-1 puis Valider les modifications .
    6. Sélectionnez Actions pour surveiller la progression du flux de travail. Notez que le flux de travail s'exécute à nouveau lorsque les fichiers du PR sont mis à jour.

    7. Une fois le flux de travail terminé, accédez à votre application conteneur à l'adresse <URL_ACR>/santé point final, où le <URL_ACR> est l'URL que vous avez enregistrée à l'étape 3 de Défi 1.

       

      Notez que le message est « Mise à jour réussie ! » (le même qu'après la mise à jour réussie précédente). Bien que cela puisse paraître paradoxal, cela confirme en fait que cette mise à jour a échoué – la tentative de mise à jour a abouti au statut500 (signifiant Erreur interne du serveur ) et n'a pas été appliqué.

    8. Vous pouvez confirmer le message en démarrant une session de terminal et en envoyant une demande de vérification de l'état à l'application, en remplaçant à nouveau <URL_ACR> avec la valeur que vous avez enregistrée à l'étape 3 de Défi 1:

      boucle <URL_ACR>/santéMise à jour réussie !

  • Si vous utilisez l'interface de ligne de commande GitHub :

    1. Consultez la branche patch-1 que vous avez créée dans la section précédente :

      git checkout patch-1

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

      emplacement /santé {
access_log désactivé ;
retour 500 "Mise à jour infructueuse !\n" ;
}

    3. Ajoutez default.conf.template à la zone de préparation Git :

      git add ingress/default.conf.template

    4. Valider le fichier :

      git commit -m "feat: mettre à jour à nouveau l'entrée NGINX"

    5. Envoyez vos modifications sur GitHub :

      git push

    6. Surveiller la progression du workflow :

      vue de flux de travail gh main.yml --repo <votre_compte_GitHub>/plate-forme

    7. Une fois le flux de travail terminé, envoyez une demande de contrôle de l’état à l’application, en remplaçant <URL_ACR> avec la valeur que vous avez enregistrée à l'étape 3 de Défi 1:

      boucle <URL_ACR>/santéMise à jour réussie !

      Il peut paraître paradoxal que le message soit « Mise à jour réussie ! » (le même qu'après la mise à jour précédente, réussie). Bien que cela puisse paraître paradoxal, cela confirme en fait que cette mise à jour a échoué – la tentative de mise à jour a abouti au statut500 (signifiant Erreur interne du serveur ) et n'a pas été appliqué.

Nettoyage des ressources

Vous souhaiterez probablement supprimer les ressources Azure que vous avez déployées dans le didacticiel pour éviter d’éventuels frais ultérieurs :

az group delete -n mon-conteneur-app-rg -y

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

  • Si vous utilisez l'interface graphique GitHub :

    1. Cliquez sur Paramètres .
    2. Faites défiler vers le bas de la page.
    3. Cliquez sur Supprimer ce référentiel .
    4. Taper <votre_compte_GitHub>/plate-forme et sélectionnez Je comprends les conséquences, supprimez ce dépôt.

  • Si vous utilisez l'interface de ligne de commande GitHub :

    Supprimer le dépôt gh <votre_compte_GitHub>/plateforme -oui

Prochaines étapes

Félicitations ! Vous avez appris à utiliser GitHub Actions pour effectuer un déploiement bleu-vert Canary d'une application de microservices. Consultez ces articles dans la documentation GitHub pour continuer à explorer et à développer vos connaissances sur DevOps :

Si vous êtes prêt à tester la deuxième étape d'un déploiement Canary (tests en production), consultez le tutoriel de Microservices de mars 2022, Améliorer la disponibilité et la résilience avec un déploiement Canary 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 suffisamment complexes pour nécessiter un maillage de services, ou si vous n'utilisez pas Kubernetes, les principes s'appliquent toujours aux déploiements plus simples utilisant uniquement un contrôleur Ingress ou un équilibreur de charge.

Pour poursuivre votre formation sur les microservices, consultez Microservices mars 2023. Dans l'unité 3, Accélérer les déploiements de microservices avec l'automatisation , vous en apprendrez davantage sur l'automatisation des déploiements.

Lire plus d'articles de blog sur F5 NGINX ›

« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."