在讲正文开始前先回顾一下以往传统的代码部署方式。

     通常运维人员在接到代码(新项目)上线的任务前都要做大量的准备工作,包括:物理主机、虚拟机、代码运行环境、数据库安装配置、各种帐号创建,、运行后期的系统监控、应用的日志收集,性能优化等一系列的工作。

想一想这个流程不是很复杂但是很繁琐,效率低下,如需要调试还需要给开发人员提供线上系统权限等等,细节没有注意的话,还会造成解决问题的难度等各种问题。

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)保存项目配置文件

2nginx定制配置文件

3Dockerfile文件

  说明:

  为什么这里会有svngitlab两个代码工具呢?我来解释一下,主要是

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完镜像,节省了部署的时间。

一、架构图

sstr.png

二、架构图说明

项目开发语言是php,使用了比较流行的laravel框架,项目中用到的laravel插件使用composer安装,npm安装全局模块,编译生成js样式文件

开发人员提交代码到svn,运维人员更改nginx配置、项目env配置并提交到gitlab

svngitlab钩子会触发jenkins执行下载对应项目的envnginx配置文件、Dockerfile和最新版本的代码

jenkins执行shell脚本:composer安装laravel插件和npm安装模块,编译生成js文件。完好的代码通过docker build Dockerfile 指令打包成镜像

④上传构建好的镜像pushharbor镜像仓库

jenkins借助Rancher的插件通过APIrancher交互更新service达到更升级容器的目的(也就是更新代码版本),其中pull镜像的这一步会通过saltstack并行从harbor上下拉之前构建好的镜像到多个主机上

以上流程完整的实现了CI\CD,这里主要是jenkins部分是关键位置之一。

下面通过关键配置的截图来展示一个清晰的思路

三、jenkins详细配置

1)新建一个使用自由风格的项目,名称根据项目命名。同时勾选要在那个slave节点上进行项目构建,见图1红框部分

1

12.png

源码管理部分,这里就是架构图中的gitlab保存的项目配置文件,gitlab可以在RancherCatalog中进行安装,在gitlab中创建一个项目,创新用户有相对应的权限。Jienkins添加gitlab账户。配置见图2

2

23.png

这一步是关键性的,也就是架构图中流程序号③做的工作,代码、镜像、上传下载都是在那一台slave节点完成的,这个slave节点同时配置成saltstack master服务,Rancher的计算节点配置成minion节点,这主要是为了并行下载镜像

3

34.png

Rancher 插件的配置部分,其中API EndpointRancher API Key Rancher Enviroment Id

需要在Rancher的管理界面上创建API>秘钥>添加账号APIKey增加到jenkins中,使用API 见图4 5 6

注意:

图5的红框部分高级配置Auto Confirm 勾选后更新服务后,状态是正常的,不能回滚。

如果不勾选,在更新服务后,状态在UI显示的Upgraded,再次发布时会造成失败。

好处就是:如果你没有把握这次发布是一定没问题的,还可以在Rancher管理界面中回滚到之前的状态。

4

1513954499488321.png

5

56.png

6

67.png

下图是项目发布的Timeline,每次发布时长都在3分钟左右,还要看网络状况、镜像大小和构建容器镜像主机的性能。

7

78.png 

总结

1. 目前这套流程,在测试环境跑了三个小项目,线上环境跑了一个小项目。

2. 项目代码(svn)和项目配置文件相关(gitlab)应该整合到一起,很好解决。

3. 所有的问题都是在测试环境中不断发现问题,解决问题,然后在线上进行完善,以防止出现不可控制的风险发生,毕竟这个技术储备对于目前的团队来说还有很大不足。

目前面临的问题有:

1.没有测试环节,无法验证容器镜像构建完成更新容器后,是否能够正常提供服务,这样发到生产环境是危险的。

如果说解决方案,那就是在镜像构建完毕后,启动一个单元测试,来验证结果或者再发布一个预上线环境用自动化的全方位的测试,测试通过出发更新生产环境的发布即更新service,否则通知发布者测试未通过。

2. 整套流程,没有实现如何回滚到上一版本的方法,其实这个也容易,就是在③步的svn代码checkout那步加上带版本号的命令行即可。

本文完