Tutoriel NGINX : Comment utiliser les actions GitHub pour automatiser les déploiements de microservices Canary
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 :
- Comment déployer et configurer des microservices
- Comment gérer en toute sécurité les secrets dans les conteneurs
- Comment utiliser les actions GitHub pour automatiser les versions de microservices Canary (cet article)
- Comment utiliser le traçage OpenTelemetry pour comprendre vos 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 :
- Créer et déployer une application conteneur NGINX
- Configurer des autorisations pour automatiser les déploiements d'applications Azure Container
- Créer un déploiement bleu-vert Canary avec une action GitHub
- Tester le flux de travail GitHub Actions
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 :
- 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 lors de l'utilisation d'un compte d'organisation.
- L' interface de ligne de commande Azure .
- L' interface de ligne de commande GitHub , si vous souhaitez l'utiliser à la place (ou en plus) de l'interface graphique utilisateur GitHub basée sur un navigateur.
Installation
Créez et configurez les ressources de base nécessaires. Dupliquez et clonez le dépôt du tutoriel, connectez-vous à Azure CLI, puis installez l’extension Azure Container Apps.
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-marchForkez 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 :
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 .
Clonez le référentiel localement, en remplaçant votre nom de compte par
<votre_compte_GitHub>:git clone https://github.com/<your_GitHub_account>/platform.gitcd platform
Si vous utilisez la CLI GitHub, exécutez :
gh repo fork microservices-march/platform -–clone
Connectez-vous à l'interface de ligne de commande Azure. Suivez les invites 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" } } ]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 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.
Créez un groupe de ressources Azure pour l’application conteneur :
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" }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/ ...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’agitde 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
Containerappcreated. Dans l’exemple de sortie de l’étape 2, il s’agitde https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/.Remplacez cette URL par
<URL_ACR>dans les commandes suivantes.
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"(Facultatif) Testez 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'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.
Recherchez l’ID principal de votre identité gérée. Il apparaît dans la colonne
PrincipalIDde 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 my-container-app \ --resource-group my-container-app-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ ... 39f8434b-12d6-4735-81d8-ba0apo14579f ... ... TenantId ... ------------------------------------ ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsdeRecherchez 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 utiliserez cette valeur pour remplacer<ACR_resource_ID>à 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/cac085021b77acrAttribuez le rôle intégré Azure pour ACR à l’identité gérée de l’application conteneur, en remplaçant
<managed_identity_principal_ID>par l’identité géré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" }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) :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": "" } ]Recherchez votre ID d’abonnement Azure .
az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97cCré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_CREDENTIALSdans Ajoutez des secrets à votre référentiel GitHub. Vous pouvez ignorer en toute sécurité l'avertissement concernant l'obsolescencede --sdk-auth; 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 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 :
- Accédez à votre référentiel GitHub forké.
- Sélectionnez Paramètres > Secrets et variables > Actions .
- Cliquez sur Nouveau secret de référentiel .
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
- Nom –
- Cliquez sur Ajouter un secret .
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_NAMEmon-application-conteneurGROUPE_RESSOURCESmon-conteneur-app-rgACR_NOM<ACR_nom>- Procédez à la création d’un fichier de workflow d’action GitHub .
Si vous utilisez l'interface de ligne de commande GitHub :
À la racine de votre dépôt, créez un fichier temporaire.
touch ~/creds.json- À 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 .
Créer le secret :
gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.jsonSupprimer creds.json :
rm ~/creds.jsonRépétez cette commande pour créer trois autres secrets :
gh secret set <secret_name> --repo <your_GitHub_account>/platformPour 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_NAMEmon-application-conteneurGROUPE_RESSOURCESmon-conteneur-app-rgACR_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.
Créez un fichier pour le workflow Action.
Si vous utilisez l'interface graphique GitHub :
- Accédez à votre référentiel GitHub.
- 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
À 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 :
name: Deploy to AzureConfigurez le workflow à exécuter lorsqu'une demande push ou pull est envoyée à la branche principale :
on: push: branches: - main pull_request: branches: - mainDans la section
des tâches, définissez la tâchede build-deploy, qui extrait le code, se connecte à Azure et déploie l'application sur Azure Container App :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.ioDé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-deploymentau même niveau que la clébuild-deployque vous avez définie dans la puce précédente :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 flux de travail complet
Ceci est le texte complet du fichier de workflow 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 d'action
Si vous utilisez l'interface graphique GitHub :
- 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.
- Cliquez sur Actions pour surveiller la progression du flux de travail.
Si vous utilisez l'interface de ligne de commande GitHub :
Ajoutez main.yml à la zone de préparation Git :
git add .github/workflows/main.ymlValider le fichier :
git commit -m "feat: create GitHub Actions workflow"Envoyez vos modifications sur GitHub :
git pushSurveiller la progression du workflow :
gh workflow view main.yml --repo <your_GitHub_account>/platform
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 :
- Sélectionnez Code > ingress > default.conf.template .
- Ouvrez default.conf.template pour le modifier en sélectionnant l'icône en forme de crayon avec l'info-bulle Modifier ce fichier .
Dans le bloc
d'emplacement/healthprès de la fin du fichier, modifiez la directivede retourcomme indiqué :location /health { access_log off; return 200 "Successful Update!\n"; }- 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 .
- Cliquez sur Créer une demande d’extraction pour accéder au modèle de demande d’extraction.
- Cliquez à nouveau sur Créer une demande d’extraction pour créer la demande d’extraction.
- Cliquez sur Actions pour surveiller la progression du flux de travail.
- 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! ». 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:curl <ACR_URL>/healthSuccessful Update!- Procéder à une mise à jour infructueuse .
Si vous utilisez l'interface de ligne de commande GitHub :
Créez une nouvelle branche appelée patch-1 :
git checkout -b patch-1Dans votre éditeur de texte préféré, ouvrez ingress/default.conf.template et dans le bloc
d'emplacement/healthprès de la fin du fichier, modifiez la directivede retourcomme indiqué :location /health { access_log off; return 200 "Successful Update!\n"; }Ajoutez default.conf.template à la zone de préparation Git :
git add ingress/default.conf.templateValider le fichier :
git commit -m "feat: update NGINX ingress"Envoyez vos modifications sur GitHub :
git push --set-upstream origin patch-1Créer une pull request (PR) :
gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platformSurveiller la progression du workflow :
gh workflow view main.yml --repo <your_GitHub_account>/platformUne 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:curl <ACR_URL>/health Successful Update!
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 :
- Sélectionnez Code > ingress > default.conf.template .
- 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 .
- Ouvrez default.conf.template pour le modifier en sélectionnant l'icône en forme de crayon avec l'info-bulle Modifier ce fichier .
Modifiez la directive
de retourcomme indiqué :location /health { access_log off; return 500 "Unsuccessful Update!\n"; }- Sélectionnez Valider directement dans la branche -patch-1 puis Valider les modifications .
- 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.
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(signifiantErreurinternedu serveur) et n'a pas été appliqué.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:curl <ACR_URL>/healthSuccessful Update!
Si vous utilisez l'interface de ligne de commande GitHub :
Consultez la branche patch-1 que vous avez créée dans la section précédente :
git checkout patch-1Dans votre éditeur de texte préféré, ouvrez ingress/default.conf.template et modifiez à nouveau la directive
de retourcomme indiqué :location /health { access_log off; return 500 "Unsuccessful Update!\n"; }Ajoutez default.conf.template à la zone de préparation Git :
git add ingress/default.conf.templateValider le fichier :
git commit -m "feat: update NGINX ingress again"Envoyez vos modifications sur GitHub :
git pushSurveiller la progression du workflow :
gh workflow view main.yml --repo <your_GitHub_account>/platformUne 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:curl <ACR_URL>/healthSuccessful Update!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(signifiantErreurinternedu serveur) et n'a pas été appliqué.
Libération des ressources
Pour éviter des frais à l'avenir, pensez à supprimer les ressources Azure que vous avez déployées dans le tutoriel :
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 GitHub :
- Cliquez sur Paramètres .
- Faites défiler vers le bas de la page.
- Cliquez sur Supprimer ce référentiel .
- 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 :
gh repo delete <your_GitHub_account>/platform -yes
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 :
- À propos des flux de travail
- À propos de l'intégration continue à l'aide de GitHub Actions
- À propos du déploiement continu à l'aide de GitHub Actions
- À propos de la surveillance et du dépannage
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.
« 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."