基于Jenkins+Gitlab+Harbor+Rancher架构的CI/CD实现
在讲正文开始前先回顾一下以往传统的代码部署方式。
通常运维人员在接到代码（新项目）上线的任务前都要做大量的准备工作，包括：物理主机、虚拟机、代码运行环境、数据库安装配置、各种帐号创建，、运行后期的系统监控、应用的日志收集，性能优化等一系列的工作。
想一想这个流程不是很复杂但是很繁琐，效率低下，如需要调试还需要给开发人员提供线上系统权限等等，细节没有注意的话，还会造成解决问题的难度等各种问题。
OK，说完以上的问题，那接下来就有相对应的解决方案。
方案大概的架构组成：
jenkins+saltstack+svn+gitlab+harbor+rancher
各个组件的功能描述：
1. jenkins
（1）负责监控SVN代码、gitlab中配置文件的变动
（2）负载执行镜像的构建、上传下载
（3）通过Rancher插件系统构建stack/service
（4）发送构建结果通知
2. svn：
（1）开发提交代码仓库（部门项目一直习惯使用svn管理代码）
3. gitlab：
（1）保存项目配置文件
（2）nginx定制配置文件
（3）Dockerfile文件
说明：
为什么这里会有svn和gitlab两个代码工具呢？我来解释一下，主要是
（1）部门的开发一直以来都在使用svn，还不是特别习惯git方式。
（2）要求代码的线上配置连接数据库帐号开发不能直接修改，且也不知道。不向开发泄漏线上帐号，分开管理，这里我就采用git后面有详细介绍。
4. harbor：
这个是vmware公司开源的docker镜像仓库管理系统，比较方便管理维护镜像
（1）负责构建后镜像的存储
5. rancher：
容器编排管理工具
（1）通过API负责接受jenkins的调用，自动创建、更新stack/service
（2）实现服务的扩容缩容
6. saltstack：
（1）这个组建可有可无，为什么呢？
主要原因是:在rancher中每个服务的后端有时至少是两个以上的容器支持对外访问，分布在多个服务器上运行，同样的容一个镜像要分别pull到宿主机中，这个时间是成倍的（对于容器分布在不同宿主机上来说），saltstack实现了镜像的并发下载，也就是说只是耗费了同样的时间，每个宿主机都同时pull完镜像，节省了部署的时间。
一、架构图
二、架构图说明
项目开发语言是php，使用了比较流行的laravel框架，项目中用到的laravel插件使用composer安装，npm安装全局模块，编译生成js样式文件
① 开发人员提交代码到svn，运维人员更改nginx配置、项目env配置并提交到gitlab
②svn、gitlab钩子会触发jenkins执行下载对应项目的env、nginx配置文件、Dockerfile和最新版本的代码
③jenkins执行shell脚本：composer安装laravel插件和npm安装模块，编译生成js文件。完好的代码通过docker build Dockerfile 指令打包成镜像
④上传构建好的镜像push到harbor镜像仓库
⑤jenkins借助Rancher的插件通过API与rancher交互更新service达到更升级容器的目的（也就是更新代码版本），其中pull镜像的这一步会通过saltstack并行从harbor上下拉之前构建好的镜像到多个主机上
以上流程完整的实现了CI\CD，这里主要是jenkins部分是关键位置之一。
下面通过关键配置的截图来展示一个清晰的思路
三、jenkins详细配置
（1）新建一个使用自由风格的项目，名称根据项目命名。同时勾选要在那个slave节点上进行项目构建，见图1红框部分
图1：
源码管理部分，这里就是架构图中的gitlab保存的项目配置文件，gitlab可以在Rancher的Catalog中进行安装，在gitlab中创建一个项目，创新用户有相对应的权限。Jienkins添加gitlab账户。配置见图2
图2
这一步是关键性的，也就是架构图中流程序号③做的工作，代码、镜像、上传下载都是在那一台slave节点完成的，这个slave节点同时配置成saltstack master服务，Rancher的计算节点配置成minion节点，这主要是为了并行下载镜像
图3
Rancher 插件的配置部分，其中API Endpoint、Rancher API Key、 和Rancher Enviroment Id
需要在Rancher的管理界面上创建API>秘钥>添加账号APIKey增加到jenkins中，使用API为https://xx.xx.xx.xx:8080/v2-beta 见图4 、5 、6
注意：
图5的红框部分高级配置Auto Confirm 勾选后更新服务后，状态是正常的，不能回滚。
如果不勾选，在更新服务后，状态在UI显示的Upgraded，再次发布时会造成失败。
好处就是：如果你没有把握这次发布是一定没问题的，还可以在Rancher管理界面中回滚到之前的状态。
图4
图5
图6
下图是项目发布的Timeline，每次发布时长都在3分钟左右，还要看网络状况、镜像大小和构建容器镜像主机的性能。
图7
总结
1. 目前这套流程，在测试环境跑了三个小项目，线上环境跑了一个小项目。
2. 项目代码（svn）和项目配置文件相关（gitlab）应该整合到一起，很好解决。
3. 所有的问题都是在测试环境中不断发现问题，解决问题，然后在线上进行完善，以防止出现不可控制的风险发生，毕竟这个技术储备对于目前的团队来说还有很大不足。
目前面临的问题有：
1.没有测试环节，无法验证容器镜像构建完成更新容器后，是否能够正常提供服务，这样发到生产环境是危险的。
如果说解决方案，那就是在镜像构建完毕后，启动一个单元测试，来验证结果或者再发布一个预上线环境用自动化的全方位的测试，测试通过出发更新生产环境的发布即更新service，否则通知发布者测试未通过。
2. 整套流程，没有实现如何回滚到上一版本的方法，其实这个也容易，就是在③步的svn代码checkout那步加上带版本号的命令行即可。
本文完
本文转自andylhz 51CTO博客，原文链接：http://blog.51cto.com/andylhz2009/2053741，如需转载请自行联系原作者
