轻量化 Jenkins 高可用实践

彭小阳

作者简介：

石雪峰，乐视致新（天津）电子科技有限公司工程效率技术总监，多年配置管理，持续交付和研发系统平台建设经验，曾负责全球化工程效率团队管理和建设，追求极致的工程效率水平，深信技术改变世界。DevOps的践行者和推动者，认证DevOps Master和Jenkins专家。

前言：

我今天分享的主题是“轻量化的Jenkins高可用实践”。最近一直在写Pipelines，这个性能实在让我发狂，熬了很长时间。简单做一个自我介绍，我叫石雪峰，我今天只想说我是Jenkins工程师。今天来到这里很高兴跟大家聊聊关于Jenkins的事情。
今天分享主题主要分成三个部分：第一部分，Jenkins跟持续交付；第二部分，Jenkins轻量化思路；第三部分，Jenkins高可用实践。

一、Jenkins跟持续交付

1、持续交付构建企业IT价值流

我相信大家都听说过状态报告，体现了对持续交付的应用。其实简单来说就体现了两点：第一点，对于DevOps帮助我们企业加快交付效率，第二点也让我们的质量变得更好。

也就是所谓的鱼与熊掌兼得。持续交付就是DevOps非常核心的实践，而Pipelines就承载这样工程实践的工具。为什么我们一直在说Pipelines做Jenkins？就是因为我们要做持续交付，做DevOps，帮助企业价值快速的流转。

2、流水线打破敏捷之墙

为什么Pipelines帮助大家打破这样的理念？因为DevOps诞生之前我们都在做敏捷，敏捷很多时候各个团队都在自己的领域里边做自己的改进，但是实际上整个价值流交付是断掉的。

实际上流水线帮助我们最大的一点，它可以帮助整个持续交付的环节，整个链条完整的打通，实现完整的流水线。之前同事交流的时候大家就说Pipelines最显著的特点是什么？就是端到端。端到端可以从我们的需求一直到交付整个流程全部打通，避免以前各自为战的状态。

3、jenkins驱动持续交付

这张图相信大家也见过很多次了，我们Jenkins驱动持续交付。Jenkins这样一个平台并不想替代所有原有的工作，只是提供了一个平台化的能力，帮助大家在各个环节的工具可以接到平台上来，实现端到端的交付。Jenkins就是我们持续交付的枢纽，相当于是整个持续交付链条的中心，所有环节都跟Jenkins交付。这也是为什么现在CI/CD对于企业来说越来越重要。

4 、CI/CD平台对于企业至关重要

Jenkins这么大比例的工具平台的稳定性是我们现在非常关注的一点，如果有朝一日我们CI/CD做得足够好，但是Jenkins平台挂掉了，后果不堪设想。

之前我们公司出现了Jenkins断掉了，导致的结果超过两天的时间修复，这段时间所有IT交付的东西都无法实现价值交付。我相信随着各个企业逐渐的扩大，JenkinsCI/CD平台所起到的作用也会非常重要。所以我们应该花一些心思在平台的可用性上。

二、Jenkins轻量化思路

1、使用jenkins的常见问题

接下来就是我今天所要谈的重点，刚才解释为什么Jenkins或者CI/CD如此之重要，接下来我们要看一下为什么变得这么令人担忧，为什么经常会出现一些问题？Jenkins常见的问题包括哪些，包括性能、可用性、拓展性、安全。

我相信大家脑中对Jenkins的一些问题还有很多，我们回过头来看一看，这些问题根源到底在于什么？在于哪里？

2、我们是如何使用jenkins的

我帮大家理一理，因为我用Jenkins也挺长时间了，最开始我们没用Jenkins，大家都在用类似的自动化工具。有一天有人告诉我有Jenkins研发的管家，可以帮助我们自动化调度很多工作。所以Jenkins最开始引入团队的时候可能更多的相当于自动化工具的平台。我相信很多人还是把Jenkins作为自动化调度平台使用。

随着平台逐渐的为人所知，我们突然发现Jenkins有一个非常强大的特点在于它有很多插件，没用过Jenkins插件的应该是比较奇怪的一件事情。而且Jenkins在今年的大会上也提到，现在业界对Jenkins的插件已经1600个插件了。如此多的插件大大减少我们平常琐碎的工作。在这样的背景下我们开始疯狂的搜插件，想要实现一些功能的时候我们就去查查有没有相应的插件能替我们做这些事情。
因为插件在很多时候并没有完整的满足需求，可能需要两三个插件一起帮助我们实现完整的需求。这就是为什么我们的Jenkins上面插件会越来越多。是因为很多插件是个人爱好者大家维护、开发的，很多时候你也会在Jenkins插件的官网上看要不要维护插件，这也导致随着Jenkins官方版本不断地发展，很多插件已经不再适配了。当我们继续使用这样一些插件的时候显然会产生一些问题。

3、jenkins系统固有问题

接下来随着插件越来越多，我们的功能越来越强大，我们会依赖于Jenkins做更多的事情，这是理所应当的。自然而然我们这个团队也有越来越多的人开始使用Jenkins，我们Jenkins上的用户也变得越来越多，Jenkins管理的节点也会越来越多。这就是我们使用Jenkins日常的路径。

所以我们期望Jenkins无所不能，而且我们持续在问什么，我们希望Jenkins变得更强大，我们希望Jenkins帮我们承担更多的工作，我们希望集成更多的能力。回过头来我们看看另外一方面，我们怎么应用Jenkins，另外我们来看看Jenkins自己。Jenkins包括哪些？
第一，Jenkins是一个单体应用，Jenkins是一个JAVA单体应用，到现在为止依然是一个单体应用。其实Jenkins还有很多改进的空间。
第二，比较大的问题就是Jenkins采用的是本地文件存储。我不知道大家有没有看过Jenkins目录结构，所有的内容都是通过文件保存的。这会带来什么问题呢？一会带来非常大的IO压力，因为会一直读写磁盘上的文件。另外对高可用，对同步备份带来了一些瓶颈和问题。传统上我们使用数据库的时候有非常多成熟的方案帮助我们去做分层或者动态负载均衡，多节点等等。因为Jenkins目前使用的是基于本地文件的存储方式，所以这样一些优势没有办法很容易的用到。
第三，大量碎片文件。因为我们在Jenkins上很多的数据，尤其是我们的日志保存在Jenkins的Master上，即便是分布式的架构，实际上我们调配任务还是会传回我们的Master上，我们所有历史信息是保存在Master上。所以分布式的架构并不能解决这样一个问题，这也是为什么我们Jenkins上有大量的文件，尤其在你不做清理的时候。之前我们Jenkins会挂掉，我们就去看到底为什么Jenkins会挂掉？因为脚本里边写了很多问题，所以说不断地循环，不断地输出日志，就导致Jenkins的Master挂掉了。
第四，Jenkins在启动的时候会很慢。你们有没有想过Jenkins在启动的时候做什么？这个事情我昨天咨询了一下Sam Van Oort，他来告诉我的。简单来说Jenkins在每次启动的时候会做以下几件事：1，会加载Jenkins主要的配置，Jenkins系统配置；2，会加载插件，插件越多，加载的内容越多，导致Jenkins性能越来越慢。与此同时不仅是插件，还有所有的兆铺（音），如果Jenkins无限庞大，是不是性能越来越有问题。这也是为什么Jenkins系统固有的问题，导致Jenkins遇到性能瓶颈，尤其是在大规模企业应用的时候。

4、重新审视jenkins架构

我之前带着一个问题问KK，KK告诉我非常好的消息，Jenkins的架构优化会作为2018年非常重要的里程碑，我们也非常期待Jenkins变成一个架构。总之现在Jenkins社区或者Jenkins创始人他们也越来越多的关注Jenkins性能问题。因为大家也知道Jenkins是我们企业的核心。我们可以期待大家可以咨询一下Sam Van Oort他们打算明年交付什么。现在初步算一算还有不到两个月的时间，但是依然要给我们的社区点赞。其实去改变一个历史悠久的单体应用的话要发挥非常大的力量。
这张图我想表达的是不要让Jenkins陷入一个重围，Jenkins可以作为我们的管家，可以帮助我们做很多事情，但是你不要让它承载更多的功能在里边，这样会导致Jenkins不堪重负。谁也不希望Jenkins摆在这个位置，虽然很酷。我们不希望Jenkins承载更多的东西，这也是为什么我想说的轻量化，初衷在于给Jenkins减负。

接下来我们看一看Jenkins的系统架构。我花了很长时间也没有找到官方的系统架构图，所以没办法自己动手自己画一个。
Jenkins系统架构包括什么？第一Jenkins是一个分布式的系统，在右上角就是我们的Jenkins的Master，Jenkins的Master有Jenkins Core，Jenkins Core提供了很多能力，第二个是队列能力，我之前也花一些时间看一些事情，实际上Jenkins更倾向于之前的Setp。这就是之前的机制和原理，初衷可以帮助我们节省很多缓存。这导致的问题是什么？闲的闲死，忙得忙死。第三块就是Build。
同时Extension提供了一种能力，体现就是插件，我们的插件外部有一个Update Center，所有的插件也是保存在Master上的，这个不是分布式的。
左下角是一个外部系统，跟Jenkins本身并没有直接的关系，但是因为Jenkins插件的存在帮助我们很好的整合。也让外部的系统可以很轻易的做一些集成，这也是上午发布流水线2.0版本非常大的亮点功能，就是做系统集成。

5、jenkins的核心能力

Jenkins的核心能力是什么？我们回过头来去看一看Jenkins的核心能力到底包含哪些？

第一个就是Jenkins Core，Jenkins Core就是Jenkins最核心的东西。
第二点是插件，每件事情有两面性，我们受益于插件，也受困于插件，如何很好的取用插件，这是很好的问题。
第三点是队列资源调度。实际上这是Jenkins提供了一个非常重要的核心能力，提供了一些队列的机制和提供了一些调度的能力，即便调度不是很完美，但依然可以满足我们基本的使用。
第四点就是Jenkins2.0，也就是说我们的Pipelines和“布鲁深”（音）。这是Jenkins未来的发展中里程碑的事件。我们很欣慰Sam Van Oort过来面对面的跟我们交流，经过他的分享我个人也受益匪浅。

6、轻量化解决之道

什么叫做轻量化？少即是多，对于我个人而言，之所以提轻量化主要在于我们希望Sam Van Oort保留一些核心能力，让其他人替Jenkins干活，以前Jenkins是我们的管家，现在我们要帮他干活。

对于整个Jenkins轻量化的解决之道，我个人觉得这八点是比较重要的一些思路，帮助大家去年Jenkins性能问题的时候，帮助大家在做扩展的时候这些思路或多或少可以帮助到大家。

6.1最佳实践一、分布式架构。

这个东西并没有什么好说的，因为Jenkins原生就是支持分布式架构，只不过有的时候我们习惯把很多调度放在Master上。但实际上这样带来的结果是什么？Jenkins又当爹又当妈，这样毫无疑问会给Jenkins Master带来很多不好的影响。
如果没有指令的时候默认调度到Master上，这也不怪大家，是默认的行为，当我们显示指令的时候很显然会调度到Master上。正如刚才Sam Van Oort提到，最好的工作就是把这些脚本调度到其他的机器上，Jenkins Master上只是一些工作，Master在原始的时候只有一个。我们要用分布式架构，不要再Jenkins Master上做很多高性能的动作。

6.2最佳实践二、动态节点挂载。

这个事情并没有什么新鲜事，后来我简单搜了一下，因为我们之前再去管理Jenkins节点的时候是通过长连接的方式，首先Jenkins要去维持这些联系，保证这些联系不是断掉的。
我们为什么要提动态的挂载节点？一方面是动态资源，另外一方面我们不希望Master长期维持很多的东西。测试的同学他们在做测试的时候会有一些特殊的设备，自己的实验室，当这些设备IP地址发生变化的时候Jenkins Master是不知道这件事情的。所有的节点需要动态化，更多的还是关注Jenkins的性能。

6.3最佳实践三，资源调度代理。

这是我上次提到的，上午很多同事，包括硅谷来的嘉宾都在提，通过容器调度平台动态的生成节点。我很欣慰在这点上我们跟世界处在同一条起跑线上，我们是在做同样一件事情，去摸索一个解决之道。
对于资源调度代理来说最重要的事情就是Jenkins不用再去看资源合理不合理，Jenkins并不知道这个任务到底要消耗多少资源，只能硬性的指定。这对原始的Jenkins来说并不知道这件事情，依然会把任务调度到同样的机器上，就导致性能就开始有问题了。
我们在使用容器调度平台的时候天生就支持资源的调度，资源的拓展。实际上就是把烦琐的事情，或者这么复杂的调度算法让其他平台去做。这样的话我们就可以受益于现有非常优秀容器调度平台的机制，一些算法帮助我们把所有资源打平。当我们把所有的机器都牵上之后，我眼中只剩下一些CPU，一些内存或者一些计算资源。这也是我们帮Jenkins减负重要的途径，通过资源调度平台把资源调度完全带入进去。

6.4最佳实践四点，任务按需触发。

最早我们在用Jenkins的时候很多时候还是在做任务，因为语法也是一样的，大家写起来没有任何压力，很多时候我们去执行一些任务，这样的结果是什么？可能一些没有任何改变的任务也在不断地触发，你想减缓这样的问题只能你自己在你的脚本里，在工具里边做一些判断，我这次到底有没有变化，没有变化的话退掉。但是毫无疑问每次会提起来。
接下来我们提到poll SCM的方式，这个方式跟定期调度没有太多区别。但是它天生会帮我们检查代码有没有变更，如果没有变更任务是不会执行的。它是用的“poll”这个单词，这个单词是选举投票的意思，是根据需求。从这一点上来说一开始就误解了意义。
到了现在我相信很多同学已经把代码平台跟SCM平台做了集成。也就是说只有你配置了这样的方式，你过滤了不需要的分支，不需要的提交，只有满足了这个需求之后才会把你的任务触发起来。这就意味着任务起来准确性和有效性，远比之前毫无疑义的无限循环更有教训。在同样的资源下干更多有意义的事情也是一种减负。
其实不仅如此，我们在提持续集成，最显著的一点，每次提交要触发一次完整的流水线，如何去做呢？就是通过Webhook的方式，我们最佳实践里边已经给大家提供了这样的方式，去做Webhook的调度。

6.5 最佳实践五，合理的使用插件。

第一个原则，Jenkins企业版有一个非常重要的功能，就是帮助大家去验证每一个插件，验证所有的插件是完好的，是可以用的，没有任何风险的。这是Jenkins企业版最大的卖点之一。对于我们来说首先可以去参考的一点，Jenkins在起用的时候其实已经给我们一个非常好的提示了，有些推荐插件级。
实际上在官方上有一个地址，里边记录了哪些东西是推荐的。大家想哪些插件需要用，哪些不需要用，第一点我们可以看一看Jenkins企业版在用的东西。这给我们是一个非常大的参考。
第二个原则我个人认为插件这个东西够用就行了，之前大家都有一些强迫症，看到插件有更新了，我们一定要批量更新。但原本非常稳定的插件或者稳定的功能因为插件没有经过完好的测试，导致原本能用的东西一升级就断掉了。其实到那个时候只能恨自己手贱了。如果说一个插件能满足现有的需求，没有明显的瓶颈点，或者Jenkins官方没有提出有一些安全漏洞，我建议大家可以继续使用这样插件，不要频繁的升级，每次升级的时候要关注一下到底改了什么，改的东西跟你有没有关系。
刚才Sam也提到很多时候不一定插件要比原生命令好，实际上插件做的事情无外乎帮我们包了一层，提供友好的用户界面。核心的工作如果用简单的脚本可以完成，为什么加载一个插件，为什么要在Jenkins启动的时候还再做一些负担。
大家有没有做过一个尝试？在运行中的Jenkins直接把插件目录全部干掉，会发生什么？什么也不会发生，因为Jenkins在运行的时候所有插件都在内存里边，即便把目录直接干掉，对他来说没有任何影响，下次重启的时候才会有影响。这也是一个非常大的佐证，这也是为什么我们要合理的使用插件，如果原生的命令可以满足这些功能，我相信大家可以用原生的命令做，也就是所谓少即是多的概念。

6.6最佳实践六，任务动态的生成。

大家可以猜猜这是哪家企业的Jenkins？我觉得Sam应该非常熟悉，因为这是Jenkins官方的Jenkins。我们再看一看Jenkins官方自己是怎么用Jenkins的？就意味着所有官方自己维护的时候已经完全用Pipelines取代了原有的了。
第二个，我们这边用的比较少一些，就是小黑书。大家有多少人用过Multibranch Job？正确的打开方式是Multibranch Job。核心理念是在于所有的任务是动态生成的，Multibranch Job会扫描里边每一支代码分支。你没有必要去创建这个任务，所有东西都是动态生成的。而且当你改变代码库，新建一个分支，减少一个分支，这个东西会定期的帮你们分布。所以你不用担心一个代码库里有分支，Multibranch Job可以实现这些功能。
而且Sam是一个非常强大的黑科技，不仅一个代码库可以支持多个，实际上多个Multibranch Job可以有多个代码库。我也不知道到底干掉，我很纠结这个事情，我去问这个东西要不要了，不要干掉了，他给我的回答是可能。如果我们都用Multibranch Job的方式就不存在这种情况了。

6.7最佳实践骐，Master水平扩展。

上午KK给大家提供的一个案例，我没记错是2500个Jenkins Master。很多业界最佳实践他们推荐多个Jenkins Master，而不是用一个Jenkins Master。为什么有这样一些结果，核心的理念是什么？实际上在最佳实践里边不一定把所有的经历花在一个地方，可以建很多的Jenkins Master，这就是Jenkins Master的水平扩展。当我们把一个拓展到多个的时候，性能对于单体来说就没有这么的尖锐。这一点多个Jenkins Master可能也是我们未来的发展趋势。

6.8最佳实践八， Devops元素周期表。

28号元素是Jenkins，为什么要这么说？我们的Jenkins替我们做了很多工作，但实际上没有办法覆盖元素周期表里边所有的事情。我个人理解Jenkins更多的还是要把各种各样的工具，各种各样的东西插接上来，而不是用Jenkins替代所有的工具，让Jenkins做所有的事情。我们可能要关注一下如何把这些系统做一个集成，这也是我们未来比较大的挑战。

三，Jenkins高可用实践。

这也是比较吸引眼球的事情。

1、企业级jenkins产品化服务化思路

在这里边一开始想说的是Jenkins企业级产品化思路，为什么一开始没有提Jenkins高可用？是因为我觉得这个事情对大家来说更重要，企业级的Jenkins需要的是什么？我们怎么样去设定一个企业级的Jenkins。

我们认为Jenkins的产品化、服务化是我们一个指导方向，为什么要做产品化和服务化？当Master变得足够多的时候，越来越多的团队在一起使用Jenkins，有2500个Jenkins的Master，如何保证统一的环境和统一的服务。这是一个非常挠头的事情。
所以说做Jenkins产品化，尤其在大型企业里边做Jenkins产品化、服务化，第一点要统一这样的环境，统一服务。这里边就包含定期版本的升级，经过验证的产品，有人告诉你这些东西不能用。包括我们集成很多企业级的功能，新建一个Jenkins Master，是不是集成权限的功能。我们就把它潜到企业级的Jenkins Master里边去，可以直接实用功能。
随着我们的Jenkins Master数量越来越多，对于后台统一的数据，数据的备份和预警都是非常重要的。我们不能让每个团队自己建立这样的机制，统一把这项功能做一些服务，做一些产品包装在我们的Jenkins产品上。
另外一点这样一个产品化的思路可以实现的就是Jenkins开箱即用，就是你打开一个箱子就是一个健壮的Jenkins，打开箱子就可以帮助你实现这些功能。怎么做呢？之前我们的做法，我们可以提供一些封装好的，把这个包分摊给大家，让大家安装。但现在我们就没有必要做这个事情了，因为我们有容器调度平台，我们把Jenkins作为一个服务放上去，谁需要初始化出来。这样的话对于统一服务提供了非常好的应用性。
其实CI/CD是一种能力，这种能力要嵌入到每个团队里边，我们应该把这样一些能力，这样一些服务提供给所有人，让所有人使用CI/CD的时候不再成为一种瓶颈，而是把它做一个简单的服务，这样的话才能让CI/CD企业级价值的交付，自组织团队才能运行起来，基础就是有一个非常好的平台。
今天上午KK在分享的时候也提到了服务团队，所做的就是打造一个企业级的平台。这样的服务团队对于企业级的其他团队之间的关系就相当于开源版的Jenkins和企业版的Jenkins。我们在做的无外乎就是在公司内部作为一个企业版的Jenkins服务商把这样的服务提供给我们的用户。这也是为什么Jenkins产品化、服务化至关重要的原因。

2、jenkins高可用方案

回过头来还是要说一说，如果你是单体应用的话你可能会关注我怎么去做Jenkins Master负载平衡？我在这里给大家罗列了几个方案：

第一个方案是最官方的方案，就是CoudBees的方案，接下来Sam会给大家介绍，我希望他能给大家提到这一点，这也是大家所关注的企业级的核心功能点之一。

第二个方案是业界非常知名云厂商的方案。其实简单来说他们做了很多的工作，去帮助我们减缓Master的性能问题，建立多Master的工作机制。包括把所有的文件存储转换成数据库存储，包括把所有的加载机制从静态变成动态，实际上做了很多工作。但是我相信对在座的各位来说如果你们的企业没有达到这样的规模，没有这样的一些能力和精力实现复杂的架构工作，我们可以把这个工作交给我们Jenkins的社区，也许到未来他们会提供更好的方案。

第三个方案是OpenStack插件方案，唯一值得提的是这个插件很久没有更新过。这个地方依然是单点，不一定现有的方案都是完美的方案，每个人都在摸索最佳可行路径。

3、Jenkins的分级应用。

为什么不一定要用统一的Jenkins Master，Jenkins Master可以根据我们团队级去做拆分。第二种按照环境拆分，包括测试阶段、个人阶段，和线上生产发布的需求。我们可以根据不同的需求做Master的拆分。这里边带来的问题，当我们使用Pipelines的时候如何更有效的集成Pipelines，如何能把Pipelines的集成做好。这是我们做不同环境和拆分不同的挑战，我也希望把这个问题带给Sam，看看他能不能给我们好的回答。

4、CIDB

CIDB是大家容易忽视的一点，我们建立了很多Master的时候，Jenkins上面非常核心的功能，Jenkins上面有核心的研发数据，所有的日志，分级的信息都在Jenkins Master上，我们的Master挂掉，数据丢失是非常严重的问题。

所以在我们的实践中我们在后台建立了一个非常强大的数据库，把所有的研发课程信息写入数据库里边去。这就保证了我们的Jenkins Master可以随意挂掉，包括我们的CIDB可以很快速的恢复。另外可以简单的汇聚多个数据，这些状态信息，可以做一些监控，做一些预警，做一些性能的评估。一切都是基于数据的。
所以Jenkins上面的数据是企业的核心数据，我们如何能把这些数据很好的保存在数据库里边，能让这些数据创造价值，这也是我们为什么建立CIDB核心的原因。

5、jenkins备份

简单说一下，Jenkins还包括很多备份的方案，有很多方式可以帮助我们实现Jenkins核心数据的备份。
方案一、使用backup插件实现

方案二、使用版本控制实现

方案三、使用rsyns数据同步工具实现

6、jenkins master容器化

这是我们现在正在实施的工作，我们把Jenkins Master放到了容器平台上，虽然没有实现完美的高可用，完美动态的扩容，但是可以实现的就是HA，通过容器调度平台实现Jenkins Master的高可用。Jenkins挂掉的时候可以用同样的方式提起来，现在对我们公司来说所有东西都是跑在容器里边的。所有东西都是在容器里边的，我们非常高兴去拥抱容器的变换，拥抱技术变革。

7、最后一点Jenkins Master Failovr。

因为我们有共享的存储，因为我们有比较成熟的调度平台，Jenkins Master切换就不是特别大的技术难题了。因为我们把所有的数据都做了同步，我们把所有的Jenkins Master尽量变成无状态化，可以回归服务的本质，让它可以尽快的起来和死掉。我们刚才讲了所有内容的汇总希望提升整个Jenkins Master的可用性。
我的演讲到此为止，做得比较粗糙，大家如果有兴趣的话可以加我们的好友，我们可以深入的交流。