关键词：

编者按：据统计，在上周结束的OpenStack温哥华峰会中，关于CI/CD持续集成和交付的议题超过40个，CI/CD成为了整场峰会最热门的话题之一。而Zuul作为CI/CD模块中耀眼的明星，被大家所熟知，在本次峰会上更是引起了业界高度关注。在这里小编将简单介绍下Zuul，包括Zuul 的CI简单流程图、组件及架构等。

什么是Zuul

随着OpenStack持续集成的推广，基于OpenStack开源项目的性质，项目大，全球各地的开发人员多，变更提交频繁。Jenkins不能解决并发多、单依赖的问题，拉长了问题反馈时间。为解决该问题，源于OpenStack开源社区的基于ZUUL框架的 CI方案出现在我们的视线中。

CI简单流程图

Zuul组件及工作流程

为了更好的理解什么是Zuul和Zuul到底是怎么工作的，需要介绍一下Zuul有哪些组件。

Zuul整体架构

Zuul-server

Zuul-server是Zuul的主要的服务，zuul-server是作为zuul的scheduler，zuul-server从gerrit接收消息，一旦消息被接收到，zuul-server就建立工作流程，并把处理结果返回给gerrit Zuul-server跟gerrit组件交流是通过执行“gerrit stream-events”，然后等待gerrit返回的信息，另外，zuul-server也与Gearman进行通讯。

Gearman

Jenkins的设计初衷并不用于并行执行，它设计中某些点使用到了全局锁，因此在Jenkins的slave节点增加到一定数量后（大约100台），Jenkins的master节点就会出现问题而成为瓶颈。同时master节点是单点部署，无法完成HA等处理。为了扩展Jenkins而引入了Gearman。

简单来说，Gearman是一个用来扩展Jenkins的一种协议，而且Gearman一开始并不是专门为Zuul开发的，但是Gearman很好的符合了Zuul的需求，因此OpenStack采用Gearman来扩展Zuul对Jenkins的调度。 在配置的时候可以选择单独创建Gearman-server或者是使用Zuul来部署Gearman，具体在/etc/zuul/zuul.conf里面进行配置：
1 [gearman_server]
2 listen_address = 127.0.0.1
3 log_config = /etc/zuul/gearman-logging.conf
4 start = true
5

把start改成true，zuul服务就会启动并管理Gearman进程。

Zuul-merger

这里不要被这个组件的名字所误导了，这个组件并不是当代码全部通过测试后用来merge到主干的。当开发者提交一个change后，zuul-merger把这个change merge到一个本地forked repository中 ，这样就可以进行下一步的测试了。

可以把zuul-merger单独部署在一台服务器上也可以进行高可用部署，即部署在多台服务器上组成zuul-merger的集群。

在zuul的配置文件 /etc/zuul/zuul.conf下可以对zuul-merger进行配置，在 [merger] section下面：
1 [merger]
2 git_dir = /var/lib/zuul/git
3 log_config = /etc/zuul/merger-logging.conf
4 pidfile = /var/run/zuul-merger/zuul-merger.pid
5 zuul_url = 127.0.0.1
6

git_dir是zuul对Git repository的一个copy
Log_config是配置zuul-merger的log目录
zuul_url是zuul server的url，这个url可能有多个（zuul集群的情况下）
Zuul-cloner
Zuul-cloner不像其他组件，它没有Damon，只有一个client，用来创建job的workspace
Zuul Workflow
下图解释了当一个patch提交给gerrit的时候zuul的workflow是怎么样的：

Gerrit

用户的patch是提交给Gerrit的，也可以是一个新的commit，一旦这个patch被提交上来，Gerrit就会publish一个event，通知其他服务来处理这个event，如Zuul、Jenkins等。

Zuul Server

Zuul-server根据zuul.conf的配置来启动相应的关联进程，Zuul server会先起一个进程叫GerritWatcher，用来listen从Gerrit那边传过来的event（步骤3），在注册好所有的连接后，zuul-server会起一个Gearman，zuul-server同时会启动Gearman和Scheduler。

当一个Gerrit的event被publish后，GerritWatcher就会通知scheduler，scheduler先会去检查这个event是否合法（根据layout.yaml里面定义的规则），如果通过，便会触发一个trigger event（步骤4）。

Scheduler接着处理这个event，并把这个event添加到一个相关的pipeline里面（步骤5，也是根据layout.yaml里面定义的规则），接下去就是pipeline来处理这个event了，scheduler也会去检查这个event是否依赖于其他的event。

Zuul Merger

当scheduler触发完成trigger event后，把整个代码克隆下来，并把更改的代码并入主干的工作是由zuul-merger来完成的。在步骤6中，merger会从gearman那边获得一个“merge job”的信息，里面包括项目的名称，分支信息，change number和ref等信息。第一步merger需要确认这个commit是不是重复的，如果是，那么就返回已经发生的commit，如果不是，那么继续下一步工作。

HEAD ref重置完成后，如果ref指向了一个不可用的分支，那么zuul就会自动选择第一个可用的分支，然后merger会通过“git fetch”来update repo，再checkout。

接下来merger尝试merge更改到repo上，如果merge成功，那么就会在zuul-server中创建一个新的reference到repo中，最后，merger会返回一个动作完成的信息。
Gearman & Jenknis
现在repo已经准备完成，在上面merger的工作完成之后，现在需要测试这个代码的更改。这步操作其实是scheduler来做的，但是需要配合Gearman来执行。Scheduler发送给Gearman，scheduler也会发送一些变量给Gearman，一般是 ‘ZUUL_’ 开头的。

Gearman接着把数据发送给Jenkins，Jenkins可能是一个集群，Jenkins在测试完成后会把结果返回给zuul，zuul再去通知gerrit是否去merge这个更改。

是否必须使用Jenkins

OpenStack社区考虑过不再使用Jenkins，只使用Zuul来代替，但是如果你的CI系统跟Jenkins强绑定的话，系统中使用了很多Jenkins的plugin，那么再去转换到non-Jenkins的环境中会有比较大的困难。当然可以慢慢利用Zuul来替换Jenkins，但是如果一定要使用Jenkins的话，那么就需要“Jenkins Gearman”这个plugin来提供支持。

Pipelines

Pipelines是Zuul重要的组成部分，每一个gerrit的change都会由一个或者多个Pipelines来进行处理。

Upsteam

非Openstack核心团队的人员可以在评审代码后作出+1（好）、0（无评价）、-1（不建议合并）的评价。核心团队的成员可以给出非核心成员可给出的所有评价，此外还可以给出+2（好，approved）、-2评价（不要提交）。

标签属性中另外一列为“Verified”。只有Gerrit的非交互用户（non-interactive users）如Jenkins，才能在此属性上添加Verified标签。Verified一列可设置的值为+1（check pipeline测试通过）、-1（check pipeline测试未通过）、+2（gate pipeline测试通过）、-2（gate pipeline测试未通过）。此外，第三方搭建的外部测试平台也属于非交互用户，但是只能设置+1、-1。

Pipeline也有很多种：

periodic – 周期性工作的pipeline，比如用于非工作时间做常规的测试
expermental – 如果你有一个新项目，但是不知道它是怎么工作的，那么可以用于这个expermental pipeline
pre-release – 触发的job是归于一个新的pre-release tags
release – 触发的job是归于一个release tags

定制化Pipelines

可以通过配置Zuul来定制化pipelines，可以通过更改zuul layout配置文件，下面是一个配置例子：
1 - name: test
2 manager: IndependentPipelineManager
3 source: gerrit_internal
4 trigger:
5 my_gerrit:
6 - event: patchset-created
7 success:
8 my_gerrit:
9 verified: 1
10 failure:
11 my_gerrit
12 verified: -1
13

可以自定义一个pipeline，取名为test，如果pipeline运行成功，那么返回给gerrit +1，如果失败，那么返回给gerrit -1。上面的配置文件中还有
1 manager: IndependentPipelineManager
2

这个是用来决定pipeline具体是如何工作的。

IndependentPipelineManager

IndependentPipelineManager是当pipeline在处理信息是不需要关心信息处理的顺序的时候使用，在一些patch提交时，在其他test正在运行的时候，也不会对这个patch提交产生影响，当前提交的patch相对独立，就可以使用IndependentPipelineManager。

DependentPipelineManager

DependentPipelineManager则是当pipeline在处理信息是不需要关心信息处理的顺序的时候使用，如果当你同时提交了多个patch，当一个patch test failed的时候，那么同时提交的相关联的patch都需要再次test一次。

Zuul同时还可以很好的处理具有复杂依赖关系的多个patch。它能监控正在执行的任务，并可提前结束掉因依赖的patch测试失败而必定失败的测试任务。

参考文献：
http://stackeye.com/2014/06/openstack-ci/
https://docs.openstack.org/infra/manual/zuulv3.html

关于九州云99Cloud
九州云（99Cloud.Inc）成立于2012年，是中国第一家从事OpenStack和相关开源服务的专业公司。公司成立六年，秉承“开源 · 赋能变革”的理念，已经从单一的OpenStack产品提供商，发展成为涵盖云核心、云运营、云运维和云安全等多个领域的开源软件和服务提供商。九州云已支持了国家电网、×××、中国银联、中国移动、中国电信、中国联通、中国资源卫星、中航信（航旅纵横）、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等重量级客户。在2018年最新的Queen发行版排名中，九州云在核心模块贡献跃居全球第四，中国第二，其中在容器部署Kolla项目、NFV编排Tacker项目等重量级项目上贡献全球第一。

ci/cd技术专题「jenkins实战系列」重塑jenkins服务进行自动合并的方案实现（纠正错误）

前言介绍本篇文章主要针对于之前的Jenkins在构建分支的时候，进行自动合并其他分支的纠正和专题介绍，如果想要了解更多的说明，可以参考一下官方文档：Jenkins的Git合并官方介绍（英文版）、【Jenkins官... 查看详情

ci/cd技术专题「jenkins实战系列」jenkins实现自动化部署+自动化合并其他分支(代码片段)

...的安装以及部署到Linux环境的案例和基本配置，【CI/CD技术专题】「Jenkins实战系列」（1）全流程介绍Jenkins环境搭建+基础部署配置（Windows->Linux），接下来，会针对于相关的J 查看详情

ci/cd技术专题「jenkins实战系列」全流程介绍jenkins环境搭建+基础部署配置（windows-＞linux）(代码片段)

背景在实际开发中，我们经常要一边开发一边测试，当然这里说的测试并不是程序员对自己代码的单元测试，而是同组程序员将代码提交后，由测试人员测试；前后端分离后，经常会修改接口，然后重... 查看详情

docker最全教程——从理论到实战（十四）

...。  为了降低容器的使用门槛以及便于大家将容器技术应用于开发和实践，当前教程大部分线上实践结合TKE（腾讯云容器服务）来进行讲解和实践。当本系列内容讲解完成后，笔者将再单独讲解Kubernetes（k8s）。最后，长... 查看详情

gitlab的ci/cd配置管理(代码片段)

...置管理（二）标签（空格分隔）：运维系列一：gitlabCI/CD介绍二：配置gitlab的CI/CD的runner三：代码的MAVEN打包环境四：配置gitlab的CI文件五：发布项目一：gitlabCI/CD介绍1.1gitlabCI/CD概述Gitlab是常用的开源git代码管理工具之一，随着发... 查看详情

分享一个ci/cd的自动部署想法(代码片段)

-sql1-sql2-sql1-sql2-XXXProject-2564-XXXProject-2564相信你从文件格式中也能明白每一个属性的意义吧？/02识别配置和DB变更文件的新增/聪明的你可能已经根据前面的《文件名的定义》部分内容猜到了，就是通过JiraID来识别。具体操作方式... 查看详情

基于kubernetes实现ci/cd配置(代码片段)

基于Kubernetes实现CI/CD配置一、基本介绍二、基于Kubernetes实现CI/CD配置1.配置GitLab2.配置Jenkins3.实现CI/CD配置4.验证一、基本介绍基于Kubernetes实现CI/CD配置，其实和往常那些CI/CD配置并没有太大区别。都是通过提交代码，拉取... 查看详情

gitlabci/cd简单介绍(代码片段)

...了解CI/CD，编写特定PipelineJob。本文将做一些CI/CD基本介绍，看完后能够在.gitlab-ci.yml中配置需要的Job就行，所以这篇文章适合 查看详情

容器云原生devops学习笔记——第三期：从零搭建ci/cd系统标准化交付流程(代码片段)

暑期实习期间，所在的技术中台—效能研发团队规划设计并结合公司开源协同实现符合DevOps理念的研发工具平台，实现研发过程自动化、标准化；实习期间对DevOps的理解一直懵懵懂懂，最近观看了阿里专家带你玩... 查看详情

基于gitlab的ci/cd系统重点记要

参考技术AGitlab是套功能完善的源码管理系统，平时用于公司内部各研发组的源码同步、问题跟踪、开发协同。Gitlab自带的CI/CD功能与Gitlab更简单、灵活的协同工作，也减小了日常维护的压力，因此，本文针对Gitlab的CI/CD功能做的... 查看详情

jenkins-pipeline配置简介

参考技术A本文重点整理pipeline整体流程和配置中的几点细节，弱化了配置流程，如果想看完整的配置流程请点击Jenkins和gitlab（webhooks）的CI/CD前置工作。在你想要做CI/CD的工程中增加jenkinsfile并编写相应脚本。在jenkins中创建Pipeline... 查看详情

docker最全教程之使用teamcity来完成内部cicd流程（十六）

...。  为了降低容器的使用门槛以及便于大家将容器技术应用于开发和实践，当前教程大部分线上实践结合TKE（腾讯云容器服务）来进行讲解和实践。当本系列内容讲解完成后，笔者将再单独讲解Kubernetes（k8s）。最后，长... 查看详情

什么是ci/cd

...），再到今天的DevOps，这是现代开发人员构建出色产品的技术路线。随着DevOps的兴起 查看详情

gitlabci/cd简单介绍(代码片段)

...了解CI/CD，编写特定PipelineJob。本文将做一些CI/CD基本介绍，看完后能够在.gitlab-ci.yml中配置需要的Job就行，所以这篇文章适合未接触过，或者刚想入手GitlabCI/CD的人。本文不算原创，内容来源自于官网GitLabCI/CD... 查看详情

基于kubernetes实现ci/cd配置(代码片段)

基于Kubernetes实现CI/CD配置一、基本介绍二、基于Kubernetes实现CI/CD配置1.配置GitLab2.配置Jenkins3.实现CI/CD配置4.验证一、基本介绍基于Kubernetes实现CI/CD配置，其实和往常那些CI/CD配置并没有太大区别。都是通过提交代码，拉取... 查看详情

唱吧devops的落地，微服务ci/cd的范本技术解读

原文地址：http://www.infoq.com/cn/articles/devops-landing-in-changba?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text作者钮博彦刘宇桐发布于2017年3月28日.1、业务架构：从单体式到微服 查看详情

ci与cd之docker上安装jenkins(代码片段)

一.CI，CD，Jenkins的介绍CI：持续集成(Continuousintegration，简称CI)，在传统的软件开发环境中，有集成，但是没有持续集成这种说法，长时间的分支与主干脱离，导致分支与主干可能存在较大偏差，在集成代码的时候可能需要花费数... 查看详情

ihealth基于docker的devopsci/cd实践

本文由1月31日晚iHealth运维技术负责人郭拓在Rancher官方技术交流群内所做分享的内容整理而成，分享了iHealth从最初的服务器端直接部署，到现在实现全自动CI/CD的实践经验。作者简介郭拓，北京爱和健康科技有限公司（iHealth)。... 查看详情