通过

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

  • 项目

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

在本教程中，你将：

  • 使用 GitHub Actions 工作流为容器应用配置持续部署。
  • 更改示例存储库的副本以触发 GitHub Actions 工作流。
  • 排查在配置持续部署过程中可能会遇到的问题。
  • 完成教程系列后，删除不需要的资源。

持续部署与持续集成和持续交付（CI/CD）的 DevOps 实践相关，这是应用开发工作流的自动化。

下图突出显示了本教程中的任务。

Azure 容器应用上部署 Python 应用所涉及的服务关系图，其中突出显示了有关持续部署的部分。

先决条件

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

  • 在上一教程中创建的资源（及其配置），其中包括 Azure 容器注册表 实例，以及 Azure 容器应用中的容器应用。

  • 一个 GitHub 帐户，你在其中为示例代码（Django 或 Flask）创建分支，并且可以从 Azure 容器应用连接到此帐户。 （如果下载了示例代码而不是派生，请确保将本地存储库推送到你的 GitHub 帐户。）

  • （可选）在开发环境中安装的 Git，以便在 GitHub 中更改代码并推送到存储库。 或者，可以直接在 GitHub 中进行更改。

为容器配置持续部署

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

在本部分中，你将使用 GitHub Actions 工作流设置持续部署。 在持续部署的过程中，新的 Docker 镜像和容器修订版是由触发器生成的。 本教程中的触发器是对存储库主分支的任何更改，例如拉取请求。 触发工作流时，它会创建新的 Docker 映像，将其推送到 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>"

    在命令中：

    • <应用名称> 是服务主体的可选显示名称。 如果离开 --name 选项，则会生成 GUID 作为显示名称。
    • <订阅 ID> 是唯一标识 Azure 中的订阅的 GUID。 如果您不知道您的订阅 ID，可以运行 az account show 命令，然后从输出中的 id 属性中复制订阅 ID。
    • <资源组名称> 是包含 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

    在命令中：

    • <资源组名称> 是资源组的名称。 本教程涉及的是 pythoncontainer-rg。
    • <https://github.com/userid/repo> 是 GitHub 存储库的 URL。 本教程中涉及的是 https://github.com/userid/msdocs-python-django-azure-container-apps 或 https://github.com/userid/msdocs-python-flask-azure-container-apps。 在这些 URL 中，userid 是 GitHub 用户 ID。
    • <注册表名称> 是在上一教程中创建的现有 Azure 容器注册表实例，也可以是可以使用的实例。
    • <客户端 ID> 是上一 az ad sp create-for-rbac 命令中 appId 属性的值。 ID 是采用 00000000-0000-0000-0000-00000000 格式的 GUID。
    • <租户 ID> 是上一 az ad sp create-for-rbac 命令中 tenant 属性的值。 ID 也是一种类似于客户端 ID 的 GUID。
    • <客户端机密> 是上一 az ad sp create-for-rbac 命令中 password 属性的值。

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

如果按照门户的步骤进行操作，将会自动为你创建服务主体。 如果已按照 Azure CLI 的步骤操作，在配置持续部署之前显式创建了服务主体。

使用 GitHub Actions 重新部署 Web 应用

在本节中，你将对示例存储库的分支副本进行更改。 之后，可以确认更改已自动部署到网站。

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

  1. 转到示例存储库的分支，然后从主分支开始。

    显示示例存储库分支中主分支的屏幕截图。

  2. 做出改变：

    1. 转到 /templates/base.html 文件。 （对于 Django，路径为 restaurant_review/templates/restaurant_review/base.html。）
    2. 选择 编辑 并将短语 Azure Restaurant Review 更改为 Azure Restaurant Review - Redeployed。

    显示如何在示例存储库分支中的模板文件中进行更改的屏幕截图。

  3. 在正在编辑的页面底部，确保选中直接提交到主分支。 然后选择提交更改按钮。

    显示了用于在示例存储库分支中的模板文件中提交更改选择的屏幕截图。

提交将启动 GitHub Actions 工作流。

注意

本教程介绍如何直接在主分支上进行更改。 在典型的软件工作流中，在主分支以外的分支中进行更改，然后创建一个拉取请求，将更改合并到主分支。 拉取请求也会启动工作流。

了解 GitHub Actions

查看工作流历史记录

如果需要查看工作流历史记录，请使用以下过程之一。

在 GitHub 上，转到示例存储库的分支，打开操作选项卡。

屏幕截图，显示存储库的“操作”选项卡上的工作流。

工作流机密

.github/workflows/<workflow-name>.yml 工作流文件已添加到存储库中，该文件包含工作流中生成作业和容器应用更新作业所需的凭据占位符。 凭据信息以加密形式存储在代码库的设置 区域，位于安全性>机密和变量>操作之下。

将凭据显示为 GitHub Actions 机密的屏幕截图。

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

OAuth 授权的应用

设置持续部署时，请将 Azure 容器应用指定为 GitHub 帐户的授权 OAuth 应用。 容器应用使用授权的访问权限在 .github/workflows/<工作流名称>.yml中创建 GitHub Actions YAML 文件。 可以在 集成>应用程序下查看授权应用，并在帐户中撤销权限。

显示 GitHub 中用户授权应用的位置的屏幕截图。

疑难解答

通过 Azure CLI 设置服务主体时遇到错误

本部分可帮助解决使用 Azure CLI az ad sp create-for-rba 命令设置服务主体时遇到的错误。

如果收到包含“InvalidSchema：找不到连接适配器”错误：

如果收到包含“多个应用程序具有相同显示名称”的错误：

  • 服务主体的名称已被采用。 选择另一个名称，或省略 --name 参数。 GUID 将自动生成为显示名称。

GitHub Actions 工作流失败

若要检查工作流的状态，请转到存储库 操作 选项卡：

  • 如果工作流失败，请深入查看工作流文件。 应有两个作业：构建和部署。 对于失败的作业，请检查作业任务的输出以查找问题。
  • 如果有包含“TLS 握手超时”的错误消息，请手动运行工作流。 在存储库的 操作 选项卡上，选择 触发自动部署 以查看超时是否是临时问题。
  • 如果为容器应用设置持续部署，如本教程所示，将自动为你创建工作流文件（.github/workflows/<工作流名称>.yml）。 无需修改本教程的此文件。 如果执行了此操作，请将其还原并尝试工作流。

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

在 GitHub 中：

  • 检查 GitHub Actions 工作流是否已运行，以及你是否已将更改提交到触发工作流的分支。

在 Azure 门户中：

  • 检查 Azure 容器注册表实例，以查看更改分支后是否使用时间戳创建了新的 Docker 映像。

  • 检查容器应用的日志，查看是否存在编程错误：

    1. 转到容器应用，然后转到 修订管理><活动容器>>修订详细信息>控制台日志。
    2. 选择显示生成时间、Stream_s 和 Log_s 列的顺序。
    3. 按最新日志进行排序，并在 Stream_s 列中查找 Python stderr 和 stdout 消息。 Python print 输出 stdout 消息。

在 Azure CLI 中：

想要停止持续部署

停止持续部署意味着断开容器应用与存储库的连接。

在 Azure 门户中：

  • 转到容器应用。 在服务菜单上，选择 持续部署，然后选择 断开连接。

在 Azure CLI 中：

断开连接后：

  • .github/workflows/<工作流名称>.yml 文件将从存储库中删除。
  • 不会从存储库中删除机密密钥。
  • Azure 容器应用仍作为 GitHub 帐户的授权 OAuth 应用。
  • 在 Azure 中，容器保留着上次部署的容器。 可以将容器应用重新连接到 Azure 容器注册表实例，确保新的容器修订版能够获取最新的映像。
  • 在 Azure 中，不会删除你创建并用于持续部署的服务主体。

删除资源

如果已完成教程系列，并且不希望产生额外费用，请删除使用的资源。

删除资源组会删除组中的所有资源，并且是删除资源最快的方法。 有关如何删除资源组的示例，请参阅容器化教程清理。

相关内容

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