DaoCloud贾恒：一文搞懂发布现代化

嘉宾 | 贾恒   整理 | 李会明

出品 | CSDN云原生

2022年5月24日，在线上举行的云原生系列Meetup·北京站上，DaoCloud道客微服务架构师贾恒分享了发布工具Argo CD、Argo Rollouts，并对云原生发布体系如何在微服务中完成闭环等问题进行了解读。

戳👇观看贾恒分享视频

如何实现全链路发布闭环？DaoCloud贾恒告诉你答案

所谓“发布现代化”可以理解为云原生微服务体系下的发布，发布现代化的探索主要分三个部分来阐述：

• 理论基础：GitOps

• 发布工具：Argo CD & Rollouts

• 闭环：发布体系与微服务、数据隔离的配合

理论基础：GitOps

GitOps是Weaveworks于2017年推出的一种为云原生应用程序实施持续部署的方法。它通过使用Git和持续部署工具，专注于提供在操作基础架构时以开发人员为中心的体验。

GitOps有4 个组成部分：

• Git仓库：用来存储应用程序声明性定义的yaml文件的源代码仓库

• Kubernetes集群：用于部署应用程序的底层集群

• 同步代理（Kubernetes Operator）：将Git仓库和应用状态持续同步到集群中

• CD Pipeline：持续部署的流水线，用来编排整个流程的持续部署

GitOps具备3个特点：

• 更快更频繁的部署

• 简单快速的错误恢复

• 更容易的凭证管理

Operator的使用可以提醒Git与集群中运行的内容之间的差异，如果存在差异，Kubernetes控制器会根据情况自动更新或回滚集群。将Git置于交付管道的中心，开发人员可以使用熟悉的工具发出拉取请求，以加速和简化Kubernetes的应用程序部署和操作任务。

Push & Pull发布模式

上图为传统的Push模式，涉及应用仓库和环境仓库。应用仓库指的是代码仓库，环境仓库则是部署清单仓库。部署清单包括：Kubernetes的demployment、service、helm、kustomize等。

Push模式下的部署流程是这样的：

1. 当应用程序代码有变更时，触发CI流水线（Build Pipeline）

2. CI流水线执行完成后，将镜像推送到镜像仓库（Image Registry）

3. 更改资源配置清单（Environment Repository）

4. 触发CD流水线（Deployment Pipeline），完成环境发布

上图为Pull模式，Pull模式下的部署流程是这样的：

1. 当应用程序代码有变更时，触发CI流水线（Build Pipeline）

2. CI流水线执行完成后，将镜像推送到镜像仓库（Image Registry）

3. 更改资源配置清单（Environment Repository）

4. Operator控制器监控镜像仓库和资源配置清单的变更，完成环境发布

Pull模式下的部署流程的前三步与Push模式基本一致，不同点在于：Pull模式下，更改资源配置清单后，并不是资源配置清单去触发CD流水线的构建，而是由集群中的Operator控制器watch镜像仓库和资源配置清单的变更，发现变更后进行环境发布。

Pull模式解决了传统Push模式的两个问题：

• 密钥管理问题：Operator应始终与要部署的应用程序处于相同的环境或集群中。这可以防止在基于推送的方法中看到特权模式。

• 期望状态与实际状态冲突问题：get配置与基础设施实际运行不符这个问题。

基于这些原因，GitOps选择采用了Pull模式。

GitOps的原则

• 任何能够被描述的内容都必须存储在Git库中：通过使用Git作为存储声明性基础架构和应用程序代码的存储仓库，可以方便地监控集群，以及检查比较实际环境的状态与代码库上的状态是否一致。

• 不应直接使用kubectl命令：一般不提倡在命令行中直接使用kubectl命令操作执行部署基础架构或应用程序到集群中。使用