2.4 持续部署工具对比
本节将介绍目前工程实践上常用的持续部署工具,包括本书的主角——由Netflix开源的Spinnaker,以及由Google开源的Tekton、由Intuit开源的Argo CD。
Spinnaker和Tekton目前是持续交付基金会(CDF)的成员,其他成员还包括Jenkins、Jenkins X项目。Argo由CNCF托管,是CNCF目前在CI/CD领域的唯一项目。
2.4.1 Tekton
Tekton是专注于Kubernetes集群的CI/CD工具,它是本节所介绍工具中“最年轻”的项目。Tekton起源于Knative Build组件。
使用Tekton之前,需要在集群内安装它,安装完成后,Tekton会通过Kubernetes CRD(Custom Resources)的方式扩展负载类型,并实现用自定义控制器来完成对CRD的逻辑处理。
Tekton扩展的CRD如下。
• Task:描述任务的模板,用于描述单个任务的执行过程,可以有多个有序的步骤(Step),可包含变量定义。
• TaskRun:用于描述运行Task,实例化Task并支持传递参数。
• Pipeline:TaskRun一次只能运行一个Task,当需要运行多个Task时,就要使用Pipeline对Task进行编排。
• PipelineRun:和Task一样,PipelineRun是用于实例化Pipeline,用于启动Pipeline,并指出传递参数。
• PipelineResource:资源定义,例如Git仓库信息、Docker仓库信息等,这些资源可以在不同的Task之间共享。
Tekton Task和Pipeline的调度关系如图2-3所示。
对于Tekton Task和Pipeline的关系和实现,例如Task A内不同的Step由同一个Pod内不同的Container实现流水线逻辑,每个Step之间是有序的。在Tekton中实现有序,是由每个步骤监听上一个步骤执行完成后,生成用于标识索引的文件(tekton/tools/$index)来控制顺序的。不同的Task之间由不同的Pod负责运行,Task之间的依赖关系和启动顺序由Tekton Controller通过生成有向无环图(DAG)来进行调谐(Reconcile)。
通过编写声明式Manifest文件实现Tekton的自定义资源,并提交至Kubernetes集群,这样便能够启动Tekton流水线。
图2-3 Tekton Task和Pipeline的调度关系
以下是一个最简单的Task例子,将以下内容保存为task.yaml。
定义了Task后,需要再定义TaskRun才能够运行它,将以下内容保存为task_run.yaml。
首先在命令行运行kubectl apply -f task.yaml提交Task,再运行kubectl apply -f task_run.yaml提交TaskRun运行echo-hello-world Task。
使用Pipeline能够对Task进行编排,将以下内容保存为pipeline.yaml。
还要使用PipelineRun来运行Pipeline,将以下内容保存为pipeline_run.yaml。
首先在命令行运行kubectl apply -f pipeline.yaml提交Pipeline,再运行kubectl apply -f pipeline_run.yaml提交PipelineRun运行Pipeline。
PipelineResource可以将公用的信息进行存储和复用,例如定义Git仓库为PipelineResource的代码如下。
提交到Kubernetes集群后,在PipelineRun内便能够利用引用的方式。
由于Tekton不同,Task都在单独的Pod内运行,可以通过kubectl apply get pod -n tekton-pipelines获取运行Task Pod的状态。此外,还可以通过kubectl logs $pod_name -n tekton-pipelines查看对应Pod输出的Log来查看流水线的日志信息。
Tekton通过在Kubernetes集群运行,并监听自定义资源的提交及外部资源的变化来实现CI/CD流水线,对运行在Kubernetes环境下的应用的CI/CD相对友好,同时内置最佳实践案例能够快速创建持续部署流水线。
对于容器化的应用及完全使用Kubernetes作为运行环境的团队来说,Tekton是一个很好的选择,且当组织采用各团队“自己吃自己的狗粮”的管理方式时,Tekton能够为其提供强大的灵活性;对于那些同时使用虚拟机和多个Kubernetes集群的大型团队来说,Tekton无法为他们提供一个中心化的控制和管理中心。
Tekton提供的流水线编排能力相对较弱,在做技术选型时需要额外注意这一点。
2.4.2 Argo CD
在介绍Argo CD之前,首先来了解Argo CD背后的核心理念——GitOps。
GitOps是一种为应用程序实施持续部署的方法。它着重于开发人员的体验,通过使用开发人员已经熟悉的工具(例如Git和CI工具)对基础架构进行操作和变更。
GitOps的核心思想是拥有一个Git仓库,该仓库始终包含生产环境所需的基础架构的声明式描述文件,结合自动化工具,如果要部署或变更当前的应用程序,只需要像提交代码一样更新描述文件即可自动完成变更。
在GitOps的理念中,不同环节的自动化串联可以使用Webhook或Trigger来实现。Webhook一般是通过HTTP请求的方式来触发下一个自动化阶段;Trigger的概念则更加广泛,既可以是由上一阶段主动触发的Webhook及消息通知或GRPC触发的方式,还可以是由下一阶段通过主动拉取检查变化实现触发,其工作流程如图2-4所示。
图2-4 GitOps工作流程
图2-4是一个典型的GitOps工作流程,开发者在更新应用时会首先更新应用代码,持续集成流程在收到触发后启动构建流程,并将构建物推送到镜像仓库。如果本次提交涉及对线上环境的修改,那么还会触发持续部署流程对线上基础架构进行变更,例如更新环境变量或更新镜像等。需要注意的是,触发持续部署的流程可能通过Webhook触发,也可能是持续部署工具通过定期主动拉取的方式检查是否有差异,进而触发流程。
Argo CD遵循GitOps的思想模式,使用Git仓库作为定义应用状态的来源,并可在Git仓库发生变化时自动同步和部署应用程序。Argo CD的实现要依靠Kubernetes控制器,该控制器会监视正在运行的应用,以及比较当前状态和Git仓库的指定清单文件,一旦文件发生修改,就会自动触发流水线。这意味着对Git仓库的任何修改都可以自动应用到对应的环境中。
Argo CD的核心概念如下。
• Application:定义Kubernetes资源清单,这是Argo CD的一个自定义资源定义(CRD),存储在Kubernetes集群中。
• Application source type:使用哪个工具来构建应用。
• Target state:应用的期望状态,由Git仓库存储的文件表示。
• Live state:应用程序实时的状态,例如部署了哪些Pod。
• Sync status:应用的期望状态和实时状态是否同步。
• ync:使应用状态迁移至期望状态的过程,一般是部署行为。
• Refresh:将Git中最新的代码与实时状态进行对比,并找出不同点。
• Health:应用程序的运行状态是否正常运行。
• Tool:从文件目录创建清单的工具,例如Kustomize或Ksonnet。
下面通过简单的示例来详细介绍上述概念。
准备一个Kubernetes集群,并执行以下命令安装Argo CD。
使用kubectl port-forward进行端口转发。
打开浏览器访问localhost:8080,进入Argo CD登录页,如图2-5所示。
图2-5 Argo CD登录页
输入账号admin,密码为完整的argo-server Pod名称(运行kubectl get pods -n argocd | grep argocd-server即可获得)。进入首页后,单击左上角的“NEW APP”创建应用,如图2-6所示。
图2-6 Argo CD创建应用
以部署实例应用guestbook为例,在对应的表单分别选择或填写以下内容。
• Application Name:guestbook。
• Project:default。
• SYNC OPTIONS:USE A SCHEMA TO VALIDATE RESOURCE MANIFESTS。
• Repository URL。[1]
• Revision:HEAD。
• Path:guestbook。
• Cluster URL。[2]
• Namespace:default。
填写完成后,单击上方的“CREATE”完成创建,并展示guestbook应用的状态,如图2-7所示。
图2-7 Argo CD应用状态
注意,完成创建后,Argo CD并不会立刻进行自动部署,而是需要手动进行触发。查看应用状态当前为OutOfSync(未同步),意味着集群已部署的应用和Git仓库存储的应用状态不同步,手动单击“SYNC”即可完成应用部署。
同步完成后,将显示应用具体的状态,例如Healthy、Synced、Sync OK,这意味着当前应用状态和Git仓库存储的期望状态一致,并展示工作负载的类型和拓扑图,如图2-8所示。
图2-8 Argo CD应用拓扑图
完成以上步骤即实现了将Git仓库存储的Kubernetes(Manifest)部署到目标集群中,当Git仓库被修改后,应用状态将重新变更为OutOfSync,重复SYNC同步动作即可同步应用。
当然,Argo CD还提供了Webhook,用于非常方便地实现自动触发,无须人工操作,当Git仓库被修改后,会自动触发同步动作。
Argo CD通过实现GitOps的工作流,进而实现了应用状态的自动监控和自动部署。Argo CD支持多集群,主要针对Kubernetes集群的部署场景,同时弱化了流水线的理念,对较复杂的部署场景的支持较弱(如蓝绿发布和金丝雀发布),也不支持传统虚拟机的部署。