专注 K8S研究
分类： 系统运维
2018-03-21 19:56:26
【摘要】
本实践介绍了利用Jenkins 和docker技术，如何实现CI/CD的各环节的步骤，包括环境准备，代码提交，编译程序，构建镜像，部署，测试。
一套完整的流程，和今日元宵佳节的圆月甚是应景，希望大家能有所收获。
【关键词】
Docker、镜像、Jenkins、持续集成、自动化部署、CI、CD、ESM
【类别】
软件的小分类：架构相关
研发支持的小分类：软件设计
术语介绍:
ESM: 企业服务管理系统
Rancher: 容器管理和服务编排工具
Compose: 服务编排
一个全新的系统，开发测试所需要处理的事情大概有：申请测试机器、编码实现、部署测试、集成等，而其中申请测试机器和部署测试是两个最耗时且低技术含量的操作。那如何简化整个流程，使开发人员一提交代码后，就能快速将应用部署到一台服务器上,以提高项目的开发效率？
测试环境和正式环境，由于两者环境的不同，比如操作系统、中间件版本、环境变量、安装路径等等,导致泄露到正式环境的bug通常是由于这种原因引起，那如何尽可能保证这两个环境的一致性，以提高项目的质量?
基于docker容器技术的自动化部署就是福音。
不需要申请测试机器，可以在云端自动生成构建机，在构建机里自动生成应用包，再在docker主机上将生成的应用包构建成镜像，然后在云平台中启动容器即可。
整个流程需要用到如下的工具:
git：源代码版本管理工具
DevOps：提供的pipline工具，通过pipline规范整个构建和部署的各个阶段
Jenkins：自动构建任务，通过任务生成对应的镜像文件和war包
制品库：保存对应的制品,如war包，jar等
镜像库：存放镜像的仓库
Esm：企业服务管理系统，包含容器的部署，运行，监控。
主体流程图:
用Jenkins来做节点控制、版本管理、流程设置、触发Job，用Docker容器来搭建编译部署环境。把这一切连接起来的就是流程脚本和Dockerfile。
1. 环境准备
1) 申请如下环境所需的账号和权限
云CI环境
制品库环境
代码评审环境
Devops环境
用来构建war包的镜像库
2) 搭建构建应用镜像的主机环境(各项目组自己提供)
生成应用镜像的docker主机
必须满足如下条件:
redhat-7.2; 安装docker1.9.1以上;安装git;安装 Jenkins slave端(后面会介绍此节)。
搭建用来运行容器的docker主机(各项目组自己提供)
环境要求: redhat 7.2; 安装docker1.9.1以上;
此主机用来挂在 esm环境上。 项目组将此主机的ip地址等信息发给 XXX项目组，以便将此主机添加到esm的环境中。
3) 本实践还涉及到的其它环境
ESM测试环境
ESM 正式环境
应用镜像库环境
Gitlab正式环境
Gitlab测试环境
2. 在docker主机上制作构建基础镜像
编写dockerfile
由于各个项目组的构建的环境都不一样，因此需要由项目组制作一个自己的构建基础镜像。其中，xx项目中构建的基础镜像为xxbuildmodel:v2.0
生成构建镜像
Push镜像到docker镜像库
3. jenkins任务配置
总体分为a”开发环境的任务” 和 b”生产环境环境”的任务。
1) 开发环境将按步骤新建如下的jenkins任务:
个人构建
代码评审
项目构建
项目部署
自动化测试
2) 生产环境将按如下步骤建立jenkins任务:
生成镜像
停止服务
项目部署
如下为以xx为例的基于开发环境的jenkins任务总图：
如下是基于生产环境的jenkins的任务总图：
a. 开发环境
个人构建：
通过代码提交触发（代码提交比较频繁的代码流，可以采用定时触发的方式进行），目的是确定构建的成功性，在jenkins上配置个人构建任务需要注意如下几点：
任务运行机器，由于是云CI，这里需要限制任务只在mesos上执行，mesos是默认的挂载在jenkins的节点，mesos上有对应的docker环境，能够创建镜像、上传镜像和上传制品库。
Git依赖库，代码在git上对应的ssh地址，以及认证
执行构建脚本
代码评审：代码提交后,代码经过评审，评审通过后才能并入主分支。包含如下：
代码提交: 代码通过开发人员提交到git
代码评审:登录gerrit，my->changes,查看产生的评审单,然后进行打分。
项目构建：
整体逻辑与个人构建相似，区别在于项目构建有产出，会输出对应的构建war包。
定时触发或者是代码评审通过后触发，拉取最新主分支的代码，实现主分支上的编译打包，应用包再上传到对应制品库。
任务运行机器：同个人构建
Git库：个人构建对比，构建的流改成master
构建环境：需要申请对应的制品库空间，对应的申请流程可以访问wiki，填写申请信息，提交即可
执行构建脚本：同个人构建执行构建脚本
项目部署：
从制品库中拉取对应的war包，运行dockerfile文件生成对应的镜像包，并且部署到esm系统，具体分为测试环境项目部署 和 正式环境项目部署。
任务运行机器：xx项目自己对应的docker主机,为环境准备 e) 中所对应的主机。
此主机可以在jenkins-->nodes路径,如下界面进行添加(在docker主机上安装jenkins slave端)(补充说明:如以后镜像库使用中开社的镜像库,则此docker主机也可以使用云CI中的主机)
Git库：和源代码的git是区分出来的,这里只配置配置项的git库。
执行shell脚本
自动化测试：
根据项目部署的esm环境，获取系统的url，运行测试脚本，实现自动化测试获取测试结果，大概的部署过程同上面的各个过程，需要注意的是由于现在云测试资源的问题，无法申请到对应资源，当前都是通过挂载节点的形式来运行测试脚本，测试部署在esm上的服务。
b. 生产环境
生产环境比测试环境简单得多，主要是对镜像重新打标签，然后部署到ESM的生产环境。
生成镜像：
主要是生成生产环境的配置文件镜像,对在开发环境生成的应用镜像重新打标签。
停止服务：
停止部署在esm里面容器的服务。
项目部署：
将应用部署到生产环境。
4. 搭建pipline流水线
1) 登录http://dxx.xxx.com.cn/devops/ 创建项目
注意：pipeline创建了项目目前必须通知pipeline项目组重启服务，否则无法触发流水线，后续修复。
2) 设置-功能设置 设置gerrit的代码路径
3) 设置-工作流-环境，设置云CI路径
4）点击新增工作流，设计新的流水线工作
实践中可以分为测试环境的流水线 和 正式环境的流水线。
如下图为测试环境的流水线:
这里分为两个流水线，上面并行的为个人构建，通过代码提交构建，另外是定时部署。
本实践讲述了目前IT应用在自动化构建部署中出现的问题，描述了在基于Jenkins 和 docker容器技术下，如何搭建自动化构建环境的步骤。解决了在搭建过程中出现的若干常见问题，将为各项目组的DevOps自动化提供指导和参考意义。
正式环境的结果:
适用的产品/项目：能容器化运行的应用，如java应用等；
需要的人员投入和培训情况：根据模板能编写简单的dockerfile,compose文件；
推广过程中需要防范的问题：要严格遵守标准规范编写dockerfile和compose文件。
个人经验总结：采用此种集成部署方式，实现DevOps自动化，可以大大提高生产效率和产品质量。
参考资料
[2]
[3]
[4]>
[5]>
[6] http://dev.xxx.com.cn/topic/#/27387
