Share via

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 GitOps 的 CI/CD 工作流 (Flux v2)

  • 项目

新式 Kubernetes 部署包含多个应用程序、群集和环境。 使用 GitOps 可以更轻松地管理这些复杂的设置，并通过 Git 以声明方式跟踪 Kubernetes 环境的所需状态。 使用常见的 Git 工具声明群集状态，可以增强问责机制、简化故障调查，并启用自动化来管理环境。

本文介绍 GitOps 如何使用 Azure Arc、Azure Repos 和 Azure Pipelines 适配整个应用程序更改生命周期。 它还提供了 GitOps 控制的 Kubernetes 环境中的单个应用程序更改的示例。

体系结构

此图显示了部署到一个或多个 Kubernetes 环境的应用程序的 CI/CD 工作流。

GitOps CI/CD 体系结构图。

应用程序代码存储库

应用程序存储库包含开发人员在运行其内部循环期间处理的应用程序代码。 应用程序的部署模板以某种常规格式（例如 Helm 或 Kustomize）驻留在此存储库中。 特定于环境的值不存储在存储库中。

对此存储库进行更改会调用一个启动部署过程的 PR 或 CI 管道。

容器注册表

容器注册表保存 Kubernetes 环境中使用的所有第一方和第三方映像。 使用用户可读的标记以及用于生成映像的 Git 提交来标记第一方应用程序映像。 可能会缓存第三方映像，以帮助提高安全性、速度和复原能力。 设置计划以便及时测试和集成安全更新。

有关详细信息，请参阅如何使用 Azure 容器注册表任务来使用和维护公共内容。

PR 管道

开发人员向应用程序存储库发出的拉取请求取决于 PR 管道是否能够成功运行。 此管道运行基本质量门，例如对应用程序代码运行 Lint 检查和单元测试。 该管道将测试应用程序，并通过 Lint 检查用于部署到 Kubernetes 环境的 Dockerfile 和 Helm 模板。 应生成并测试 Docker 映像，但不要推送映像。 使管道持续时间保持相对较短，以便快速迭代。

CI 管道

应用程序 CI 管道运行所有 PR 管道步骤，并扩展测试和部署检查。 可对主分支的每个提交运行管道，也可以按照固定的频率对一组提交运行管道。

在此阶段，可以执行对于 PR 管道消耗过高的应用程序测试，包括：

  • 将映像推送到容器注册表
  • 映像生成、Lint 分析和测试
  • 原始 YAML 文件的模板生成

CI 生成结束时，会生成工件。 这些工件可由 CD 步骤使用，为部署做准备。

Flux 群集扩展

Flux 是一个作为群集扩展在每个群集中运行的代理。 此 Flux 群集扩展负责维护所需状态。 该代理按用户定义的间隔轮询 GitOps 存储库，然后将群集状态与 Git 存储库中声明的状态进行核对。

有关详细信息，请参阅教程：使用 GitOps with Flux v2 部署应用程序。

CD 管道

CI 生成成功时会自动触发 CD 管道。 在此管道环境中，会在先前发布的模板中替换为特定于环境的值，并使用这些值针对 GitOps 存储库提出新的拉取请求。 此拉取请求包含对一个或多个 Kubernetes 群集的所需状态的建议更改。 群集管理员评审拉取请求，并批准合并到 GitOps 存储库。 管道等待拉取请求合并，然后 Flux 同步并应用状态更改。

GitOps 存储库

GitOps 存储库代表各个群集中所有环境的当前所需状态。 对此存储库所做的任何更改将由每个群集中的 Flux 服务拾取，并予以部署。 对群集所需状态的更改以拉取请求的形式呈现，然后经过评审，最终在更改获得批准后合并。 这些拉取请求包含对部署模板以及生成的 Kubernetes 清单所做的更改。 使用在低级别呈现的清单可以更仔细地检查在模板级别通常看不到的更改。

GitOps 连接器

GitOps 连接器在 Flux 代理与 GitOps 存储库/CD 管道之间创建连接。 向群集应用更改时，Flux 会将每项阶段更改和执行的运行状况检查通知给 GitOps 连接器。 此组件充当适配器。 它理解如何与 Git 存储库通信，并会更新 Git 提交状态，以便在 GitOps 存储库中显示同步进度。 部署完成时（无论是成功还是失败），连接器将通知 CD 管道继续，使管道能够执行部署后的活动，例如集成测试。

Kubernetes 群集

至少有一个已启用 Azure Arc 的 Kubernetes 或 Azure Kubernetes 服务 (AKS) 群集为应用程序所需的不同环境提供服务。 例如，一个群集可以通过不同的命名空间为开发和 QA 环境提供服务。 另一个群集可以提供更简便的环境隔离和更精细的控制。

示例工作流

作为应用程序开发人员，Alice 需要：

  • 编写应用程序代码。
  • 确定如何在 Docker 容器中运行应用程序。
  • 定义用于在 Kubernetes 群集中运行容器和相关服务的模板。

Alice 想要确保应用程序能够在多个环境中运行，但她并不知道每个环境的具体设置。

假设 Alice 想要做出某项应用程序更改，此项更改会改变应用程序部署模板中使用的 Docker 映像。

  1. Alice 更改了部署模板，将其推送到了应用程序存储库中名为 alice 的远程分支，并创建了拉取请求以针对 main 分支进行评审。

  2. Alice 请求她的团队评审更改。

    • PR 管道运行验证。
    • 在 PR 管道运行成功并且团队批准后，将合并更改。

  3. 然后，CI 管道将会启动，验证 Alice 的更改并成功完成。

    • 此更改可以安全地部署到群集，并且项目将保存到 CI 管道运行。

  4. 成功的 CI 管道运行会触发 CD 管道。

    • CD 管道拾取 Alice 的 CI 管道运行存储的项目。
    • CD 管道将模板替换为环境特定的值，并暂存针对 GitOps 存储库中现有群集状态的任何更改。
    • CD 管道使用群集状态的所需更改针对 GitOps 存储库的生产分支创建拉取请求。

  5. Alice 的团队评审并批准她的拉取请求。

    • 更改将合并到与环境对应的目标分支中。

  6. 在几分钟内，Flux 将会注意到 GitOps 存储库中发生了更改，并拉取 Alice 的更改。

    • 由于 Docker 映像的更改，应用程序 Pod 需要更新。
    • Flux 将应用对群集的更改。
    • Flux 通过 GitOps 连接器将部署状态报告回 GitOps 存储库。

  7. CD 管道运行自动化测试，以验证新部署是否成功完成并按预期方式工作。

    注意

    对于其他面向部署的环境，CD 管道将通过为下一个环境创建拉取请求并重复步骤 4-7 来不断迭代。 该过程可能需要对风险更高的部署或环境（例如安全相关的更改或生产环境）进行额外的批准。

  8. 所有环境收到成功的部署后，管道即告完成。

后续步骤