专注开发者体验 | GitOps 实现 Kuberentes 持续部署

大量的企业已经将 Kuberentes 用于其生产环境, 但面对他们正在运行的多套不同阶段的 Kuberentes 集群，仍然困惑于在保证业务团队敏捷性的同时，如何实现持续部署，高安全性、权限分离以及可审计。我们认为 GitOps 是目前比较理想的一种方法来实现基于 Kuberentes 集群的持续部署，且同时满足安全性、权限分离等企业级需求。 在这篇文章中，我们将分享 GitOps 的核心思想和工作流程。后续的系列文章中，我们会一起实践如何在 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 环境里构建 GitOps 风格的 CI/CD 流水线，欢迎持续关注！ # 什么是 GitOps GitOps 是一种为云原生应用程序实施持续部署的方法。它通过使用开发者已经熟悉的工具，包括 Git 和持续部署工具，专注于在操作基础架构时以开发者为中心的体验。 GitOps 的核心思想包括： - 拥有一个 Git 存储库，该存储库始终包含对生产环境中当前所需基础设施的声明性描述，以及一个使生产环境与存储库中描述的状态相匹配的自动化过程； - 期望的状态以强制不变性和版本控制的方式存储，并保留完整的版本历史； - 如果开发者想部署一个新的应用程序或更新一个现有的应用程序，开发者只需要更新存储库，软件代理自动从源中提取所需的状态声明，自动化过程会处理其他所有事情； - 软件代理持续观察实际系统状态并尝试应用所需状态； # 为什么选择 GitOps 同传统的持续部署系统相比，GitOps 有以下特点：  我们为什么认为 GitOps 是实现基于 Kuberentes 集群的持续部署，且同时满足安全性、权限分离等企业级需求的理想方式呢？其中一个原因是GitOps 在实践中可以选择采用推 (push) 或是拉 (pull) 的部署风格。 采用拉 (Pull) 部署风格会有如下好处： - 更加安全。因为 GitOps 代理运行在 Kubernetes 集群中，因此仅需要最小的权限用于部署。简化网络配置不需要该集群同 CD 程序建立网络连接，尤其在管理多集群时尤为简洁。 - 一致性。管理多集群时，确保了每个集群的管理方式都是一样的。 - 隔离性。每个集群的部署不依赖于集中的流水线 CD 程序。 - 可伸缩性。该方式可以容易的扩展到同时管理成百上千的集群。 GitOps 部署方式我们建议首选**拉 (Pull)** 部署风格。因为采用拉 (pull) 的部署风格从安全性、可伸缩性、隔离性、一致性都更优。 选择 GitOps 的另一个原因，是可以通过 Kuberentes 上 GitOps 具体实践来了解细节。 GitOps 方法下，Git 成为系统所需状态的唯一事实来源，支持可重复的自动化部署、集群管理和监控。开发者通过复用企业中已经非常成熟的 Git 工作流程来完成编译、测试、扫描等持续集成步骤。当系统最终状态的声明代码进入 Git 仓库主线分支后，依托 GitOps 工具链来完成验证部署，到观测告警，到操作修复达到系统最终状态的闭环。流程参见下图：  # 基于 Amazon EKS 的 GitOps 最佳实践 本次最佳实践的整体 CI/CD 流水线如下图所示：  代码仓库 CodeCommit 包含三个代码库，第一个为 Flux CD 的配置仓库 flux-repo，用来定义 Flux 相关资源。第二个是保存微服务应用配置和部署文件的 microservices-repo，另一个是业务服务的源码仓库 app-repo，本文中会使用一个前端项目作为案例。CI/CD 流水线中使用 CodePipeline 持续集成，把构建的 docker 镜像存储在 Amazon ECR 中，持续交付引擎 Flux 以 Pod 方式部署在 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 环境中。 **基本的工作流程如下：** - 开发者在开发环境中编写代码，并将最终完成的应用代码推送至 app-repo； - 应用代码库 app-repo 中的代码变更触发 CodePepeline； - CodePepeline 对代码进行编译打包并生成容器镜像，然后将其推送至 Amazon ECR 容器镜像仓库； - 部署在 EKS 环境中的 CD 引擎 Flux 周期性扫描 ECR 容器镜像仓库并从中拉取应用的容器镜像元数据 - 当发现有新版本的容器镜像产生时会自动将新版本的容器镜像地址通过 git commit/push 同步至保存在 microservices-repo 中的应用部署文件； - Flux 周期性拉取 flux-repo 代码库中的应用配置和部署文件，由于 flux-repo 代码库引用了微服务的仓库 microservices-repo，flux 比较集群当前的应用负载运行状态是否和 microservices-repo 中的文件所描述的期望一致，当发现二者有差异时，Flux 会自动将差异同步至 EKS 集群，确保工作负载始终按照期望状态运行。 在后续文章中，我们将分别介绍最佳实践中的四个模块，和开发者一起完成 CI/CD 流水线架构的构建，包括： 1. 通过 IaC 部署云基础架构； 2. 在 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 集群上部署 Flux CD； 3. 利用 Flux CD 部署 GitOps 工作流； 4. 利用 GitOps 工作流实现基于镜像的自动部署； 请持续关注 Build On Cloud 微信公众号，了解更多面向开发者的技术分享和云开发动态！ ### 往期推荐 [Generative AI 新世界](https://mp.weixin.qq.com/s/aIDvCOA98n2SeGWVHzqj1w?trk=cndc-detail) [亚马逊的开源文化](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg5Mzg1NDc2NQ==&action=getalbum&album_id=2779048236732137474&scene=21#wechat_redirect?trk=cndc-detail) [开发者生态](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg5Mzg1NDc2NQ==&action=getalbum&album_id=2779048236715360257&scene=21#wechat_redirect?trk=cndc-detail) ### 文章作者  **郑予彬** 亚马逊云科技资深开发者布道师 20 年 ICT 行业和数字化转型实践积累，专注于亚马逊云科技云原生、云安全技术领域。18 年架构师经验，致力于为金融、教育、制造以及世界 500 强企业用户提供数据中心建设以及软件定义数据中心等解决方案的咨询及技术落地。  **阙铭飞**  亚马逊云科技大中华区解决方案研发中心解决方案架构师 任职亚马逊云科技大中华区解决方案研发中心-解决方案架构师，负责解决方案研发工作。到目前为止有 10 年的工作经验，主要涉及大数据、DevOps、容器化等相关工作。