NGINX教程：如何使用GitHub Actions自动执行微服务金丝雀部署

NGINX | 2023年3月21日

本文是四篇教程之一，旨在帮助您实践以下内容中的概念：Microservices March 2023：开始交付微服务：

如何部署和配置微服务
如何安全管理容器中的密钥
如何使用 GitHub Actions 自动执行微服务金丝雀发布（本文）
如何使用OpenTelemetry追踪来了解微服务

自动化部署对大多数项目的成功至关重要。但是，仅仅部署代码还不够。还需要确保尽量缩短（或消除）停机时间，并能够在发生故障时快速回滚。结合使用金丝雀部署和蓝绿部署是确保新代码可行的常用方法。此策略包括两个步骤：

步骤 1：通过金丝雀部署进行隔离测试：将代码部署到环境之外的隔离节点、服务器或容器中，并进行测试，确保代码按预期运行。
步骤 2：通过蓝绿部署在生产环境中进行测试。假设代码在金丝雀部署中运行正常，请将代码迁移到生产环境中新建的服务器（或节点、容器）上，并与当前版本的服务器并行运行。然后，将一部分生产流量重定向到新版本，以测试其在更高负载下能否继续正常运行。通常，可以先将一小部分流量（例如 10%）导向新版本，再逐步提高比例，直至新版本接收全部流量。每次增加的比例取决于您对新版本流量处理能力的信心；也可以一次性完全切换到新版本。

如果您不熟悉在应用或网站的不同版本之间分配流量（流量拆分）的各种用例，请阅读我们博客中的《如何通过高级流量管理提高Kubernetes的韧性》，了解蓝绿部署、金丝雀发布、A/B测试、速率限制、熔断等概念。虽然这篇博文专门介绍Kubernetes，但其中的概念也广泛适用于微服务应用。

教程概述

本教程将介绍如何使用GitHub Actions自动执行金丝雀蓝绿部署的第一步。在教程的4项挑战中，您将使用Microsoft Azure Container Apps部署应用的新版本，然后使用Azure Traffic Manager将流量从旧环境转移到新环境：

创建并部署NGINX容器应用
设置 Azure Container App 自动化部署所需的权限
使用GitHub Action创建金丝雀蓝绿部署
测试 GitHub Actions 工作流

注意：虽然本教程使用Azure Container Apps，但其中的概念和技术适用于任何基于云的主机。

先决条件和设置

先决条件

如果要在自己的环境中完成本教程，需要：

一个Azure帐户。建议使用未与贵组织关联的帐户，因为使用组织帐户时可能会遇到权限问题。
The Azure CLI.
如果希望用它替代（或配合使用）基于浏览器的GitHub GUI，可使用GitHub CLI。

设置

创建并配置所需的基础资源。复刻并克隆本教程的代码仓库，登录Azure CLI，然后安装Azure Container Apps扩展。

在主目录中创建microservices-march目录。（也可以使用其他目录名称，并相应调整说明。）注意：为便于将命令复制并粘贴到终端，本教程全程省略Linux命令行提示符。

mkdir ~/microservices-marchcd ~/microservices-march

将Microservices March platform仓库复刻并克隆到个人GitHub账户，可使用GitHub CLI或图形用户界面。
- 如果使用GitHub图形用户界面：
  1. 点击窗口右上角的“Fork”，然后在“Owner”菜单中选择您的个人GitHub账户。
  2. 将该存储库克隆到本地，并将<your_GitHub_account>替换为您的帐户名称：

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

如果使用GitHub CLI，请运行：

gh repo fork microservices-march/platform -–clone

登录Azure CLI。按照提示使用浏览器登录：

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"
    }
  }
]

安装containerapp扩展：

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

挑战 1：创建并部署 NGINX 容器应用

在第一个挑战中，您将创建一个NGINX Azure Container App，作为应用的初始版本，并将其用作金丝雀蓝绿部署的基准。Azure Container Apps是Microsoft Azure的一项服务，可用于在生产就绪的容器环境中轻松运行已打包到容器中的应用代码。

创建一个Azure资源组，用于容器应用：

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"
}

将容器部署到 Azure Container Apps（此步骤可能需要一些时间）：

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

在步骤2的输出中，找到在Azure Container Registry（ACR）中创建的容器应用的名称和URL。示例输出中以橙色突出显示了这两个值。在本教程的所有命令中，请使用实际输出中的值（与步骤2的示例输出不同）替换指定变量：
- 容器应用名称：在image.registry键中，指.azurecr.io之前的字符串。在步骤 2 的示例输出中，该字符串为cac085021b77acr。在后续命令中，使用此字符串替换<ACR_name>。
- 容器应用的URL：以“Container app created”开头的行中显示的URL。在步骤2的示例输出中，该URL为https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/。在后续命令中，使用此URL替换<ACR_URL>。
根据蓝绿部署的要求，为容器应用启用修订版本：

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

（可选）查询容器中的/health端点，测试部署是否正常运行：

curl <ACR_URL>/healthOK

挑战 2：设置 Azure Container App 自动部署所需的权限

在本挑战中，您将获取用于自动执行 Azure 容器应用部署的 JSON 令牌。

首先，获取Azure容器注册表（ACR）的ID，然后获取Azure托管标识的主体ID。接下来，将ACR的内置Azure角色分配给该托管标识，并将容器应用配置为使用该托管标识。最后，获取该托管标识的JSON凭据，GitHub Actions将使用这些凭据向Azure进行身份验证。

虽然这组步骤可能显得繁琐，但创建新应用程序时只需执行一次，而且整个过程都可以通过脚本完成。本教程要求手动执行这些步骤，以便熟悉相关操作。

注意：此部署凭据创建流程仅适用于Azure。

查找托管标识的主体ID。该ID显示在输出的PrincipalID列中（为便于阅读，输出分为两行）。在步骤3中，使用此值替换<managed_identity_principal_ID>：

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

在ACR中查找容器应用的资源ID，将“<ACR_name>”替换为在“挑战1”的第3步中记录的名称。下一步需要用此值替换“<ACR_resource_ID>”：

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

将适用于ACR的Azure内置角色分配给容器应用的托管标识，并将<managed_identity_principal_ID>替换为步骤1中获取的托管标识，将<ACR_resource_ID>替换为步骤2中获取的资源ID：

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"
}

将容器应用配置为从ACR拉取映像时使用托管标识，并将<ACR_name>替换为在挑战1的步骤3中记录的容器应用名称（该名称也用于上述步骤2）：

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": ""
  }
]

查找您的Azure订阅ID。

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

创建一个包含GitHub Action所需凭据的JSON令牌，并将“<subscription_ID>”替换为您的Azure订阅ID。保存输出，以便在“AZURE_CREDENTIALS”中将其粘贴为名为“向GitHub存储库添加密钥”的密钥值。可以放心忽略有关“--sdk-auth”已弃用的警告，这是一个已知问题：

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/"
}

挑战3：创建用于金丝雀蓝绿部署的GitHub Action

在此挑战中，您需要向GitHub仓库中添加密钥（用于管理GitHub Action工作流中的敏感数据），创建Action工作流文件，并执行Action工作流。

如需详细了解密钥管理，请参阅我们博客上的 Microservices March 23 系列第 2 篇教程《如何安全管理容器中的密钥》。

向GitHub存储库添加密钥

要部署新版本的应用程序，需要在您于“设置”中复刻的GitHub存储库内创建一系列密钥。这些密钥包括在“挑战 2”中创建的托管标识所对应的JSON凭据，以及将新版NGINX镜像部署到Azure所需的一些敏感部署参数。在下一节中，您将通过GitHub Action使用这些密钥，实现自动化的金丝雀蓝绿部署。

如果使用GitHub图形用户界面：
1. 转到您复刻的 GitHub 存储库。
2. 选择“Settings > Secrets and variables > Actions”。
3. 点击“New repository secret”。
4. 在指定字段中输入以下值：
  - 名称：AZURE_CREDENTIALS
  - 密钥：来自挑战 2 的第 6 步的 JSON 凭据
5. 点击“添加密钥”。
6. 重复执行步骤3至5三次，以创建表中列出的密钥。将“密钥名称”和“密钥值”列中的值分别输入GUI的“名称”和“密钥”字段。对于第三个密钥，请将“<ACR_name>”替换为在“挑战1”的步骤3中记录的容器应用名称。密钥名称密钥值CONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>
7. 继续执行创建 GitHub Action 工作流文件。
如果使用GitHub CLI：
1. 在代码仓库的根目录下创建一个临时文件。

touch ~/creds.json

使用常用的文本编辑器打开creds.json，然后复制在挑战 2的第 6 步中创建的 JSON 凭据。
创建密钥：

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

删除creds.json：

rm ~/creds.json

重复运行此命令，再创建3个密钥：

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

每次重复执行时，将<secret_name>替换为表格中“机密名称”列的一个值。出现提示时，粘贴“机密值”列中对应的值。对于第3个机密，将<ACR_name>替换为在“挑战1”第3步中记录的、分配给容器应用的名称。机密名称机密值CONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>

创建GitHub Action工作流文件

配置好托管身份和密钥后，即可为 GitHub Action 创建工作流文件，以自动执行金丝雀蓝绿部署。

注意：工作流文件采用YAML格式定义，其中空白字符具有重要意义。请务必保留下列步骤中所示的缩进。

为Action工作流创建一个文件。
- 如果使用GitHub图形用户界面：
  1. 转到您的 GitHub 存储库。
  2. 选择“Actions > New workflow > Skip this and set up a workflow yourself”。
- 如果使用GitHub CLI，请创建 .github/workflows目录，并新建一个名为main.yml的文件：

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

使用常用的文本编辑器，将工作流内容添加到main.yml。最简单的方法是复制完整工作流文件中的文本。也可以添加本步骤中标注的一组代码片段，手动构建该文件。注意：工作流文件采用YAML格式，其中空白字符具有重要意义。如果复制代码片段，请务必保留缩进（为确保无误，可将文件与完整工作流文件进行比较）。
- 定义工作流名称：

name: Deploy to Azure

将工作流配置为在向主分支执行推送或创建拉取请求时运行：

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

在jobs部分中，定义build-deploy作业。该作业会签出代码、登录Azure，并将应用部署到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.io

定义test-deployment作业。该作业会获取新部署修订版本的暂存URL，并使用GitHub Action ping API端点/health，以确保新修订版本能够响应。如果运行状况检查成功，容器应用上的Azure Traffic Manager将更新为把所有流量都定向到新部署的容器。注意：请务必将test-deployment键缩进到与上一项中定义的build-deploy键相同的层级：

  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"

完整工作流文件

以下是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"

执行操作工作流

如果使用GitHub图形用户界面：
1. 点击“Start commit”，可根据需要添加提交消息，然后在对话框中选择“Commit new file”。新的工作流文件将合并到主分支并开始执行。
2. 点击“Actions”以监控工作流的进度。
如果使用GitHub CLI：
1. 将main.yml添加到Git暂存区：

git add .github/workflows/main.yml

提交文件：

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

将更改推送到 GitHub：

git push

监控工作流进度：

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

挑战 4：测试 GitHub Actions 工作流

在本挑战中，您将测试该工作流。首先，模拟成功更新Ingress负载均衡器，并确认应用已更新。然后，模拟更新失败（这会导致内部服务器错误），并确认已发布的应用保持不变。

成功更新

成功创建更新，并查看工作流顺利完成。

如果使用GitHub图形界面：
1. 选择“Code > ingress > default.conf.template”。
2. 选择工具提示为“default.conf.template”的铅笔图标，打开Edit this file进行编辑。
3. 在文件末尾附近的location /health块中，按如下所示更改return指令：

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

在对话框中，选择“Create a new branch for this commit and start a pull request”，然后选择“Propose changes”。
点击“Create pull request”以访问拉取请求模板。
再次点击“Create pull request”以创建拉取请求。
点击“Actions”以监控工作流进度。
工作流完成后，访问容器应用的<ACR_URL>/health端点，其中<ACR_URL>是您在挑战 1的第 3 步中记录的 URL。请注意显示的“Successful Update!”消息。
可以启动终端会话并向应用发送运行状况检查请求，以确认该消息。仍需将“<ACR_URL>”替换为在“挑战 1”第 3 步中记录的值：

curl <ACR_URL>/healthSuccessful Update!

继续执行“进行一次失败的更新”。

如果使用 GitHub CLI：
1. 创建一个名为“patch-1”的新分支：

git checkout -b patch-1

使用常用的文本编辑器打开ingress/default.conf.template，然后在文件末尾附近的location /health块中，按如下所示更改return指令：

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

将“default.conf.template”添加到Git暂存区：

git add ingress/default.conf.template

提交文件：

git commit -m "feat: update NGINX ingress"

将更改推送到 GitHub：

git push --set-upstream origin patch-1

创建拉取请求（PR）：

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

监控工作流进度：

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

工作流完成后，向应用发送运行状况检查请求，并将“<ACR_URL>”替换为在“挑战 1”的第 3 步中记录的值：

curl <ACR_URL>/health
Successful Update!

执行一次失败的更新

现在创建一次失败的更新，并观察工作流如何失败。基本步骤与“执行成功的更新”中所述相同，但需要为“return”指令设置不同的值。

如果使用GitHub图形用户界面：
1. 选择“Code > ingress > default.conf.template”。
2. 在左上角，选择“main”，然后选择以“patch-1”结尾的分支名称。该分支是在上一节中创建的。
3. 选择工具提示为“default.conf.template”的铅笔图标，打开Edit this file进行编辑。
4. 按如下所示更改return指令：

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

选择“直接提交到 -patch-1 分支”，然后选择“提交更改”。
选择“Actions”以监控工作流进度。请注意，PR中的文件更新后，工作流会再次执行。
工作流完成后，通过以下端点访问容器应用：<ACR_URL>/health。其中，<ACR_URL>是您在挑战 1的第 3 步中记录的 URL。请注意，显示的消息为Successful Update!（与上一次成功更新后显示的消息相同）。这看似矛盾，实际上却证实了本次更新失败：更新尝试返回状态码 500（表示Internal Server Error），因此未能应用。
可以启动终端会话并向应用发送运行状况检查请求，以确认该消息。仍需将<ACR_URL>替换为在挑战 1的步骤 3 中记录的值：

curl <ACR_URL>/healthSuccessful Update!

如果使用GitHub CLI：
1. 签出在patch-1中创建的上一节分支：

git checkout patch-1

在常用的文本编辑器中打开ingress/default.conf.template，然后再次按如下所示更改return指令：

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

将“default.conf.template”添加到Git暂存区：

git add ingress/default.conf.template

提交文件：

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

将更改推送到GitHub：

git push

监控工作流进度：

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

工作流完成后，向应用发送运行状况检查请求，并将“<ACR_URL>”替换为在“挑战 1”第 3 步中记录的值：

curl <ACR_URL>/healthSuccessful Update!

消息显示为“Successful Update!”（与上一次成功更新后显示的消息相同），这看似矛盾。但实际上，这恰恰证实了本次更新失败：更新尝试返回状态码 500（表示“Internal Server Error”），因此未能应用。

资源清理

建议删除在本教程中部署的Azure资源，以免日后产生任何潜在费用：

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

如果不再需要，也可以删除已创建的分支。

如果使用GitHub图形用户界面：
1. 点击“Settings”。
2. 向下滚动到页面底部。
3. 点击“删除此存储库”。
4. 输入<your_GitHub_account>/platform，然后选择“我了解相关后果，删除此存储库”。
如果使用GitHub CLI：

gh repo delete <your_GitHub_account>/platform -yes

后续步骤

恭喜！您已了解如何使用 GitHub Actions 对微服务应用执行金丝雀蓝绿部署。请参阅 GitHub 文档中的以下文章，继续探索并深入了解 DevOps：

如果您已准备好尝试金丝雀部署的第二步（在生产环境中测试），请查看我们博客上的Microservices March 2022教程《通过金丝雀部署提高正常运行时间和韧性》。该教程使用NGINX Service Mesh逐步过渡到新的应用版本。即使您的部署尚未复杂到需要使用服务网格，或者您未使用Kubernetes，这些原则仍适用于仅使用Ingress控制器或负载均衡器的简单部署。

如需继续学习微服务相关知识，请查看Microservices March 2023。在“第3单元：利用自动化加速微服务部署”中，您将进一步了解如何实现部署自动化。