正文
docker和Jenkins不是什么新东西了,两者结合也不是什么稀奇的事情,也已经有很多Jenkins和docker相结合的文章,此文仅为自己的一点心得实践,如有不对的地方,欢迎大家纠正。
先贴上大致的流程图,逐步说明:
代码-Git:
并没有什么好说明的,就是简单的使用了Git作为版本控制工具而已,通用使用规范不在细说。
此步的产出:
Git分支特定版本号
Git-自动构建、自动构建-代码包:
做法也很通用了,将project的Git钩子同Jenkins结合,达到特定分支有push时机触发自动构建,将代码包从Git拉取并打包为代码包。
此步产出:
打包好的代码包:project.tar.gz
代码包-Docker镜像
在此步中,我们为每个project提供特定的测试环境,并且在此环境中执行项目代码镜像打包操作。在此步中,需要提前准备几样东西:
测试环境:我们这里为一台干净的服务器(不要再问好奢侈,有钱就是任性),部署docker环境;
project的base镜像:对于一个成熟的项目,所依赖的环境是固定可知的,因此提前准备好其所依赖的base image是必要的。
如,我们一个项目的base image的Dockerfile:
***************************************************************************
FROM centos:liuyanglong
MAINTAINER liuyanglong "[email protected]"
MAINTAINER version "online"
USER root
ADD php.ini /home/work/local/php/etc/
ADD php-fpm.conf /home/work/local/php/etc/
ONBUILD ADD project-code.tar.gz /home/work/
ONBUILD ENTRYPOINT ["supervisord", "-c", "/etc/supervisord.conf", "-n"]
************************************************************************
注意最下面的两行ONBUILD
而在每一次Jenkins的构建时,要做的仅仅是将代码包传入,并且执行docker
build即可,此时build所使用的Dockerfile的内容只有一行:
From this_project_image:base
而执行build时只会根据base image中的两行ONBUILD执行两个命令:
ADD project-code.tar.gz /home/work/
ENTRYPOINT ["supervisord", "-c", "/etc/supervisord.conf", "-n"]>
注意:此步仅仅在测试服务器做了docker build操作,并没有执行docker pull!!
镜像打包完毕后,此步并没有结束!!
调用脚本,根据此构件号的版本docker
image创建对应的容器,脚本的输出为其对应的访问方式,供QA同学测试使用。
这样,每个构建好的版本都有对应的测试环境,且互不冲突!
鄙人的脚本地址为:https://github.com/Liuyanglong/docker-tools/blob/master/create_docker
此步的产出:
docker build成功的project image,如以构建号为image版本号,叫做:
project_dev:530
此版本代码的测试环境地址,如:172.30.40.2
生成线上镜像
到上一步为止,测试构建环境已经结束,当QA同学确定要上线时,执行Jenkins的Promotion操作,这时触发 此步,将对应build版本对应的docker镜像推送到 私有docker registry。
所执行的操作自然为:
docker tag project_dev:530
docker-registry.xxxxx.com/xxxxxxx/project_name:version
docker push docker-registry.xxxxx.com/xxxxxxx/project_name:version
此步产出:
push好的线上镜像
AB上线
此为最后一步,同样是执行promotion操作后最后所执行的步骤,调用我们的内部接口,对线上应用执行AB上线,具体可参见文章:http://segmentfault.com/a/1190000002978115#articleHeader6