通过

使用 GitHub Actions 部署到 Azure 基础结构

本指南介绍如何使用 CI/CD 和基础结构即代码（IaC）以及 GitHub Actions，以自动化且可重复的方式部署到 Azure（微软云平台）。

本文是 体系结构概述 ，提供了一个结构化解决方案，用于在 Azure 上设计可缩放、安全、可复原且高度可用的应用程序。 若要查看云体系结构和解决方案创意的更多真实示例， 请浏览 Azure 体系结构。

将 IaC 和自动化用于部署的好处

可以通过多种方式部署到 Azure，包括 Azure 门户、CLI、API 等。 对于本指南，我们将使用 IaC 和 CI/CD 自动化。 此方法的优点包括：

  • 声明性：在代码中定义基础结构和部署过程时，可以使用标准软件开发生命周期对其进行版本控制并查看。 IaC 还有助于防止配置中的任何偏移。

  • 一致性：遵循 IaC 流程可确保整个组织遵循标准、完善的方法来部署包含最佳做法的基础结构，并经过强化以满足安全需求。 对中心模板所做的任何改进都可以在整个组织中轻松应用。

  • 安全性：云运营或安全团队可以强化和批准集中管理的模板，以满足内部标准。

  • 自助服务：可以使用集中管理的模板来部署自己的基础结构。

  • 提高工作效率：通过使用标准模板，团队可以快速预配新环境，而无需担心所有实现细节。

可以在 Azure 架构中心中的 可重复基础结构 下找到其他信息，或者在 DevOps 资源中心中查找 什么是基础设施即代码。

Architecture

使用 CI/CD 部署 Azure 的体系结构概述

数据流

  1. 创建新分支并提交所需的 IaC 代码修改。
  2. 准备好将更改合并到环境中后，在 GitHub 中创建拉取请求（PR）。
  3. GitHub Actions 工作流将触发以确保代码格式正确、内部一致并生成安全基础结构。 此外，Terraform Plan 或 Bicep what-if 分析将运行，以生成将在 Azure 环境中发生的更改预览。
  4. 经过适当审查后，可以将 PR 合并到主分支中。
  5. 另一个 GitHub Actions 工作流将从主分支触发，并使用 IaC 提供程序执行更改。
  6. （Terraform 专有功能） 定期运行的 GitHub Action 工作流应查找环境中的配置漂移，并检测到更改时创建一个新问题。

先决条件

使用 Bicep

  1. 创建 GitHub 环境

    工作流利用 GitHub 环境和机密来存储 Azure 标识信息，并为部署设置审批过程。 请按照这些指南创建一个名为production的环境。 在 production 环境中，设置保护规则，并添加任何所需的审批者以批准生产部署。 可以将整个环境限制在主分支上。 可 在此处找到详细说明。

  2. 设置 Azure 标识：

    需要具有在 Azure 订阅中部署的权限的 Azure Active Directory 应用程序。 创建单个应用程序，并在 Azure 订阅中为其授予适当的读/写权限。 接下来设置联合凭据，以允许 GitHub 使用 OpenID Connect（OIDC）标识。 有关详细说明，请参阅 Azure 文档 。 需要添加三个联合凭据：

    • 将实体类型设置为 Environment 并使用 production 环境名称。
    • 将实体类型设置为 Pull Request.
    • 将实体类型设置为 Branch 并使用 main 分支名称。

  3. 添加 GitHub Secrets

    注释

    虽然有关 Azure 标识的任何数据都不包含任何机密或凭据，但我们仍使用 GitHub 机密作为一种方便的方法来参数化每个环境的标识信息。

    使用 Azure 标识在存储库上创建以下机密：

    • AZURE_CLIENT_ID ：Azure 中应用注册的应用程序（客户端）ID
    • AZURE_TENANT_ID：Azure Active Directory 中定义应用注册的租户 ID。
    • AZURE_SUBSCRIPTION_ID：定义应用注册的订阅 ID。

    可 在此处找到将机密添加到存储库的说明。

请使用 Terraform

  1. 配置 Terraform 状态位置

    Terraform 利用 状态文件 来存储有关托管基础结构的当前状态和相关配置的信息。 此文件需要在工作流的不同运行之间持久保存。 建议的方法是在 Azure 存储帐户或类似的远程后端中存储此文件。 通常，此存储将手动或通过单独的工作流进行预配。 Terraform 后端块将需要使用所选存储位置进行更新（请参阅此处以获取文档）。

  2. 创建 GitHub 环境

    工作流利用 GitHub 环境和机密来存储 Azure 标识信息，并为部署设置审批过程。 按照这些说明创建一个名为production的环境。 在 production 环境中设置保护规则，并添加任何需要批准生产部署的必要审批者。 还可以将环境限制为主分支。 可 在此处找到详细说明。

  3. 设置 Azure 标识：

    需要一个具有部署权限的 Azure Active Directory 应用程序才能在您的 Azure 订阅中使用。 为帐户 read-only 和 read/write 帐户创建单独的应用程序，并在 Azure 订阅中为其授予相应的权限。 此外，这两个角色还需要至少 Reader and Data Access 对步骤 1 中 Terraform 状态所在的存储帐户拥有权限。 接下来，设置联合凭据，允许 GitHub 使用 OpenID Connect（OIDC）来利用身份标识。 有关详细说明，请参阅 Azure 文档 。

    read/write对于身份，请创建一个联合凭据，如下所示：

    • Entity Type设置为Environment并使用production环境名称。

    针对read-only身份，请创建两个联合凭据，如下所示：

    • 将 Entity Type 设置为 Pull Request。
    • Entity Type设置为Branch并使用main分支名称。

  4. 添加 GitHub 密钥

    注释

    虽然有关 Azure 标识的任何数据都不包含任何机密或凭据，但我们仍使用 GitHub 机密作为一种方便的方法来参数化每个环境的标识信息。

    使用 read-only 标识在存储库上创建以下机密：

    • AZURE_CLIENT_ID ：Azure 中应用注册的应用程序（客户端）ID
    • AZURE_TENANT_ID ：定义应用注册的 Azure Active Directory 租户 ID。
    • AZURE_SUBSCRIPTION_ID ：定义应用注册所用的订阅 ID。

    可 在此处找到将机密添加到存储库的说明。

    使用production标识在read-write环境中创建另一个机密：

    • AZURE_CLIENT_ID ：Azure 中应用注册的应用程序（客户端）ID

    可 在此处找到将机密添加到环境的说明。 当部署到production环境时，如果需要提升的读/写权限，环境机密将覆盖存储库机密。

使用 GitHub Actions 进行部署

使用 Bicep

参考体系结构中包括两个主要工作流：

  1. Bicep 单元测试

    此工作流在每次提交时运行，由基础设施代码上的一组单元测试组成。 它运行 bicep 生成 ，将 bicep 编译到 ARM 模板。 这可确保没有格式设置错误。 接下来，它会执行 验证 以确保模板可部署。 最后，适用于 IaC 的开源静态代码分析工具 checkov 将运行以检测安全性和符合性问题。 如果存储库正在使用 GitHub 高级安全性（GHAS），结果将上传到 GitHub。

  2. Bicep What-If/Deploy

    此工作流在每个拉取请求和每个提交到主分支时运行。 工作流的 what-if 阶段用于通过运行 what-if 来了解 IaC 更改对 Azure 环境的影响。 然后，此报告会附加到 PR，以便轻松查看。 当工作流被推送到主分支触发时，部署阶段将在 what-if 分析之后运行。 此阶段将在人工审核批准后将模板部署到 Azure。

请使用 Terraform

参考体系结构中包括三个主要工作流：

  1. Terraform 单元测试

    此工作流在每次提交时运行，并由一组针对基础设施代码的单元测试组成。 它运行 terraform fmt ，以确保代码得到正确格式化，并遵循 terraform 的最佳做法。 接下来，它会执行 terraform 验证 ，以检查代码是否在语法上正确且内部一致。 最后，适用于 IaC 的开源静态代码分析工具 checkov 将运行以检测安全性和符合性问题。 如果存储库正在使用 GitHub 高级安全性（GHAS），结果将上传到 GitHub。

  2. Terraform 计划/执行

    此工作流在每个拉取请求和每个提交到主分支时运行。 工作流的计划阶段用于通过运行 terraform 计划来了解 IaC 更改对 Azure 环境的影响。 然后，此报告会附加到 PR，以便轻松查看。 当工作流由推送到主分支触发时，应用阶段将在计划后运行。 如果环境有任何挂起的更改，此阶段将采用计划文档，并在手动评审注销后 应用 更改。

  3. Terraform 偏移检测

    此工作流定期运行，以扫描环境以查找 Terraform 外部所做的任何配置偏移或更改。 如果检测到任何偏移，则会引发 GitHub 问题，以提醒项目的维护人员。

  • Last updated on