Docker结合Jenkins的持续构建实践

docker和Jenkins不是什么新东西了，二者结合也不是什么稀奇的事情，也已经有不少Jenkins和docker相结合的文章，此文仅为本身的一点心得实践，若有不对的地方，欢迎你们纠正。

先贴上大体的流程图，逐步说明：

代码-Git：

并无什么好说明的，就是简单的使用了Git做为版本控制工具而已，通用使用规范不在细说。
此步的产出：
Git分支特定版本号

Git-自动构建、自动构建-代码包：

作法也很通用了，将project的Git钩子同Jenkins结合，达到特定分支有push时机触发自动构建，将代码包从Git拉取并打包为代码包。

此步产出：
打包好的代码包：project.tar.gz

代码包-Docker镜像

在此步中，咱们为每一个project提供特定的测试环境，而且在此环境中执行项目代码镜像打包操做。在此步中，须要提早准备几样东西：

1. 测试环境：咱们这里为一台干净的服务器（不要再问好奢侈，有钱就是任性），部署docker环境；

2. project的base镜像：对于一个成熟的项目，所依赖的环境是固定可知的，所以提早准备好其所依赖的base image是必要的。
   如，咱们一个项目的base image的Dockerfile:

FROM centos:liuyanglong
MAINTAINER liuyanglong "liuyanglong@xxxx.com"
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

此步的产出：

1. docker build成功的project image，如以构建号为image版本号，叫作： project_dev:530

2. 此版本代码的测试环境地址，如：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

总结

上述就是咱们在生产环境中的使用Jenkins和docker所构建的持续集成&自动部署的逻辑架构。也欢迎各位大大拍砖指教。