CI/CD 

CI 介绍

CI是指持续集成，它属于开发人员的自动化流程。

CD 介绍

CD指持续交付和持续部署，两者都事关Pipeline后续的自动化，但有时也会单独使用以评估自动化程度。

CI/CD 介绍

CI/CD是一种在应用开发阶段引入自动化实现以较高频度向客户交付应用的方法。

CI/CD 阶段

广为接受的模型，存在三个典型阶段：持续集成、持续交付和持续部署；
CI/CD可以让持续自动化和持续监控贯穿于应用的整个生命周期（从集成到测试、到交付，再到部署）；
这些关联的事务通常被统一称作CI/CD Pipeline，它一般需要由开发和运维团队以敏捷方式协同支持；

CI/CD 术语

通常，CI/CD这一术语既可能仅指持续集成和持续交付构成的关联环节，也可以指持续集成、持续交付和持续部署这三项构成的关联环节；

甚至于，很可能有些人口中所谓的"持续交付"也包含了持续部署流程；

持续交付

通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如GitHub或Image Registry），然后由运维团队将其部署到实时生产环境中；

旨在解决开发和运维团队之间可见性及沟通较差的问题，目标在于确保尽可能地减少部署新代码时所需的工作量；

持续部署

通常是指自动将开发人员的更改从存储库发布到生产环境，以供客户使用；

主要解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题；

以持续交付为前提，完成Pipeline后续阶段的自动化；

CI/CD Pipeline

CI/CD Pipeline 介绍

为了交付新版本的软件而必须执行的一系列步骤；

一套专注于使用DevOps或SRE方法来改进软件交付的实践；

加入了监控和自动化来改进应用开发过程，尤其是在集成和测试阶段，以及交付和部署过程中；

传统的CI/CD系统是为使用虚拟机的Pipeline而设计，但云原生技术却为CI/CD Pipeline的价值实现带来了新的突破。使用Tekton项目，用户可以构建Kubernetes风格的Pipeline，控制微服务的生命周期。

CI/CD Pipeline的要素

构成CI/CD Pipeline的步骤被划分为不同的任务子集（subsets of tasks），称之为Pipeline Stage；

Pipeline中典型的Stage包括：
  Build（构建）：应用编译
  Test（测试）：代码测试
  Release（发布）：将应用交付到存储库
  Deploy（部署）：将代码部署到生产环境
  Validation和Compliance（验证与合规）：镜像安全性扫描（例如Clair）等，具体的步骤取决于实际需求

DevOps 方法

CI/CD Pipeline Workflow with Kubernetes (Push Pipeline)

CI/CD With Kubernetes and Helm (Push Pipeline)

Weave Cloud的DevOps方法 (Pull Pipeline)

Weave Cloud的DevOps方法使用Pull机制，它依赖于两种特殊组件:
  1. Config Updater：用于监视image的变动并更新配置清单；
  2. Deploy Synchronizer：维护应用的当前状态；

工作机制：Pull Pipeline模型的中心是配置中心或配置仓库（config repo）
 1. 开发人员推送代码变更至代码仓库中；
 2. CI Server 自动完成CI Pipeline并生成Docker Image；
 3. Config Updater，注意到Image的变动，并以此更新config repo中的配置清单；
 4. Deploy Synchronizer 在察觉到集群当前状态已过期后，将从配置仓库中pull到变更的配置清单并部署到集群上；

Pipeline 模型的演进

Push Pipeline

传统上的大多数CI/CD工具都使用基于Push的模型，即代码从CI系统开始，可以经由一系列脚本代码自动化完成其执行路径，或手动完成相关的Stage；

CD的步骤中可能会用到凭据，将这些凭据保存于代码中可能会导致潜在的风险；

Pull Pipeline

WeaveNet倡导一种新的基于Image Pull的Pipeline模型，并且将凭据直接保存于集群之上.

CI Pipeline根据开发人员提交的代码变更构建并推送新的Image后，负责监视代码仓库的Deployment Automator负责拉取该Image并更新config repo，而Deployment Synchronizer随后会察觉到集群上的应用状态已然落后于config repo，遂获取config repo中的配置文件并将新的Image更新到集群之上；

Weave GitOps pull pipeline

开放式应用程序模型（OAM）

OAM 介绍

对于一个特定的应用，其声明式配置清单的管理会涉及到诸多方面：
1. Dockerfile：将应用程序打包成Docker Image
2. Kubernetes资源配置文件：Deployments、Services、Volumes和ConfigMaps等；包含敏感信息的Secrets需要独立管理；
3. 环境相关管理策略，例如应用的冗余数量，在预发和生产环境可能会有所不同；
4. 与容灾相关的跨区可用性策略相关的调度机制；
5. 网络安全策略；
6. 路由策略；
7. ...

这些信息分别来自：
1. 开发人员：定义应用程序组件
2. 应用运维：组件实例及配置的声明
3. 基础架构运维：基础设施组件的声明

OAM 框架下的各角色职责

GitOps 介绍

1. 一套使用Git来管理基础架构和应用配置的实践，一项事关部署流程的技术
2. 在运行过程中以Git为声明性基础架构和应用的单一事实来源
3. 使用Git拉取请求来自动管理基础架构的置备和部署
4. Git存储库包含系统的全部状态，因此系统状态的修改痕迹既可查看也可审计
5. 与DevOps相比，GitOps更侧重于基于工具和框架的实践
6. 简单来说：GitOps = IaC + MRs + CI/CD
     MRs：Merge Requests

GitOps 使用场景

1. 存在支持声明式管理的基础架构；
   1. 天然适配Kubernetes和云原生开发的运维模式；
   2. 原生支持基于Kubernetes的持续部署；
2. 用于构建开发流程、对应用进行编码、管理配置、置备Kubernetes 集群以及在 Kubernetes 或容器注册中心进行部署；

GitOps Pipeline

GitOps 模型中存在两个Git仓库

代码仓库（code repo）：开发人员使用。推送代码变更
配置仓库（config repo）：运维人员使用。推送配置变更，包括基础设施配置以及应用配置

简要工作流程

1. 开发人员推送代码变量至代码仓库
2. CI工具链完成测试和构建
3. CD工具链完成测试和交付（新版本的Image推送至工件仓库）
4. Config Update（即Deployment Automator）将Image的变更信息推送至配置仓库
5. 随后，根据使用的分支和发布策略，完成应用的部署

GitOps 的实施要点

GitOps强调的重心在于，它要求对应用程序、环境、部署操作和基础架构进行的所有变更，都应以声明式描述文件存储于Git中；
 1. 基础设施：例如，以Terraform模块或Cloudformation脚本形式存在的声明，此外，aws也支持使用Kops在基础设施上拉起一个集群等；
 2. Kubernetes的资源配置：主要包括Deployments、Services、StatefulSets、PVC和用到的镜像等相关的配置。使用Helm包管理器打包管理一个应用程序相关的配置应该是更好的选择；
 3. 环境配置：这里仍然是指Kubernetes配置，它主要包括Kubernetes上的ConfigMap资源对象。这些配置同样可以打包在Helm Chart之中；
 4. 应用程序代码：存储于git之中，但需要通过声明式的Dockerfile打包为docker image。Dockerfile自身同样也样存储于程序的代码仓库中；

基于Pull Request完成所有需要进行变更；
 1. master（或main）分支用于反映系统的当前状态；
 2. 在master分支上打开新的PR即可完成可能需要的任何更新；
 3. PR合并后，将触发CD/GitOps管道；回滚同样由PR触发；

自愈
 1. Git配置仓库保存有应用的预期状态，而Kubernetes上保存有应用的当前状态；
 2. 需要一个专用的Operator来负责实现该功能；

GitOps 实施

1. 遵循GitOps的标准流程
2. 基于OAM框架模型，DevOps团队协同管理声明式配置清单
3. 选择合理的工具集
4. 从变更频率高或易于中断的应用程序开始

GitOps 工具集

1. Git和Git Server：显然，这是实施GitOps的基础和中心；GitHub、GitLab或任何形式的支持自动化Pipeline必要功能的Git Server均可；
2. CI Server：CI Pipeline的基础设施，如Jenkins和Tekton等；
3. Agent Operator（Deploy Operator）：CD Pipeline的基础组件。GitOps中，可用的解决方案包括ArgoCD、Flux、Jenkins X、WKSctl和Gitkube等；
4. Canary Deployer
   1. flux提供的名为Flagger的Kubernetes Operator支持金丝雀发布、A/B testing、Blue/Green mirroring等部署策略；
   2. 它能够结合Istio、Linkerd、App Mesh、NGINX、Skipper、Contour、Gloo或Traefik等自动实施流量路由和流量迁移，以及根据Prometheus实现Canary分析；

GitOps 示例

FluxCD

With the Helm Operator you can now declaratively manage Helm releases with GitOps. 

flagger

ArgoCD

专用于Kubernetes的声明式GitOps CD工具；

Tekton and ArgoCD

1. Tekton负责构建CI Pipeline
2. ArgoCD负责构建CD Pipeline

参考文档

https://www.weave.works/technologies/gitops/