在 Azure 容器应用中为 Python Web 应用配置持续部署

项目
02/07/2024

本文是有关如何将 Python Web 应用容器化和部署到 Azure 容器应用的教程的一部分。借助容器应用，无需管理复杂的基础结构，即可部署容器化应用。

本教程的这一部分介绍如何为容器应用配置持续部署或交付（CD）。 CD 是持续集成/持续交付（CI/CD）的 DevOps 实践的一部分，这是应用开发工作流的自动化。具体而言，使用 GitHub Actions 进行持续部署。

此服务关系图突出显示了本文中介绍的组件：CI/CD 的配置。

先决条件

若要设置持续部署，需要：

在本教程系列的上一篇文章中创建的资源及其配置，其中包括 Azure 容器应用中的Azure 容器注册表和容器应用。
GitHub 帐户，在其中分叉了示例代码（Django 或 Flask），可以从 Azure 容器应用连接到该帐户。（如果下载了示例代码而不是分叉，请确保将本地存储库推送到 GitHub 帐户。
（可选）在开发环境中安装的 Git ，用于在 GitHub 中更改代码并推送到存储库。或者，可以直接在 GitHub 中进行更改。

为容器配置 CD

在本教程的上一篇文章中，你在 Azure 容器应用中创建了并配置了容器应用。配置的一部分是从Azure 容器注册表拉取 Docker 映像。创建容器修订时，容器映像将从注册表拉取，例如首次设置容器应用时。

在本部分中，你将使用 GitHub Actions 工作流设置持续部署。通过持续部署，会基于触发器创建新的 Docker 映像和容器修订。本教程中的触发器是对存储库的主分支的任何更改，例如使用拉取请求（PR）。触发时，工作流会创建新的 Docker 映像，将其推送到Azure 容器注册表，并使用新映像将容器应用更新为新的修订。

Azure CLI
Azure 门户

可以在 Azure Cloud Shell 中或装有 Azure CLI 的工作站上运行 Azure CLI 命令。

如果在 Windows 计算机上的 Git Bash shell 中运行命令，请在继续操作之前输入以下命令：

export MSYS_NO_PATHCONV=1

步骤 1. 使用 az ad sp create-for-rbac 命令创建服务主体。

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

其中：

<app-name> 是服务主体的可选显示名称。如果退出该 --name 选项，则会生成 GUID 作为显示名称。
<subscription-ID> 是唯一标识 Azure 中的订阅的 GUID。如果不知道订阅 ID，可以运行 az account show 命令，并将其从 id 输出中的属性复制。
<resource-group-name> 是包含 Azure 容器应用容器的资源组的名称。基于角色的访问控制（RBAC）位于资源组级别。如果按照本教程中上一篇文章中的步骤操作，则资源组名称为 pythoncontainer-rg。

为下一步保存此命令的输出，特别是客户端 ID（appId 属性）、客户端机密（password 属性）和租户 ID（tenant 属性）。

步骤 2. 使用 az containerapp github-action add 命令配置 GitHub Actions。

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

其中：

<resource-group-name> 是资源组的名称。如果遵循本教程，则为“pythoncontainer-rg”。
<https://github.com/userid/repo> 是 GitHub 存储库的 URL。如果按照本教程中的步骤操作，它将是 GitHub 用户 ID 所在的位置https://github.com/userid/msdocs-python-django-azure-container-apps，或者https://github.com/userid/msdocs-python-flask-azure-container-apps是 GitHub userid 用户 ID。
<registry-name> 是为本教程创建的现有容器注册表，也可以是可以使用的容器注册表。
<client-id> 是上一az ad sp create-for-rbac命令中属性的值appId。 ID 是格式为 00000000-0000-0000-00000-000000000 的 GUID。
<tenant-id> 是上一az ad sp create-for-rbac命令中属性的值tenant。 ID 也是类似于客户端 ID 的 GUID。
<client-secret> 是上一az ad sp create-for-rbac命令中的属性的值password。

在持续部署的配置中， 服务主体 用于使 GitHub Actions 能够访问和修改 Azure 资源。对资源的访问权限受分配给服务主体的角色的限制。服务主体在包含容器应用的资源组上分配了内置 参与者 角色。

如果遵循门户的步骤，则会自动创建服务主体。如果已按照 Azure CLI 的步骤操作，请先显式创建服务主体，然后再配置持续部署。

使用 GitHub Actions 重新部署 Web 应用

在本部分中，将更改示例存储库的分叉副本，并确认该更改已自动部署到网站。

如果尚未创建，请创建示例存储库（Django 或 Flask）的分支。可以直接在 GitHub 或开发环境中通过 Git 命令行更改代码。

GitHub
命令行

步骤 1. 转到示例存储库的分支，并在主分支中启动。

步骤 2. 进行更改。

转到 /templates/base.html 文件。（对于 Django，路径为： restaurant_review/templates/restaurant_review/base.html。）
选择“ 编辑 ”并将短语“Azure 餐厅评审”更改为“Azure 餐厅评审 - 重新部署”。

步骤 3. 直接将更改提交到主分支。

在正在编辑的页面底部，选择“ 提交 ”按钮。
提交将启动 GitHub Actions 工作流。

如果尚未使用，则用于 git clone 将分叉存储库拉取到开发环境，并将目录更改为存储库。

步骤 1. 从主开始。

git checkout main
git pull

步骤 2. 进行更改。

转到 ./templates/base.html 文件（./restaurant_review/templates/restaruant_review/base.html for Django），并将短语“Azure 餐厅评论”更改为“Azure 餐厅评审 - 重新部署”。

步骤 3. 提交更改并将其推送到 GitHub。

git commit -a -m "Redeploy with title change."
git push

首次使用 git 时，可能需要设置全局变量“user.name”和“user.email”。有关详细信息，请参阅 git-config 的帮助。

将更改推送到主分支将启动 GitHub Actions 工作流。

注意

我们演示了直接在主分支中进行更改。在典型的软件工作流中，你将在除 main 以外的分支中进行更改，然后创建一个拉取请求（PR），将这些更改合并到 main 中。 PR 还会启动工作流。

关于 GitHub Actions

步骤 1. 在 GitHub 上，转到示例存储库的分支并打开“操作”选项卡。

这些步骤使用 GitHub CLI。

步骤 1. 获取工作流摘要。在包含克隆的文件夹中运行以下命令：

gh workflow view

此命令会提示你选择一个工作流，然后概述该工作流的最近运行情况。

注意

首次使用 gh 时，系统可能会提示你进行身份验证。按照 GitHub CLI 提示进行身份验证。

如果配置了多个远程，系统可能会要求你运行gh repo set-default以选择默认远程存储库。从显示的选项中选择分支。

可以从任何文件夹中运行 gh workflow view 命令，而无需通过添加 --repo [HOST/]OWNER/REPO 参数来设置默认存储库。

步骤 2. 有关工作流运行的详细信息，请转到 GitHub。

gh workflow view --web

工作流机密

在添加到存储库的 .github/workflows/<workflow-name>.yml 工作流文件中，你将看到工作流的生成和容器应用更新作业所需的凭据的占位符。凭据信息存储在存储库中，设置安全/机密和变量/操作下。

如果凭据信息发生更改，可以在此处更新它。例如，如果重新生成Azure 容器注册表密码，则需要更新REGISTRY_PASSWORD值。有关详细信息，请参阅 GitHub 文档中的加密机密。

OAuth 授权的应用

设置持续部署时，可将 Azure 容器应用授权为 GitHub 帐户的授权 OAuth 应用。容器应用使用授权的访问权限在 .github/workflows/<workflow-name> 中创建 GitHub Actions YML 文件.yml。可以在帐户的 Integrations/Applications 下查看授权应用并撤销权限。

故障排除提示

使用 Azure CLI az ad sp create-for-rba 命令设置服务主体时出错。

收到包含“InvalidSchema：找不到连接适配器”的错误。
- 检查正在运行的 shell。如果使用 Bash shell，请按如下所示 export MSYS_NO_PATHCONV=1设置MSYS_NO_PATHCONV变量。有关详细信息，请参阅 GitHub 问题：无法从 git bash shell 使用 Azure CLI 创建服务主体，找不到连接适配器。
收到包含“多个应用程序具有相同显示名称”的错误。
- 此错误表示服务主体的名称已被采用。选择另一个名称或离开 --name 参数，GUID 将自动生成为显示名称。

GitHub Actions 工作流失败。

若要检查工作流的状态，请转到存储库的“操作”选项卡。
如果工作流失败，请钻取其工作流文件。应有两个作业“生成”和“部署”。对于失败的作业，请查看作业任务的输出以查找问题。
如果看到带有“TLS 握手超时”的错误消息，请在存储库的“操作”选项卡下选择“触发自动部署”来手动运行工作流，以查看超时是否是临时问题。
如果为容器应用设置持续部署，如本教程所示，将自动为你创建工作流文件（.github/workflows/<workflow-name>.yml）。无需修改本教程的此文件。如果这样做，还原更改并尝试工作流。

网站不显示合并在主分支中的更改。

在 GitHub 中：检查运行 GitHub Actions 工作流，并检查更改到触发工作流的分支中。
在Azure 门户：检查Azure 容器注册表，以查看更改分支后是否使用时间戳创建了新的 Docker 映像。
在Azure 门户：检查容器应用的日志。如果出现编程错误，你将在此处看到该错误。
- 转到容器应用 |修订管理 | <活动容器> |修订详细信息 |控制台日志
- 选择列的顺序以显示“生成时间”、“Stream_s”和“Log_s”。首先按最新的日志进行排序，并在“Stream_s”列中查找 Python stderr 和 stdout 消息。 Python“print”输出将是 stdout 消息。
使用 Azure CLI 时，请使用 az containerapp logs show 命令。

断开连接持续部署时会发生什么情况？

停止持续部署意味着断开容器应用与存储库的连接。若要断开连接：<
- 在Azure 门户中，转到容器应用，选择“持续部署资源”，然后选择“断开连接”。
- 使用 Azure CLI 时，请使用 az container app github-action remove 命令。
断开连接后，在 GitHub 存储库中：
- .github/workflows/<workflow-name>.yml 文件将从存储库中删除。
- 不会删除机密密钥。
- Azure 容器应用仍作为 GitHub 帐户的授权 OAuth 应用。
断开连接后，在 Azure 中：
- 容器保留在上次部署的容器中。可以将容器应用与Azure 容器注册表重新连接，以便新的容器修订选取最新的映像。
- 不会删除创建并用于持续部署的服务主体。

后续步骤

如果已完成本教程，并且不想产生额外费用，请删除使用的资源。删除资源组会删除组中的所有资源，并且是删除资源最快的方法。有关如何删除资源组的示例，请参阅 Containerize 教程清理。

如果打算在本教程的基础上进行构建，可以执行以下后续步骤。

Share via