打通CI/CD任督二脉的关键技术点在哪？
打通CI/CD任督二脉的关键技术点在哪？
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。