CI(Continuous Integration)持续集成，CD(Continuous Delivery) 持续交付（当然也有叫 Continuous Deployment）通常会采用一些软件如Jenkins、Drone、Travis、Gocd等来辅助我们。它们能够与Git SVN等代码管理仓库集成，帮助我们实现一些自动化任务。
CI/CD软件很多，再加上代码仓库不同，外加上业务流程的复杂度和不同开发语言的特性，会产生千变万化的组合。可以说CI/CD本身就是一个很大的话题，正所谓一千个人眼中就有一千个哈姆雷特，所以我们这次分享主要还是关注在与Rancher结合方面。
下面我们就以jenkins为例，看Rancher如何与其集成。
首先我们可以想到，对于一个CI/CD环境，Rancher可以提供什么?
快速部署jenkins
环境隔离/用户管理
基于Rancher compose进行应用编排
提供外部访问入口
Rancher的Catalog中提供了jenkins部署的样板：
左侧是jenkins-ci server，右侧是swam-plugin，这两个可以组成一个master/slave模式的集群。
尝试性的部署后，可以看到类似这样的效果：
选用jenkins-swarm-plugin组成slave节点, 这样我们可以在jenkins跑任务时能够和docker进行更好的集成 。
构建完毕后，可以在jenkins中看到集群状况：
那么使用jenkins来做CI是一种怎样的表现模式呢? 我们来通过一张图来看下：
开发人员 push commit后，代码仓库收到提交信息。这时可以通过仓库自带的hook来触发jenkins build。也可以通过jenkins的自poll来获取最新代码。然后jenkins就自动执行你所设定的各种任务脚本。
插播一句，关于触发jenkins build 的几种方式：
Post commit hook (git原生hook)
Webhook (github/gitlab都支持，需要hook的server端接收请求
Jenkins有相应的plugin)
Build periodically / Poll SCM
CI的过程根据业务的复杂程度，各有不同，一般情况下分为这几步：
运行测试用例—编译lib—制作docker镜像并push到仓库—ranchercompose 部署服务。
通常我们可以把 rancher-compose 的file直接写在代码project中，这样jenkins可以直接读取到，并执行rancher-compose执行部署服务。
在执行rancher-compose时，可以考虑下面两种策略：
每次根据jenkins的<buid_num>来创建新的stack
Rancher-compose --force-upgrade --pull 拉取最新镜像并强制升级
在rancher-compose 执行完毕后，通常交付一个对外访问的ip:port，但是这个访问地址一般来说不是固定的，所以我们的业务服务部署完毕后，自动绑定dns，是一个非常好的体验。
sync-service 可以将app-service的服务地址在dns中添加A记录，这样我们只需记住dns，就可以直接看到CD后的业务服务。这里的dns-server 最好是可以支持SRV Record，关于SRV Record，大家可以理解为类似AWS Route53的功能。
关于如何取出服务地址并自动添加DNS记录的原理，可以参考我之前的一篇文章：http://blog.neunn.com/wordpress/?p=276 文中第三部分有详细描述。
Q & A
Q：你刚才提到「在执行rancher-compose时，可以考虑下面两种策略:每次根据jenkins的<buid_num>来创建新的stack」。这种方式可以用DNS么?如果用的话，转发到哪个stack上？
A：默认情况下 <stack.name>.<env.name>.<root_domain>，你也可以特殊制定一个dns前缀<special_name>.<root_domain>
Q：jenkins里只能有一个ENV-*？
A：可以在env下部署多个jenkins，但是考虑企业内部不同部门不同业务要进行隔离，所以建议每个env一套jenkins。
原文来源：Rancher Labs
本文出自 “12452495” 博客，请务必保留此出处http://12462495.blog.51cto.com/12452495/1910967
原文地址：http://12462495.blog.51cto.com/12452495/1910967
