在Jenkins管理的持续集成境引入Docker来优化资源配置

　　Jenkins是被广泛应用的持续集成、自动化测试、持续部署的框架，甚至有些项目组顺便将其用来做流程管理的工具。根据任务的多寡，Jenkins通常有两种典型的部署方式。

　　单节点（Master）部署

　　这种部署适用于大多数项目，其构建任务较轻，数量较少，单个节点就足以满足日常开发所需。

　　多节点（Master-Slave）部署

　　通常规模较大，代码提交频繁（意味着构建频繁），自动化测试压力较大的项目都会采取这种部署结构。在这种部署结构下，Master通常只充当管理者的角色，负责任务的调度，slave节点的管理，任务状态的收集等工作，而具体的构建任务则会分配给slave节点。一个Master节点理论上可以管理的slave节点数是没有上限的，但通常随着数量的增加，其性能以及稳定性就会有不同程度的下降，具体的影响则因Master硬件性能的高低而不同。

　　关于Docker

　　Docker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。Docker 可以让你像使用集装箱一样快速的组合成应用，并且可以像运输标准集装箱一样，尽可能的屏蔽代码层面的差异。Docker 会尽可能的缩短从代码测试到产品部署的时间。简单来说Docker提供了一种技术，可以让开发人员方便地将应用代码已经运行时的环境一并打包到一个镜像中，然后将这个镜像上传至镜像仓库。在测试或者产品环境只需要下载这个镜像然后将其启动就完成了部署（就好比打开一个集装箱那么简单）。关于Docker更详细的内容请参考官网文档。

　　当前Jenkins遇到的困难

　　随着敏捷开发的普及，自动化测试成为每个项目的必须。一个经过多年开发的项目，其累积的自动化测试数量是惊人的。为了保证每次的部署都是正确的，就需要每次回归所有的自动化测试用例。根据项目的不同，有些需要每周跑一轮回归测试，而有些项目则需要每天一轮。所以我们会把所有的测试用例进行分组，同时在多台测试机上运行，以减少一轮测试所需要的时间。而这就要求我们有足够多的硬件资源来满足这需求。下图展示了一个典型的通过Jenkins来管理自动化测试的拓补结构。一台Master主机管理多台测试机，Master将测试任务分配给测试机。

　　当前Jenkins（Master-Slave）结构当前Jenkins（Master-Slave）结构

　　这种结构存在一些缺陷：

　　自动化的测试通常都是通过捕捉屏幕控件来模拟用户的行为以达到测试的目的，这就意味着一台测试机上只能同时运行一组测试用例，否则用例之间就会相互干扰。这就存在资源浪费，因为测试机的配置往往可以支持多组测试用例。

　　维护人员得确保测试机都保持在线，当测试机器数量较多的时候，比如100台甚至1000台的时候，这维护的压力就比较大。

　　通常回归测试是在晚上运行（如此就能在开发组第二天上班时发现前一天提交的代码是否正确），但这上百台测试机不论白天晚上都在工作状态，这是另一维度的浪费。

　　很重要的一点，测试机器会因为各种原因导致测试环境被污染，导致测试不能顺利进行，而此时除了维护人员手工处理外，没有特别好的方案。

　　之前我们提到过，当slave数量达到一定程度的时候，作为Master的节点就会出现性能变差，稳定性下降。

　　每个Slave节点在开始跑测试之前都需要从中央库下载最新的分发包，解压，设定运行环境。这个过程通常也占用不少时间，想象一下，突然间上百个slave开始下载最新的库，这对中央库是一个极大的冲击。