如何使用docker+docker jenkins maven实现自动化集成

来源：蜘蛛抓取(WebSpider) 时间：2017-05-02 06:16 标签： docker jenkins 安装
docker和Jenkins不是什么新东西了，两者结合也不是什么稀奇的事情，也已经有很多Jenkins和docker相结合的文章，此文仅为自己的一点心得实践，如有不对的地方，欢迎大家纠正。
先贴上大致的流程图，逐步说明：
并没有什么好说明的，就是简单的使用了Git作为版本控制工具而已，通用使用规范不在细说。此步的产出：Git分支特定版本号
做法也很通用了，将project的Git钩子同Jenkins结合，达到特定分支有push时机触发自动构建，将代码包从Git拉取并打包为代码包。
此步产出：打包好的代码包：project.tar.gz
在此步中，我们为每个project提供特定的测试环境，并且在此环境中执行项目代码镜像打包操作。在此步中，需要提前准备几样东西：
测试环境：我们这里为一台干净的服务器（不要再问好奢侈，有钱就是任性），部署docker环境；
project的base镜像：对于一个成熟的项目，所依赖的环境是固定可知的，因此提前准备好其所依赖的base image是必要的。如，我们一个项目的base image的Dockerfile:
FROM centos:liuyanglong
MAINTAINER liuyanglong ""
MAINTAINER version "online"
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同学测试使用。这样，每个构建好的版本都有对应的测试环境，且互不冲突！鄙人的脚本地址为：
此步的产出：
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-/xxxxxxx/project_name:version
docker push docker-/xxxxxxx/project_name:version
此步产出：push好的线上镜像
此为最后一步，同样是执行promotion操作后最后所执行的步骤，调用内部接口，对线上应用执行AB上线
上述就是在生产环境中的使用Jenkins和docker所构建的持续集成&自动部署的逻辑架构。
阅读(...) 评论()你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
本文将重点讨论在Jenkins管理的持续集成以及测试的环境中，我们如何通过引入Docker来优化资源的配置，提高整个环境的性能以及稳定性。
关于JenkinsJenkins是被广泛应用的持续集成、自动化测试、持续部署的框架，甚至有些项目组顺便将其用来做流程管理的工具。根据任务的多寡，Jenkins通常有两种典型的部署方式。
单节点（Master）部署
这种部署适用于大多数项目，其构建任务较轻，数量较少，单个节点就足以满足日常开发所需。多节点（Master-Slave）部署
通常规模较大，代码提交频繁（意味着构建频繁），自动化测试压力较大的项目都会采取这种部署结构。在这种部署结构下，Master通常只充当管理者的角色，负责任务的调度，slave节点的管理，任务状态的收集等工作，而具体的构建任务则会分配给slave节点。一个Master节点理论上可以管理的slave节点数是没有上限的，但通常随着数量的增加，其性能以及稳定性就会有不同程度的下降，具体的影响则因Master硬件性能的高低而不同。
关于DockerDocker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。Docker 可以让你像使用集装箱一样快速的组合成应用，并且可以像运输标准集装箱一样，尽可能的屏蔽代码层面的差异。Docker 会尽可能的缩短从代码测试到产品部署的时间。简单来说Docker提供了一种技术，可以让开发人员方便地将应用代码已经运行时的环境一并打包到一个镜像中，然后将这个镜像上传至镜像仓库。在测试或者产品环境只需要下载这个镜像然后将其启动就完成了部署（就好比打开一个集装箱那么简单）。关于Docker更详细的内容请参考。
当前Jenkins遇到的困难随着敏捷开发的普及，自动化测试成为每个项目的必须。一个经过多年开发的项目，其累积的自动化测试数量是惊人的。为了保证每次的部署都是正确的，就需要每次回归所有的自动化测试用例。根据项目的不同，有些需要每周跑一轮回归测试，而有些项目则需要每天一轮。所以我们会把所有的测试用例进行分组，同时在多台测试机上运行，以减少一轮测试所需要的时间。而这就要求我们有足够多的硬件资源来满足这需求。下图展示了一个典型的通过Jenkins来管理自动化测试的拓补结构。一台Master主机管理多台测试机，Master将测试任务分配给测试机。
当前Jenkins（Master-Slave）结构
这种结构存在一些缺陷：
自动化的测试通常都是通过捕捉屏幕控件来模拟用户的行为以达到测试的目的，这就意味着一台测试机上只能同时运行一组测试用例，否则用例之间就会相互干扰。这就存在资源浪费，因为测试机的配置往往可以支持多组测试用例。维护人员得确保测试机都保持在线，当测试机器数量较多的时候，比如100台甚至1000台的时候，这维护的压力就比较大。通常回归测试是在晚上运行（如此就能在开发组第二天上班时发现前一天提交的代码是否正确），但这上百台测试机不论白天晚上都在工作状态，这是另一维度的浪费。很重要的一点，测试机器会因为各种原因导致测试环境被污染，导致测试不能顺利进行，而此时除了维护人员手工处理外，没有特别好的方案。之前我们提到过，当slave数量达到一定程度的时候，作为Master的节点就会出现性能变差，稳定性下降。每个Slave节点在开始跑测试之前都需要从中央库下载最新的分发包，解压，设定运行环境。这个过程通常也占用不少时间，想象一下，突然间上百个slave开始下载最新的库，这对中央库是一个极大的冲击。
如何引入Docker来解决这些问题很自然的一个想法就是将测试机全部替换成Docker容器（Container），而管理这些容器的工作交给更专业的工具，如Google的Kubernetes或者Docker官方提供的Swarm。所有构建的环境都打包进Docker的镜像文件中，自动化测试是一个镜像，编译单元测试是一个镜像等等。改进后的拓扑结构如下图所示：
引入Docker以后的结构
在这个方案中唯一的技术问题是自动化测试需要桌面系统，而通常Docker容器中运行的都是无图形界面的应用。解决的方法也非常直接，我们在容器中提供桌面系统（VNC服务）。根据不同的Linux发行版本，我们可以选择TightVNC或者TigerVNC。不论选择哪种VNC?服务，他们都提供一个虚拟桌面，可以通过VNC?的客户端远程连接到该桌面进行操作。
对应前文提到的6个不足，在这种结构下悉数得到了解决。
每个测试机可以同时运行多组自动化测试用例，也就是说跑原来相同数量的回归测试，这种方案下可以至少节省一半的测试机。通过Kubernetes或者Swarm，我们可以实现对容器的自动化管理，从而减轻维护人员的工作。Docker容器可以根据需要动态增减，又因为构建所需的一切环境都被封装在Docker的镜像中，这些测试机器可以被方便的用于其他任务的构建，而不需要进行额外的配置。只需要下载其他构建任务的镜像，然后将其启动。每次测试启动一个全新的容器，所以环境是完全干净的。当某个容器出现问题的时候，这个容器就会被销毁，同时新起一个容器完成相同的测试工作。在这种结构下Jenkins只需要管理一个slave节点，而Kubernetes和Swarm则可以管理成千上万个容器。在同一个Docker环境中（同一台测试机）只需要下载一次最新的自动化测试的镜像就能起多个容器，而在这种结构下，测试机数量已经大大减少，从而对中央库（私有镜像仓库）的冲击也明显减轻了。
更多的思考一个项目开发了5年，就累积了上万回归测试，需要几十台测试机不间断的运行8、9个小时才能完成；设想下，这个项目还要继续运行5年甚至10年呢？我们的测试机的数量将会是多少，我们的测试反馈周期还是8、9个小时么？根据我们的观察，经过多年的维护，很多功能模块已经是非常完善，基本很少有代码的修改。那么这些功能对应的测试用例是否有必要每次都跑呢？答案我想是否定的，但问题是怎么来判断当前代码的修改是否会影响到这些功能模块呢？按照现在的设计，我想没有人敢百分百的肯定。我们是否有必要对现有代码做些调整，依照微服务的思想，把我们的分发包拆分下，每次只需要发布有更新的模块。如此一来我们递归的自动化测试用例也只需要包含有改动的那些模块。那时候，很可能我们可以在每次代码提交就运行一次回归测试。
原文链接：，作者：朱建波，道富银行技术经理。
我公司的方案
http://www.lxy520.net//docker-jenkins-git-mavenzi-dong-hua-gou-jian-yu-bu-
要回复文章请先或

我要回帖

更多关于 docker jenkins 安装 的文章

 

随机推荐