让你的jenkins能当奴隶主---说说几种Jenkins build框架

最近又有几个朋友看了俺的文章询问，如何让Jenkins能做到分布式。我解释了很久，发现这也是个很好的topic，就来博客继续念叨念叨。

这个很简单，所以这篇文章也就介绍简单点。

首先说下Jenkins能支持的几种build框架：

1.我构建，我收集的Master only框架。

 Master only 框架主要就靠Jenkins本身运作在Server上（数据库在server上或不在都属于该框架），利用Server本身的硬件资源进行build（编译，做包，测试等）。

它能做到的事情：

a:能够让job运行在Master上。

b:能够让job写数据到database。

c:能够让job更新/计划数据并展示。

2.你构建，我收集的Master-单slave框架。

该框架是用于解决单一server又运行Jenkins又编译，影响Jenkins的正常运作的情况。该框架让Jenkins的Agent常驻在另外一台服务器，让它变成Jenkins的slave，由slave来运行job.Master就用来收集数据，传递数据，展示数据。

3. 你们构建，我收集的Master-多slave框架。

改框架主要解决了单台slave同时编译多branch的软件的时候的效率低下问题。由N个Jenkins Agent常驻于N个服务器，由Master统一调度job运行在不同的Slave上。从而达到不同的branch编译不会相互影响的情况，加速编译、做包速度。而Master 只用于收集数据、展示数据。

4. 你们构建，我们各收集各的多Master-多slave框架。

该框架用于解决由于Jenkins 的负载太重导致的Jenkins性能问题，由多个Jenkins作为不同的Master，指派Job到不同的Slave上build.各个master负责的Job领域、类型不同。比如Master 1是SCM做包的，Master2专门管编译，Master 3用于自动化测试。而Master们还是用于收集数据，展示信息。

这个框架便是下一步的Cloud build的基础。

5.Cloud Build

该框架是一个动态的框架，处于1-4的框架中的一种。所以这里就没有配图了。

当任务不多的时候，可能为1-2.

当任务很多的时候，可能为3.

当任务巨大的时候，可能为4.

因为有了Cloud，服务器资源可以随意调配，那么可以在Cloud上申请几个instance做为Master，同时申请几千个CPU的slave做编译。编译完释放instance的所用资源。而Master还是只做数据收集、展示数据。当这个Master完成任务的时候，该instance也可以释放所用资源。

Cloud build框架用于节约HW的资源，一个Cloud服务的公司可以提供很多其他公司来用它的服务，从而减少了总的HW数量。而几千个cpu的编译速度，不是一般server能比的。

说了这么多，看官您云（晕）了没？