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

使用 GitHub Actions 和 GitFlow 实现 AKS 应用的 CI/CD

Azure 容器注册表
Azure Kubernetes 服务 (AKS)
Azure Monitor
Azure Pipelines

GitOps 是一种适用于云原生应用程序的操作模型,用于将应用程序和声明性基础结构代码存储在 Git 中,以便其用作自动持续交付的真实来源。 使用 GitOps,你可以在 Git 存储库中描述你的整个系统的所需状态,然后 GitOps 操作器会将其部署到你的环境(通常是一个 Kubernetes 群集)。 有关 Azure 上 Kubernetes 的 GitOps 的更多信息,请访问 Azure Kubernetes 服务的 GitOps已启用 Azure Arc 的 Kubernetes 的 CI/CD 和 GitOps 规则

本文中的示例方案适用于希望通过使用容器、用于生成的持续集成 (CI) 和用于持续部署 (CD) 的 GitOps 来实现端到端应用程序开发现代化的企业。 在此方案中,一个 Flask 应用将用作示例。 此 Web 应用由使用 Python 和 Flask 框架编写的前端组成。

体系结构

以下选项探讨了基于推送和基于拉取的 CI/CD 方法。

选项 1:基于推送的 CI/CD

Diagram of the push-based architecture with GitHub Actions.

基于推送的体系结构,其中包含用于 CI 和 CD 的 GitHub Actions。

下载此体系结构的 Visio 文件

数据流

此方案涵盖一个两层 Web 应用程序(包含一个前端 Web 组件和一个使用 Redis 的后端)的基于推送的 DevOps 管道。 此管道使用 GitHub Actions 进行生成和部署。 数据流经方案的情形如下所示:

  1. 应用代码被开发出来。
  2. 应用代码提交到 GitHub git 存储库。
  3. GitHub Actions 从应用代码生成容器映像,并将容器映像推送到 Azure 容器注册表。
  4. GitHub Actions 作业使用 kubectl 或部署到 Kubernetes 群集操作将清单文件中所述的应用部署(或推送)到 Azure Kubernetes 服务 (AKS) 群集。

选项 2:基于拉取的 CI/CD (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

基于拉取的体系结构,其中包含用于 CI 的 GitHub Actions 和用于 CD 的 Argo CD。

下载此体系结构的 Visio 文件

数据流

此方案涵盖一个两层 Web 应用程序(包含一个前端 Web 组件和一个使用 Redis 的后端)的基于拉取的 DevOps 管道。 此管道使用 GitHub Actions 进行生成。 对于部署,它使用 Argo CD 作为 GitOps 操作器来拉取/同步应用。 数据流经方案的情形如下所示:

  1. 应用代码被开发出来。
  2. 应用代码提交到 GitHub 存储库。
  3. GitHub Actions 从应用代码生成容器映像,并将容器映像推送到 Azure 容器注册表。
  4. GitHub Actions 根据 Azure 容器注册表中容器映像的版本号来使用当前映像版本更新 Kubernetes 清单部署文件。
  5. Argo CD 与 Git 存储库同步或从中拉取数据。
  6. Argo CD 将应用部署到 AKS 群集。

组件

  • GitHub Actions 是一种自动化解决方案,可以与 Azure 服务集成以实现持续集成 (CI)。 在本方案中,GitHub Actions 会根据提交到源代码管理中的内容协调新容器映像的创建过程,接着将这些映像推送到 Azure 容器注册表,然后更新 GitHub 存储库中的 Kubernetes 清单文件。
  • Azure Kubernetes 服务 (AKS) 是一种托管 Kubernetes 平台,可以让用户在没有容器业务流程专业知识的情况下部署和管理容器化的应用程序。 作为一个托管 Kubernetes 服务,Azure 可以自动处理运行状况监视和维护等关键任务。
  • Azure 容器注册表存储和管理 AKS 群集使用的容器映像。 映像会以安全的方式进行存储,并可通过 Azure 平台复制到其他区域以加快部署速度。
  • GitHub 是一种基于 Web 的源代码管理系统,在 Git 上运行,由开发人员用来存储应用程序代码并对其进行版本控制。 在此方案中,GitHub 用于将源代码存储在 Git 存储库中,然后,GitHub Actions 将用于执行容器映像的生成,并在基于推送的方法中将容器映像推送到 Azure 容器注册表。
  • Argo CD 是一种与 GitHub 和 AKS 集成的开源 GitOps 操作器。 Argo CD 支持持续部署 (CD)。 Flux 本来可以用于此目的,但 Argo CD 展示了应用团队如何可以为其特定的应用程序生命周期问题选择单独的工具,而不是使用群集操作员用于群集管理的同一工具。
  • Azure Monitor 可以跟踪性能、维护安全和确定趋势。 Azure Monitor 获得的指标可供其他资源和工具(例如 Grafana)使用。

备选方法

  • Azure Pipelines 可帮助你为任何应用实现 CI/CD 和测试管道。
  • Jenkins 是一种开源的自动化服务器,可与 Azure 服务集成以进行 CI/CD。
  • Flux 可以用作 GitOps 操作器。 它可以执行与 Argo CD 相同的任务,并且它与 AKS 的工作方式相同。

方案详细信息

在此方案中,应用的自动化生成和部署使用多种技术。 代码是在 VS Code 中开发的,并且存储在 GitHub 存储库中。 GitHub Actions 用于生成应用作为容器,然后将容器映像推送到 Azure 容器注册表。 GitHub Actions 用于更新必要的 Kubernetes 清单部署文件,该文件也存储在 Git 存储库中,而 GitOps 操作器 Argo CD 从那里选取 Kubernetes 清单文件,并将应用部署到 AKS 群集。

其他示例包括提供自动化开发环境、验证新的代码提交,以及将新部署推送到过渡环境或生产环境中。 传统上,企业必须手动生成和编译应用程序和更新,维持一个大型代码库。 借助现代的应用程序开发方法使用 CI 和用于 CD 的 GitOps,可以快速地生成、测试和部署服务。 此现代方法可以更快速地将应用程序和更新发布给客户,更灵活地响应不断变化的业务需求。

有了 AKS、容器注册表、GitHub 和 GitHub Actions 之类的 Azure 和 GitHub 服务,公司就可以使用最新的应用程序开发技术和工具来简化实现高可用性的过程。 此外,通过使用适用于 GitOps 的 Flux 或 Argo CD 等开源技术,公司还可以简化部署并强制实施所需的应用程序状态。

可能的用例

其他相关用例包括:

  • 通过采用微服务式的基于容器的方法来实现应用程序开发实践现代化。
  • 加快应用程序开发和部署生命周期。
  • 自动部署到测试或验收环境以进行验证。
  • 确保应用程序的配置和所需状态。
  • 自动进行群集生命周期管理。

CI/CD 选项

本文档展示了如何对用于在 CI/CD 管道中处理持续部署的新式方法使用 GitOps。 不过,每个组织都是不同的。 通过自动化交付管道将应用程序部署到 Kubernetes 群集时,必须了解可以实现这一目的的各种方法。

将应用程序部署到 AKS 群集的两个最常见的 CI/CD 选项是基于推送的和基于拉取的。 推送选项利用 GitHub Actions 进行持续部署,拉取选项利用 GitOps 进行持续部署。

选项 1:基于推送的体系结构,其中包含用于 CI 和 CD 的 GitHub Actions

在这种方法中,代码从管道的 CI 部分开始,然后将更改作为部署推送到 Kubernetes 群集。 部署基于触发器。 有多种触发器可以启动部署,例如,将内容提交到存储库的提交操作,或者是来自另一个 CI 管道的触发器。 使用此方法,管道系统可以访问 Kubernetes 群集。 基于推送的模块是 CI/CD 工具目前最常用的模型。

使用基于推送的方法的原因:

  • 灵活性:大多数 GitOps 操作器目前仅在 Kubernetes 中运行。 如果组织想要将应用程序部署到 Kubernetes 以外的地方,则需要通过其他 CI/CD 工具(例如使用 GitHub Actions)将应用程序推送到该环境。

  • 效率:部署云原生和传统应用程序的标准化方法更高效。 目前,GitOps 最适用于 Kubernetes 上运行的云原生应用程序。

  • 简单性:基于推送的 CI/CD 在许多组织内最广泛的工程师群体中广为人知。 基于推送的方法可能比基于推送和基于拉取的 CI/CD 方法的组合更简单。

  • 结构:用于应用程序的当前存储库结构可能不太适合 GitOps,这意味着需要重大规划和重构才能适合 GitOps。

选项 2:基于拉取的体系结构,其中包含用于 CI 的 GitHub Actions 和用于 CD 的 GitOps 操作器 Argo CD

此方法以应用 Kubernetes 群集内的任何更改为中心。 Kubernetes 群集包含一个操作器,该操作器扫描 git 存储库以获取群集的所需状态,选取并应用需要进行的任何更改。 在此模型中,没有任何外部客户端具有 Kubernetes 群集的管理员级凭据。 拉取模型不是新模型,但尚未由 CI/CD 工具广泛使用。 最近,随着 GitOps 的引入,拉取模型已得到了采用。 许多组织一直在使用 GitOps 以便于其 CD/CD 管道中的持续部署。

使用基于拉取的方法的原因:

  • 一致性:使用 GitOps 时,操作器会将 Kubernetes 群集的状态与 git 存储库中的配置和应用程序的所需状态进行比较。 如果配置或应用程序存在任何偏差,GitOps 操作器会自动将 Kubernetes 群集恢复到所需状态。

  • 安全性:使用 GitOps 的基于拉取的 CI/CD 方法让你可以将安全凭据转移到 Kubernetes 群集,这样,通过避免将凭据存储在外部 CI 工具中,就会减小安全和风险面。 还可以减少允许的入站连接数,并限制对 Kubernetes 群集的管理员级访问。

  • 版本控制:由于 GitOps 利用 Git 存储库作为事实来源,因此持续部署本质上具有版本控制、回滚和审核功能。

  • 多租户:使用 GitOps 的基于拉取的方法非常适合分布式团队和/或多租户。 借助 GitOps,可以利用单独的 git 存储库、单独的访问权限,并可以跨不同命名空间分配部署。

  • 云原生:更多应用程序正在现代化或构建为云原生应用程序。 对于任何在 Kubernetes 中运行大部分应用程序的组织,使用 GitOps 操作器进行持续部署比使用基于推送的传统 CI/CD 方法更简单、更高效。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改善工作负载质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述

为了监视应用程序性能并报告问题,此方案将利用 Azure Monitor。 可以通过此工具监视和排查性能问题,解决这些问题可能需要代码更新,而这些代码更新可通过 CI/CD 管道进行部署。

作为 AKS 群集的一部分,负载均衡器可以将应用程序流量分布到一个或多个运行应用程序的容器或 Pod。 可以通过这种在 Kubernetes 中运行容器化应用程序的方法,为客户提供高度可用的基础结构。

注意

本文不直接解决 CI/CD 管道高可用性问题。 有关详细信息,请访问 GitHub Actions 的高可用性用于 Kubernetes 的 Argo CD 声明性 GitOps CD

复原组件内置于 Kubernetes 中。 如果出现问题,这些组件会监视和重启容器或 Pod。 将多个 Kubernetes 节点组合使用时,应用程序可以容忍一个 Pod 或节点不可用的情况。

若需可复原解决方案的通用设计指南,请参阅设计可靠的 Azure 应用程序

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅安全性支柱概述

为了将凭据和权限隔离,本方案使用专用的 Microsoft Entra 服务主体。 此服务主体的凭据以安全的凭据对象形式存储在 GitHub 中(作为 GitHub Actions 机密),因此不会在脚本或生成管道中直接公开和可见。

有关如何保护 AKS 群集上的应用程序的一般指导原则,请参阅 AKS 中应用程序和群集的安全性概念

为了分离关注点,所需遵循的指导原则是将运行业务应用程序的计算与 CD 代理或 GitOps 操作器分隔开,具体方法是分别在 Kubernetes 群集上的不同命名空间中运行业务应用程序和 GitOps 操作器。 为了进一步分离关注点,GitOps 操作器可以在专用于 GitOps 实例的 Kubernetes 群集上运行,该群集独立于运行业务应用程序的生产 Kubernetes 群集。

注意

本文不直接解决如何保护 CI/CD 管道的问题。

性能效率

性能效率是指工作负载能够以高效的方式扩展以满足用户对它的需求。 有关详细信息,请参阅性能效率要素概述

AKS 允许按照应用程序的需求调整群集节点的数目。 应用程序增长时,你可以纵向扩展运行你的服务的 Kubernetes 节点数。

有了 GitHub Actions,云提供商会自动缩放运行器数。 如果使用自承载运行器,则运行器主机将负责根据需要缩放它们。

有关其他可伸缩性主题,请参阅性能效率清单

部署此方案

按照 AKS-baseline-automation 参考实现中的步骤部署方案。 该参考实现存储库为基于推送的 CI/CD 方案和基于拉取的 CI/CD (GitOps) 方案提供了引导式演练。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

其他参与者:

若要查看非公开领英个人资料,请登录领英。

后续步骤

本方案使用了 Azure 容器注册表和 AKS 来存储和运行基于容器的应用程序。 Azure 容器应用或 Azure 容器实例也可用于运行基于容器的应用程序,不需预配任何业务流程组件。 有关详细信息,请参阅 Azure 容器实例概述Azure 容器应用概述

产品文档:

Microsoft Learn 模块: