了解端到端部署

5 分钟

GitHub Actions 工作流是一种灵活的工具，可以通过许多不同的方式进行配置以满足需求。本单元将介绍如何使用工作流来部署整个解决方案，包括配置 Azure 基础结构，以及执行其他部署操作。

多少工作流？

在某些组织中，管理 Azure 环境的团队不同于开发在环境中运行的代码的团队。在这些情况下，通常倾向于创建多个工作流，每个工作流都由负责该特定领域的团队拥有。例如，你可以创建一个工作流来部署 Bicep 代码，用于部署网站的 Azure 资源，同时再创建另一个工作流，用于部署网站应用程序。

尽管这种方法可能会在管理工作流方面提供一些灵活性，但可能较难保持所有内容同步。例如，假设你的网站团队需要在其 Azure 应用服务应用上进行新设置，以启用其正在生成的功能。除非基础结构部署工作流成功完成，否则应用程序部署工作流将无法运行。此外，在工作流之间发送数据（如基础结构工作流创建的 Azure 资源的名称）可能会变得复杂。

相比之下，最好创建单个工作流来部署解决方案所需的所有内容，即使由不同的团队或不同的人员管理组件也是如此。可以使用 Git 和 GitHub 等工具来协调工作。添加新功能后，可以使用分支对 Bicep 文件进行必要的更改。如果更改已准备好进行集成和发布，单个工作流可执行生成和部署解决方案所需的全部步骤，从而减少发生不同步的可能性。

提示

为解决方案生成代码时，可能需要经常进行部署，以便测试其工作原理。你会发现，将基础结构与应用程序代码一起部署会使工作流运行缓慢并阻碍进度。

如果你处于这种情况，可以考虑禁用开发环境的基础结构部署。可以使用路径筛选器、可重用工作流和条件来实现此目的。但是对于其他环境，应保持完整部署序列不变。

控制平面和数据平面

许多 Azure 资源提供两种不同的访问平面。控制平面用于部署和配置资源。数据平面用于访问资源的功能。

创建和部署 Bicep 文件时，会与控制平面进行交互。在 Azure 中，控制平面为 Azure 资源管理器。可使用资源管理器定义每个资源的配置。

但除了与控制平面交互，你的工作流通常还需要执行其他操作。例如，你可能需要：

将 Blob 上传到存储帐户。
修改数据库架构。
对第三方服务进行 API 调用。
触发机器学习模型更新。
将网站部署到 Azure 应用服务应用。
将软件部署到虚拟机。
向第三方提供程序注册 DNS 条目。

考虑端到端工作流时，通常需要部署 Azure 资源，然后针对这些资源的数据平面执行一系列操作。有时，这些操作被称为部署的“最后一英里”，因为你是通过使用控制平面来执行大部分的部署，并且仅剩下少量的配置。

注意

某些资源在控制平面和数据平面之间没有明确的划分。其中包括 Azure 数据工厂和 Azure API 管理。这两种服务都支持使用 Bicep 进行完全自动化部署，但需要特别注意。在模块结尾的“总结”页面上可以找到有关更多信息的链接。

如何执行数据平面操作

创建与资源的数据平面交互的部署工作流时，可以使用以下三种常见方法中的任意一种：

资源管理器部署脚本
工作流脚本
工作流操作

资源管理器部署脚本在 Bicep 文件中进行定义。它们运行 Bash 或 PowerShell 脚本，并可以与 Azure CLI 命令和 Azure PowerShell cmdlet 进行交互。为部署脚本创建托管标识以用于对 Azure 进行身份验证，Azure 会自动预配和管理运行部署脚本所需的其他资源。

需要在部署过程中运行基本脚本时，部署脚本是不错的选择，但是，它们不会让你轻松访问工作流中的其他元素。

还可以从部署工作流中运行自己的逻辑。 GitHub Actions 为需要执行的工作提供丰富的操作生态系统。如果找不到满足需求的操作，可以使用脚本运行自己的 Bash 或 PowerShell 代码。工作流操作和脚本从工作流的运行器运行。通常，需要向正在使用的服务的数据平面验证操作或脚本，而如何执行此操作取决于服务。

工作流操作和脚本提供了灵活性和控制力。还可通过它们访问工作流项目，工作流项目将在后续部分介绍。本模块将重点介绍工作流操作。在模块结尾的“总结”页面上，我们提供了有关资源管理器部署脚本更多信息的链接。

输出

工作流通常通过部署 Bicep 文件来创建和配置 Azure 资源。然后，工作流的后续部分与这些资源的数据平面进行交互。为了能够与资源交互，工作流操作和步骤需要有关已创建的 Azure 资源的信息。

例如，假设你有一个部署存储帐户的 Bicep 文件。你希望工作流部署存储帐户，然后将一些 Blob 上传到存储帐户中的 Blob 容器。上传 Blob 的工作流步骤需要知道要连接到的存储帐户的名称以及要将文件上传到的 Blob 容器的名称。

最佳做法是让 Bicep 文件决定 Azure 资源的名称。它可能会使用参数、变量或表达式来创建存储帐户和 Blob 容器的名称。然后，Bicep 文件可以公开提供每个资源名称的输出。工作流中的后续步骤可以读取输出值。这样一来，工作流定义就不需要硬编码任何名称或其他信息，这些信息可能会在不同的环境中发生变化，或者基于在 Bicep 文件中定义的规则。

通过 GitHub Actions，可以使用管道变量传播输出的值。 azure/arm-deploy 操作会自动为每个 Bicep 部署输出创建变量。还可以在脚本中手动创建工作流变量。在本模块结尾的“总结”页面上可以找到有关更多信息的链接。

访问在另一个作业中创建的变量时，需要发布该变量，使其可供读取它的作业访问。例如，假设创建了一个部署 Bicep 文件的作业，并且需要将 appServiceAppName 输出传播到工作流。你使用 outputs 关键字指定 appServiceAppName 工作流变量应设置为 deploy 步骤创建的 appServiceAppName 输出变量的值：

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

然后，在稍后的作业中，通过包含 needs 关键字创建对创建变量的作业的显式依赖项，并使用已发布变量的名称引用该变量：

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

通过使用 Bicep 输出和工作流变量，可以创建一个工作流来部署 Bicep 代码，然后在部署过程中对资源执行各种操作。

了解端到端部署

多少工作流？

控制平面和数据平面

如何执行数据平面操作

输出

反馈