CI/CD(工具)界的扛把子
大家都说CI/CD,他们的目的到底是什么?
持续集成的目的,在保证高质量的基础上,就是让产品可以快速迭代。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。
持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。所以说,持续交付,持续交付是将持续集成产生的软件,进行自动化测试。
目前在开源界,持续集成工具有几种,如Buildbot(Python语言开发)、Travis CI、Strider(Node.JS与JavaScript开发)、Go、Integrity(Ruby语言开发)。这五种工具,各有各的特点和长处。(参照:http://cloud.51cto.com/art/201508/487605.htm)
但在持续集成工具界的扛把子,非Jenkins莫属。Jenkins功能强大、适用性广、知名度高。几乎所有的配置,Jenkins都能够通过基于Web的GUI完成。
实现CI/CD的“两条”路径
需要注意的是:本节谈实现CI/CD的两条路径,主要是从基础架构层面去谈的(传统模式和容器模式),并未考虑应用层面。
1.传统模式
在传统基础架构模式下,无论是X86物理服务器,还是X86虚拟化,数据中心承载关键业务的主要还是Linux操作系统。在这种模式下,我们当然可以实现CI/CD甚至Devops。不过路径相对长一点。
在传统基础架构模式下,实现CI/CD,集成工具侧使用Jenkins依然是首选。在此基础上,通过Ansible Tower与Jenkins的集成,可以大大提升代码的部署效率。
在持续集成阶段,Jenkins可以通过调用Ansible Tower将代码部署到dev、test、生产等环境。环境可以在物理机、虚拟机,甚至云上。
那么有人会问,做CI/CD是否可以只用Jenkins或Ansible Tower呢,关于这点,请见下表:
CD/CD使用技术 | 场景描述 |
---|---|
Jenkins | 如果代码要部署的环境非常简单并且单一(如build和deploy都在相同的网络环境内,甚至在相同的物理服务器上),那么可以写一个自定义脚本,进行build成功后的部署。 |
Ansible Tower | 只有部署代码过程,没有build/test过程。 |
Jenkins+Ansible Tower | 包含build/test,并且部署较为复杂。例如代码build成功后需要在多台机器上并行部署,并且机器的环境也不尽相同。Jenkins负责CI过程,Ansible Tower负责部署过程。 |
下面视频是Jenkins与Ansible Tower对接的过程。在视频中:当源码库某一段代码发生变更以后,jenkins触发build,如果build成功,触发ansible tower 部署。代码可以部署到任意环境:物理机、虚拟机甚至公有云上。
2.容器模式
随着容器/Dcoker的兴起,大家很快发现docker在做PaaS和实现Devops方面,有其天然的优势,这点是毋庸置疑的。
红帽基于容器的解决方案是Openshift。Openshift既面向运维,又面向开发。前者体现容器话应用的秒级弹性伸缩。后者则体现在Devops,将产品开发速度提升十倍以上。
在面向开发方面,Openshift一个革命性创新是S2I,source to image。即实现从一个应用的静态源代码到动态应用服务的全过程。当然,在整个S2I的过程中,我们通常也会使用Jenkins做集成测试。
Openshift提供容器化的Jenkins镜像,而Openshift3.5可以与容器化的Jenkins实现统一认证、单点登录(SSO)。
例如,在Openshift平台上,点击容器化的jenkins的访问链接:
然后马上会出现认证提示,即使用openshift认证的用户登录Jenkins。
截止到目前,我们可以看出,无论是在传统物理机、X86虚拟化还是在容器化平台,CI/CD的实现,都离不开Jenkins这样优秀的工具。那么打通CI/CD任督二脉的关键技术点,或者说Jenkins的关键技术点在哪呢?
打通CI/CD任督二脉的关键技术点
笔者认为,在通过Jenkins实现CI/CD的过程中,pipeline的制定是最关键的。没有Pipeline,CI/CD是无从实现的。
Pipeline管道模型,可以定义CI/CD整个流程,并进行各个阶段的监控,我们可以理解成“流水线”。结合Jenkins + Openshift这个场景。我们需要做的事情是,定义一个应用在各个阶段的pipeline,如构建、开发环境部署并测试、测试环境部署并测试、确认测试是否通过、生产环境部署。当然,不同的开发流程、不同的应用,其pipeline也是不同的。
如何配置Pipeline?
下图源自:https://jenkins.io/doc/book/pipeline/
一个完整的pipeline架构图如下图:
我们配置Pipeline,有几种方法,第一种是通过jenkins的图形化界面进行操作。第二种数书写Jenkinsfile ,然后通过文件生成pipeline。
方式1:通过Jenkins UI创建
登录Jenkins后, 点击新建:
然后可以看到有多种构建方式,这里我们选择第一种,并命名为david pipeline
接下来,点击“增加构建步骤”,选中Trigger Openshift Build
接下来,会出现如下界面:
可以看到,需要填写的项目,但我们可以看到,BuildConfig是必填的。因为Jenkins触发BC,才能实现一次build。BC是一个静态配置信息。
一个BC中通常会定义构建使用的源码地址和build成功后,输出的镜像,通过如下命令可以查看:
那么,在上面的表格中,如何查看Cluster API URL呢?查看Master节点的配置文件中,publicURL的描述,也就是下面图片第三行的内容https://master.example.com:8443/console/
在上面表格中,tocket指的是:要操作的project的default serviceaccount的token,查看的方法如下:
在上面表格中,project指的就是Openshift中的项目名称。
上面信息输入完整以后,再次点击“增加构建步骤”,选择Excute shell:
接下涞将会出现一个shell执行框,它的含义是:当jenkins触发build完成以后,将会执行下面的shell,根据shell中定义的逻辑进行测试:
在笔者用的实验环境中,定义了pipeline的各个阶段(只是一个示例,不适用于生产),由于这只是个展示,因此在各个阶段中,并没有定义真正的测试内容,是默认都直接通过的,也就是pipeline完整走完。
在Openshift中,其展示效果如下:
在实际环境中,是一定要定义每个阶段的内容的,例如可以通过curl验证部署的应用是否正常等等。而且通常开发、测试、生产在Openshift部署不同的项目,而jenkins中需要配置不同的项目与之对应。 但需要将三个Jenkins的项目联动起来。
举个例子:把一个david的应用分为三个阶段:dev、sit、pro(生产)。我们需要在openshift创建三个project,名字分别为david-dev、david-sit、david-pro。然后,我们需要在Jenkins上也分别创建三个项目,与Openshift中的项目相对应:david-dev、david-sit、david-pro。
第一个Jenkins的项目的工作是:1.触发对应openshift项目中的bc,进行代码构建,然后对构建结果进行测试(简单的方法如curl)。2. build成功以后,实际上镜像会被push到openshift的集成registery。
第二个Jenkins项目的工作是:1.对dev阶段生成的image打tag,把它打成sit的镜像。2.根据打完tag的镜像,触发dc,部署镜像,并对部署的结果进行测试。
第三个Jenkins项目的工作是:1.对sit阶段生成的image打tag,把它打成后pro的镜像。2.根据打完tag的镜像,触发dc,部署镜像,并对部署的结果进行测试。
那么问题来了,Jenkins中的三个项目,如何联动?别着急,可以在Jenkins进行设置:
对于david-sit,它的触发条件设置:
对于david-pro,它的触发条件设置:
通过这种方法,我们把Jenkins的三个阶段串起来,实际上也就把对应Openshift的三个阶段的项目给串起来了,实现连动。
方式2:通过Openshift Pipeline创建
第二种方式,就是构建一个pipeline方式的应用。pipeline和应用一起部署,部署应用的时候,会有一个容器化的jenkins自动在项目中部署,用于管理一起创建的应用。
目前,在github上已经有一些示例。读第一个README.md文件,可以看到使用方法。
按照Readme文件中的步骤进行操作:
创建一个centos的template:
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/image-streams/image-streams-centos7.json -n openshift
创建一个Jenkins的模板:
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/jenkins-ephemeral-template.json -n openshift
上面两个模板,会在后面创建应用的时候,被调用。
在openshift中创建一个新的项目
然后在新的项目中,根据下载的yaml文件,创建应用。
应用创建成功:
接下来,我们登录Openshift的UI,进行查看,会更直观一些:
过一会,项目中的的容器部署成功。
我们可以到pipeline中查看其配置:
这个pipeline中定义了build和deploy两个阶段。
最后,可以在pipeline中点击start build,触发构建,由于内容与上文类似,这里不再进行赘述。
总结:
本文介绍了实现CI/CD的关键要点。在传统模式下,可以使用Jenkins和Ansible Tower对接,实现CI/CD。在容器环境下,S2I与Jenkins对接,也可以实现CI/CD。