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

table.nginx-blog, table.nginx-blog th, table.nginx-blog td {
边框：2px 纯黑；
边界崩溃：崩溃；
}
表.nginx-博客 {
宽度：100%；
}
table.nginx-blog th {
背景颜色：#d3d3d3；
对齐：左；
左内边距：5px；
右内边距：5px；
底部填充：2px；
顶部填充：2px；
行高：120%；
}
表.nginx-博客 td {
左内边距：5px；
右内边距：5px；
底部填充：2px；
顶部填充：5px；
行高：120%；
}
表.nginx-博客 td.center {
文本对齐：居中；
底部填充：2px；
顶部填充：5px；
行高：120%；
}

本文是帮助您将 2023 年 3 月的微服务概念付诸实践的四篇教程之一：开始交付微服务：

• 如何部署和配置微服务
• 如何安全地管理容器中的机密
• 如何使用 GitHub Actions 自动化微服务金丝雀发布（本文）
• 如何使用 OpenTelemetry 跟踪来了解您的微服务

自动化部署对于大多数项目的成功至关重要。然而，仅仅部署代码是不够的。您还需要确保限制（或消除）停机时间，并且需要能够在发生故障时快速回滚。将金丝雀部署和蓝绿部署相结合是确保新代码可行的常见方法。该策略包括两个步骤：

• 第 1 步：金丝雀部署以进行隔离测试 – 将您的代码部署到环境之外的隔离节点、服务器或容器，并进行测试以确保代码按预期运行。
• 第 2 步：蓝绿部署以在生产中进行测试 – 假设代码在金丝雀部署中运行，将代码移植到生产环境中新创建的服务器（或节点或容器）与当前版本的服务器一起维护。然后将一部分生产流量重定向到新版本，以测试其在更高负载下是否继续正常工作。大多数情况下，您首先将一小部分（例如 10%）定向到新版本，然后逐步增加，直到新版本接收到所有流量。增量的大小取决于您对新版本可以处理流量的信心；您甚至可以一步完全切换到新版本。

如果您不熟悉在不同版本的应用程序或网站之间分配流量（流量分割）的不同用例，请阅读我们博客上的如何通过高级流量管理提高 Kubernetes 的弹性，以获得对 blue 的概念性理解－绿色部署、金丝雀发布、A/B 测试、速率限制、熔断等等。虽然该博客特定于 Kubernetes，但这些概念广泛适用于微服务应用。

教程概述

在本教程中，我们将展示如何使用 GitHub Actions 自动执行金丝雀蓝绿部署的第一步。在本教程的四个挑战中，您将使用 Microsoft Azure 容器应用部署新版本的应用程序，然后使用 Azure 流量管理器将流量从旧环境转移到新环境：

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

注意：虽然本教程使用 Azure 容器应用，但这些概念和技术可以应用于任何基于云的主机。

先决条件和设置

先决条件

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

• Azure 帐户。我们建议您使用未链接到 y 的帐户我们的组织，因为您在使用组织帐户时可能会遇到权限问题。
• Azure CLI。
• GitHub CLI，如果您想使用它来代替（或补充）基于浏览器的 GitHub GUI。

设置

创建并配置必要的基础资源。分叉并克隆本教程的存储库，登录到 Azure CLI，然后安装 Azure 容器应用的扩展。

在您的主目录中，创建 microservices-march 目录。 （您还可以使用不同的目录名称并相应地调整说明。）

注意：在整个教程中，省略了 Linux 命令行上的提示符，以便更轻松地将命令复制并粘贴到终端中。

mkdir ~/微服务-march
cd ~/微服务-march

使用 GitHub CLI 或 GUI 将 Microservices March 平台存储库分叉并克隆到您的个人 GitHub 帐户。

• 如果使用 GitHub GUI：

• 单击窗口右上角的“Fork”，然后在“所有者”菜单上选择您的个人 GitHub 帐户。

• 在本地克隆存储库，并将 替换为您的帐户名：

  git 克隆 https://github.com//platform.git
  光盘平台

• 如果使用 GitHub CLI，请运行：

  gh repo fork microservices-march/platform –clone

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

登录
[
{
“cloudName”: “AzureCloud”,
“homeTenantId”: “cfd11e0f-1435-450s-bdr1-ffab73b4er8e”,
“id”：“60efapl2-38ad-41w8-g49a-0ecc6723l97c”，
“isDefault”：正确，
“由租户管理”：[]，
“name”: “Azure 订阅 1”,
“状态”：“已启用”，
“tenantId”：“cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde”，
“用户”：{
“名称”：“user@example.com”，
“类型”：“用户”
}
}
]

安装容器应用扩展：

az 扩展添加 –name containerapp -upgrade
已安装的扩展“containerapp”处于预览状态。

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

在这个初始挑战中，您将创建一个 NGINX Azure 容器应用程序作为应用程序的初始版本，用作金丝雀蓝绿部署的基准。 Azure 容器应用程序是一项 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”，
“位置：“韦斯图斯”，
“管理者”：空，
“名称”：“我的容器应用程序rg”，
“特性”： {
“配置状态”：“成功”
},
“标签”：空，
“类型”：“Microsoft.Resources/resourceGroups”
}

部署容器迁移到 Azure 容器应用程序（此步骤可能需要一段时间）：

az containerapp up \
–resource-group my-container-app-rg \
–name my-container-app \
–源./入口\
–入口外部\
–目标端口 80 \
–地点韦斯图斯
…
– 图像：
注册表：cac085021b77acr.azurecr.io
存储库：我的容器应用程序
标签：“20230315212413756768”
摘要：sha256：90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451…
运行时依赖：
注册表：registry.hub.docker.com
存储库：库/nginx
标签：“1.23”
摘要：sha256：aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce…
git：{}
运行ID：cf1 27s后成功
在资源组 my-container-app-rg 中创建 Containerapp my-container-app
添加注册表密码作为名称“ca2ffbce7810acrazurecrio-cac085021b77acr”的秘密
容器应用程序已创建。通过 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ 访问您的应用程序
…

在步骤 2 的输出中，找到您在 Azure 容器注册表 (ACR) 中创建的容器应用程序的名称和 URL。它们在示例输出中以橙色突出显示。您将用输出中的值（与步骤 2 中的示例输出不同）替换整个教程中命令中指示的变量：

• 容器应用的名称 – 在 image.registry 键中，.azurecr.io 之前的字符串。在步骤 2 的示例输出中，它是 cac085021b77acr。

  在后续命令中将此字符串替换为 。

• 容器应用的 URL – 所创建的容器应用开始行的 URL。在步骤 2 的示例输出中，它是 https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/。

  在后续命令中将此 URL 替换为 。

根据蓝色的要求启用容器应用程序的修订…9；绿色部署：

az containerapp 修订版设置模式 \
–name my-container-app \
–resource-group my-container-app-rg \
–模式多重
“多种的”

（可选）通过查询容器中的 /health 端点来测试部署是否正常工作：

卷曲 /health
好的

挑战 2：设置自动化 Azure 容器应用部署的权限

在此挑战中，您将获得 JSON 令牌，该令牌使您能够自动执行 Azure 容器应用部署。

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

虽然这组步骤可能看起来很乏味，但您只需要o 在创建新应用程序时执行一次，您可以完全编写该过程的脚本。本教程要求您手动执行这些步骤以熟悉它们。

注意：创建部署凭据的过程特定于 Azure。

查找您的托管身份的主体 ID。它出现在输出的“PrincipalID”列中（为了便于阅读，该列分为两行）。您将在步骤 3 中将此值替换为 ：

az containerapp 身份分配 \
–name my-container-app \
–resource-group my-container-app-rg \
–系统分配的\
–输出表
校长编号…
———————————————— …
39f8434b-12d6-4735-81d8-ba0apo14579f …

…租户ID
…————————————
… cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

在以下位置查找容器应用程序的资源 ID：ACR，将 替换为您在挑战 1 第 3 步中记录的名称。您将在下一步中将此值替换为 ：

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

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

az 角色分配创建 \
–assignee \
–角色 AcrPull \
–scope
{
“条件”：空，
“条件版本”：空，
“创建者”：空，
“创建时间”: “2023-03-15T20:28:40.831224+00:00”,
“delegateManagedIdentityResourceId”：空，
“描述”：空，
“id”: “/下标ons/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed160 07ff249” ,
“名称”：“f0773943-8769-44c6-a820-ed16007ff249”，
“principalId”: “39f8ee4b-6fd6-47b5-89d8-ba0a4314579f”,
“principalType”: “服务主体”,
“resourceGroup”: “my-container-app-rg”,
“roleDefinitionId”：“/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d”，
“范围”：“/订阅/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr”，
“类型”：“Microsoft.Authorization/roleAssignments”，
“更新者”：“d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d”，
“更新”：“2023-03-15T20：28：41.127243 + 00：00”
}

将容器应用配置为在从其中拉取映像时使用托管标识m ACR，将 替换为您在挑战 1 的步骤 3 中记录的容器应用名称（也在上面的步骤 2 中使用）：

az containerapp 注册表集 \
–name my-container-app \
–resource-group my-container-app-rg \
–server .azurecr.io \
–身份系统
[
{
“身份”：“系统”，
“passwordSecretRef”: “”,
“服务器”：“cac085021b77acr.azurecr.io”，
“用户名”： ””
}
]

查找您的 Azure 订阅 ID。

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

创建一个 JSON 令牌，其中包含 GitHub 操作要使用的凭据，并将 替换为您的 Azure 订阅 ID。将要粘贴的输出保存为将机密添加到 GitHub 存储库中名为 AZURE_CREDENTIALS 的机密值。您可以放心地忽略有关 –sdk-auth 已弃用的警告；这是一个已知问题：

az ad sp 为 rbac 创建 \
–名称我的容器ner-app-rbac \
–角色贡献者\
–scopes /subscriptions//resourceGroups/my-container-app-rg \
–sdk-auth \
–输出json
选项“–sdk-auth”已被弃用，并将在未来版本中删除。
…
{
“clientId”: “0732444d-23e6-47fb-8c2c-74bddfc7d2er”,
“clientSecret”: “qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe”,
“订阅Id”：“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 操作

在本次挑战中，您广告d 机密到您的 GitHub 存储库（用于管理 GitHub Action 工作流程中的敏感数据），创建 Action 工作流程文件，然后执行 Action 工作流程。

有关秘密管理的详细介绍，请参阅我们博客上的 3 月 23 日微服务第二个教程“如何安全地管理容器中的秘密”。

将机密添加到您的 GitHub 存储库

要部署应用程序的新版本，您需要在您在“设置”中分叉的 GitHub 存储库中创建一系列机密。这些机密是挑战 2 中创建的托管身份的 JSON 凭据，以及将新版本的 NGINX 映像部署到 Azure 所需的一些敏感部署特定参数。在下一部分中，您将在 GitHub Action 中使用这些机密来自动执行金丝雀蓝绿部署。

• 如果使用 GitHub GUI：

• 导航到您的分叉 GitHub 存储库。
• 选择设置 > 秘密和变量s > 行动。
• 单击“新建存储库机密”。

• 在指示字段中键入以下值：

  • 名称 – AZURE_CREDENTIALS
  • 秘密 – 来自挑战 2 第 6 步的 JSON 凭据
• 点击“添加机密”。

• 重复步骤 3-5 三次以创建表中列出的密钥。将“秘密名称”和“秘密值”列中的值分别输入到 GUI 的“名称”和“秘密”字段中。对于第三个密钥，请将 替换为您在挑战 1 第 3 步中记录的分配给容器应用的名称。

  秘密名字
  秘密价值
  CONTAINER_APP_NAME 我的容器应用 RESOURCE_GROUP 我的容器应用程序-rg ACR_NAME
• 继续创建 GitHub 操作工作流程文件。

• 如果使用 GitHub CLI：

• 在t在您的存储库的根目录中，创建一个临时文件。

  触摸〜/creds.json

• 使用您喜欢的文本编辑器打开 creds.json 并复制您在挑战 2 第 6 步中创建的 JSON 凭据。

• 创建秘密：

  gh 秘密集 AZURE_CREDENTIALS –repo /platform < ~/creds.json

• 删除creds.json：

  rm ~/creds.json

• 重复此命令以创建另外三个秘密：

  gh 秘密集 –repo /platform

  对于每次重复，将 替换为表中 Secret Name 列中的值之一。根据提示，粘贴“秘密值”列中的关联值。对于第三个密钥，请将 替换为您在挑战 1 第 3 步中记录的分配给容器应用的名称。

  秘密名字
  秘密价值
  CONTAINER_APP_NAME 我的容器应用 RESOURCE_GROUP
  我的容器应用程序-rg ACR_NAME

创建 GitHub 操作工作流文件

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

注意：工作流文件以 YAML 格式定义，其中空格很重要。请务必保留以下步骤中显示的缩进。

为操作工作流程创建文件。

• 如果使用 GitHub GUI：

• 导航到您的 GitHub 存储库。
• 选择“操作”>“新建工作流程”> 跳过此步骤并自行设置工作流程。

• 如果使用 GitHub CLI，请创建 .github/workflows 目录并创建一个名为 main.yml 的新文件：

  mkdir .github/工作流程
  触摸.github/workflows/main.yml

使用您喜欢的文本编辑器，将工作流文本添加到 main.yml 中。容易的事方法是复制完整工作流程文件中出现的文本。或者，您可以通过添加此步骤中注释的一组代码片段来手动构建文件。

注意：工作流文件以 YAML 格式定义，其中空格很重要。如果您复制片段，请务必保留缩进（为了更加确定，请将您的文件与完整工作流程文件进行比较。

• 定义工作流程的名称：

  名称：部署到 Azure

• 配置工作流在向主分支发出推送或拉取请求时运行：

  在：
  推：
  分支机构：
  – 主要的
  拉请求：
  分支机构：
  – 主要的

• 在作业部分中，定义构建-部署作业，该作业检出代码、登录 Azure 并将应用程序部署到 Azure 容器应用程序：

  工作：
  构建部署：
  运行系统：ubuntu-22.04
  脚步：
  – 名称：查看代码库
  使用：actions/checkout@v3

  – 名称：登录 Azure
  使用：azure/login@v1和：
  信用：${{secrets.AZURE_CREDENTIALS }}

  – 名称：构建和部署容器应用程序
  运行： |
  # 手动添加containerapp扩展
  az 扩展添加 –name containerapp –upgrade
  # 使用 Azure CLI 部署更新
  az containerapp up -n ${{ Secrets.CONTAINER_APP_NAME }}\
  -g ${{ Secrets.RESOURCE_GROUP }} \
  –source ${{ github.workspace }}/ingress \
  –registry-server ${{ Secrets.ACR_NAME }}.azurecr.io

• 定义测试部署作业，该作业获取新部署修订版的暂存 URL，并使用 GitHub 操作 ping API 端点 /health 以确保新修订版正在响应。如果运行状况检查成功，容器应用上的 Azure 流量管理器将更新，将所有流量指向新部署的容器。

  注意：请务必将测试部署键缩进与您在上一个项目符号中定义的构建部署键相同的级别：

  特斯t-部署：
  需求：构建-部署
  运行系统：ubuntu-22.04
  脚步：
  – 名称：登录 Azure
  使用：azure/login@v1
  和：
  信用：${{secrets.AZURE_CREDENTIALS }}

  – name: 获取新的容器名称
  运行： |
  # 手动添加containerapp扩展
  az 扩展添加 –name containerapp –upgrade

  # 获取最后部署的修订版本名称
  REVISION_NAME=`az containerapp 修订列表 -n ${{secrets.CONTAINER_APP_NAME }} -g ${{secrets.RESOURCE_GROUP }} –query “[].name” -o tsv |尾巴-1`
  # 获取最后部署的修订版本的 FQDN
  REVISION_FQDN=`az containerapp 修订版显示 -n ${{secrets.CONTAINER_APP_NAME }} -g ${{secrets.RESOURCE_GROUP }} –revision “$REVISION_NAME” –queryproperties.fqdn -o tsv`
  # 将值存储在环境变量中
  回声“REVISION_NAME=$REVISION_NAME”>> $GITHUB_ENV
  回声“REVISION_FQDN=$REVISION_FQDN”>> $GITHUB_ENV

  – 名称：测试部署id：测试部署
  使用：jtalk/url-health-check-action@v3 # 触摸端点的市场操作
  和：
  url: “https://${{ env.REVISION_FQDN }}/health” # 暂存端点

  – name: 部署成功
  运行： |
  echo “部署成功！启用新版本”
  az containerapp 入口流量集 -n ${{ Secrets.CONTAINER_APP_NAME }} -g ${{ Secrets.RESOURCE_GROUP }} –revision-weight “${{ env.REVISION_NAME }}=100”

完整工作流程文件

这是操作工作流程文件的完整文本。

名称：部署到 Azure
在：
推：
分支机构：
– 主要的
拉请求：
分支机构：
– 主要的
工作：
构建部署：
运行系统：ubuntu-22.04
脚步：
– 名称：查看代码库
使用：actions/checkout@v3

– 名称：登录 Azure
使用：azure/login@v1
和：
信用：${{secrets.AZURE_CREDENTIALS }}

– 名称：构建和部署容器
运行： |
# 手动添加containerapp扩展
az 扩展添加 –name containerapp -upgrade

# 使用 Azure CLI 部署更新
az containerapp up -n ${{ Secrets.CONTAINER_APP_NAME }} \
-g ${{ Secrets.RESOURCE_GROUP }} \
–source ${{ github.workspace }}/ingress \
–registry-server ${{ Secrets.ACR_NAME }}.azurecr.io
测试部署：
需求：构建-部署
运行系统：ubuntu-22.04
脚步：
– 名称：登录 Azure
使用：azure/login@v1
和：
信用：${{secrets.AZURE_CREDENTIALS }}

– name: 获取新的容器名称
运行： |
# 安装 Azure CLI 的 containerapp 扩展
az 扩展添加 –name containerapp –upgrade
# 获取最后部署的修订版本名称
REVISION_NAME=`az containerapp 修订列表 -n ${{secrets.CONTAINER_APP_NAME }} -g ${{secrets.RESOURCE_GROUP }} –query “[].name” -o tsv |塔伊尔-1`
# 获取最后部署的修订版本的 FQDN
REVISION_FQDN=`az containerapp 修订版显示 -n ${{secrets.CONTAINER_APP_NAME }} -g ${{secrets.RESOURCE_GROUP }} –revision “$REVISION_NAME” –queryproperties.fqdn -o tsv`
# 将值存储在环境变量中
回声“REVISION_NAME=$REVISION_NAME”>> $GITHUB_ENV
回声“REVISION_FQDN=$REVISION_FQDN”>> $GITHUB_ENV

– 名称：测试部署
id：测试部署
使用：jtalk/url-health-check-action@v3 # 触摸端点的市场操作
和：
url: “https://${{ env.REVISION_FQDN }}/health” # 暂存端点

– name: 部署成功
运行： |
echo “部署成功！启用新版本”
az containerapp 入口流量集 -n ${{ Secrets.CONTAINER_APP_NAME }} -g ${{ Secrets.RESOURCE_GROUP }} –revision-weight “${{ env.REVISION_NAME }}=100”

执行操作工作流程

• 如果使用 GitHub 图形用户界面：

• 点击“开始提交”，根据需要添加提交消息，然后在对话框中选择“提交新文件”。新的工作流程文件将合并到主分支并开始执行。
• 点击“操作”可监控工作流程的进度。

• 如果使用 GitHub CLI：

• 将main.yml添加到Git暂存区：

  git add .github/workflows/main.yml

• 提交文件：

  git commit -m“壮举：创建 GitHub Actions 工作流程”

• 将更改推送到 GitHub：

  git 推送

• 监控工作流程的进度：

  gh 工作流程视图 main.yml –repo /platform

挑战 4：测试 GitHub Actions 工作流程

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

成功更新

创建成功的更新并观察工作流程是否成功。

• 如果使用 GitHub GUI：

• 选择代码 > 入口 > default.conf.template。
• 通过选择带有工具提示“编辑此文件”的铅笔图标，打开 default.conf.template 进行编辑。

• 在文件末尾附近的 location /health 块中，按指示更改返回指令：

  位置/健康状况{
  访问注销；
  return 200 “更新成功！\n”;
  }

• 在对话框中，选择为此提交创建新分支并启动拉取请求，然后选择提出更改。
• 点击“创建拉取请求”以访问拉取请求模板。
• 再次点击“创建拉取请求”以创建拉取请求。
• 点击“操作”可监控工作流程的进度。
• 工作流程完成后，导航到位于/health 端点，其中 是您在挑战 1 第 3 步中记下的 URL。注意更新成功！消息。

• 您可以通过启动终端会话并向应用发送健康检查请求来确认该消息，再次将 替换为您在挑战 1 第 3 步中记录的值：

  卷曲 /health
  更新成功！

• 继续进行不成功的更新。

• 如果使用 GitHub CLI：

• 创建一个名为 patch-1 的新分支：

  git checkout -b patch-1

• 在您首选的文本编辑器中打开 ingress/default.conf.template，然后在文件末尾附近的 location /health 块中，按指示更改返回指令：

  位置/健康状况{
  访问注销；
  return 200 “更新成功！\n”;
  }

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

  git add ingress/default.conf.template

• 提交文件：

  G它提交-m“壮举：更新NGINX入口”

• 将更改推送到 GitHub：

  git push –set-upstream origin patch-1

• 创建拉取请求 (PR)：

  gh pr create –head patch-1 –fill –repo /platform

• 监控工作流程的进度：

  gh 工作流程视图 main.yml –repo /platform

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

  卷曲 /health
  更新成功！

更新失败

现在创建一个不成功的更新并观察工作流程失败。这基本上涉及重复“成功更新”中的步骤，但返回指令的值不同。

• 如果使用 GitHub GUI：

• 选择代码 > 入口 > default.conf.template。
• 在左上角，选择 main然后是您在上一节中创建的以 patch-1 结尾的分支的名称。
• 通过选择带有工具提示“编辑此文件”的铅笔图标，打开 default.conf.template 进行编辑。

• 按指示更改返回指令：

  位置/健康状况{
  访问注销；
  return 500 “更新失败！\n”;
  }

• 选择“直接提交到 -patch-1 分支”，然后选择“提交更改”。
• 选择“操作”以监控工作流程的进度。请注意，当 PR 中的文件更新时，工作流程会再次执行。

• 工作流程完成后，导航到位于 /health 端点的容器应用，其中 是您在挑战 1 第 3 步中记录的 URL。

  请注意，该消息已成功更新！ （与上次成功更新后相同）。尽管这看起来有些矛盾，但它实际上证实了此更新失败 – 更新尝试导致了 status 500（表示内部服务器错误）并且未得到应用。

• 您可以通过启动终端会话并向应用发送健康检查请求来确认该消息，再次将 替换为您在挑战 1 第 3 步中记录的值：

  卷曲 /health
  更新成功！

• 如果使用 GitHub CLI：

• 查看您在上一节中创建的 patch-1 分支：

  git checkout 补丁-1

• 在您喜欢的文本编辑器中打开 ingress/default.conf.template 并再次更改返回指令，如下所示：

  位置/健康状况{
  访问注销；
  return 500 “更新失败！\n”;
  }

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

  git add ingress/default.conf.template

• 提交文件：

  git commit -m“壮举：再次更新 NGINX 入口”

• 将更改推送到 GitHub：

  git 推送

• 监控工作进展流量：

  gh 工作流程视图 main.yml –repo /platform

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

  卷曲 /health
  更新成功！

  消息“更新成功”似乎有些矛盾！ （与上次成功更新后相同）。尽管这看起来有些矛盾，但实际上它证实了此更新失败 – 更新尝试导致状态 500（表示内部服务器错误）并且未应用。

资源清理

您可能希望删除在教程中部署的 Azure 资源，以避免任何潜在的费用：

az 组删除 -n my-container-app-rg -y

如果您愿意，您还可以删除您创建的分叉。

• 如果使用 GitHub GUI：

• 点击“设置”。
• 向下滚动至底部电子页面。
• 点击“删除此存储库”。
• 输入 /platform 并选择我了解后果，删除此存储库。

• 如果使用 GitHub CLI：

  gh repo 删除 /platform -yes

后续步骤

恭喜！您已经了解了如何使用 GitHub Actions 执行微服务应用程序的金丝雀蓝绿部署。查看 GitHub 文档中的这些文章，继续探索和增长您的 DevOps 知识：

• 关于工作流程
• 关于使用 GitHub Actions 进行持续集成
• 关于使用 GitHub Actions 进行持续部署
• 关于监控和故障排除

如果您准备好尝试金丝雀部署的第二步（在生产中进行测试），请查看我们博客上的 2022 年 3 月微服务教程“通过金丝雀部署提高正常运行时间和弹性”。它使用 NGINX Service Mesh 逐步过渡到新的应用程序版本。即使您的部署还没有复杂到需要服务网格，或者您没有使用 Kubernetes，这些原则仍然适用于仅使用 Ingress 控制器或负载均衡器的更简单的部署。

要继续您的微服务教育，请查看 2023 年 3 月的微服务。在第 3 单元“通过自动化加速微服务部署”中，您将了解有关自动化部署的更多信息。