让你的 Jenkins 更强壮的高可用实践

作者简介：

石雪峰，Certified DevOps Master，Certified Jenkins Engineer，DevOps时代社区核心成员，全开源端到端部署流水线主创成员，DevOpsDays大会金牌讲师。现任某大型互联网创业公司配置管理与工程效率总监，负责公司DevOps与持续交付体系与平台建设。曾任职于华为、尼康，从事持续交付推进及工具链平台建设工作，拥有多年持续交付落地实践经验。

本文整理自Jenkins User Conference China 演讲：石雪峰-《轻量化 Jenkins 高可用实践》（部分）

前言：

本系列主题主要分成三个部分：

第一部分，Jenkins跟持续交付；
第二部分，Jenkins轻量化思路；
第三部分，Jenkins高可用实践。

本文主要介绍第三部分，前两部分请点击如下链接阅读：

[轻量化 Jenkins 最佳实践](https://blog.51cto.com/15127503/2660185)

三、Jenkins高可用实践。

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

首先想跟大家聊一个话题，Jenkins企业级产品化思路，为什么一开始没有提Jenkins高可用？是因为我觉得这个事情对大家来说更加重要，首先我们需要回答一个问题，企业级的Jenkins需要的是什么？我们怎么样去设定一个企业级的Jenkins？

当前我们面临的是团队对持续交付能力需求的持续增长，就如同上午那个案例一样，当有2500个Master在企业内部同时提供服务的时候，所接触的用户量也非常可观，在这种情况下如何保证统一的环境和统一的服务，这是一个非常挠头的事情。

所以企业级Jenkins的第一要点，就是提供统一环境和统一服务。这里边就包含定期的版本升级，经过验证的组件，以及企业里面通用的功能和常见配置，比如集成权限认证，还有很多最佳实践的内容，这些都需要内嵌在Jenkins产品中，统一管理维护。

另外对于后台统一的数据收集、备份、监控预警等都需要统一建立，而不是让每个团队自己建立一套机制，所有的这些平台服务或者偏向paas层的能力都可以固化到产品里面。

另外基于产品化的思路，我们要实现Jenkins开箱即用，也就是只要打开这个箱子，里面就是一个健壮的Jenkins，无需额外的动作即可使用。

那具体怎么做呢？之前我们的做法是提供一些封装好的二进制包，并把这个包分发给团队安装使用。

但是现在就没有必要做这个事情了，因为有容器调度平台，我们可以把Jenkins作为一个服务放上去，谁需要就初始化出来一份。这样的话对于统一服务提供了非常好的适应性。

我始终认为CI/CD应该是一种能力，这种能力要嵌入到每个团队里边，对团队进行赋能，并把这种能力作为一种简单的服务提供给所有人，让团队在使用CI/CD的时候不再成为一种瓶颈。只有这样才能让CI/CD助力企业级价值的交付，自组织团队才能运转起来，基础就是有一个高效的系统平台。

今天上午KK在分享的时候也提到了服务团队，他们所做的就是打造一个企业级的平台。这样的服务团队和企业级的其他团队之间的关系就相当于开源版的Jenkins和企业版的Jenkins的关系。

我们在做的无外乎就是在公司内部作为一个企业版的Jenkins服务商把这样的服务提供给我们的用户。这也是为什么Jenkins产品化、服务化至关重要的原因。

3.2、Jenkins高可用方案

回过头来还是要说一说Jenkins高可用方案，如果你们公司使用的单点Master，可能会关注怎么去做Jenkins Master负载均衡，我在这里给大家罗列了几个方案：

第一个方案是Jenkins官方CoudBees的方案，接下来Sam会在演示环节给大家介绍，我希望他能给大家详细介绍一下这个功能，这也是大家所关注的企业级的核心功能点之一。
第二个方案是业界非常知名云厂商的方案。其实他们做了很多的工作，去解决Master的性能问题，建立多Master的工作机制。包括把所有的文件存储转换成数据库存储，包括把所有的加载机制从静态变成动态。
但是我相信对在座的各位来说如果你们的企业没有达到这样的规模，没有这样的能力和精力实现复杂的架构工作，我们可以把这个工作交给Jenkins的社区，也许到未来他们会提供更好的方案，而且这个未来近在眼前。

第三个方案是OpenStack插件方案，业界也有很多公司在使用，相当于在Jenkins Master上游建立了一个调度器，来实现任务的分配，屏蔽多Master的细节，不过值得一提的是这个插件很久没有更新过。
另外虽然解决了Master单点的问题，但是Gearman本身还是个单点，所以不一定现有的方案都是完美的方案，每个人都在摸索最佳的可行路径。

3.3、Jenkins的分级应用。

所以换个思路，我们是否一定要做统一的Jenkins Master，是否一定要大而全，再解决单点瓶颈问题，是否可以把Jenkins Master根据团队级去做拆分，或者按照环境拆分，包括测试阶段、个人阶段，和线上生产发布阶段。

我们可以根据不同的需求做Master的拆分，这里边带来的问题是，当我们使用Pipeline的时候如何更有效的做Pipeline之间的集成，这一点在目前Jenkins实践里面还没有特别完美的解决，也是做不同环境拆分的挑战，我希望把这个问题带给Sam，看看他能不能给我们一个好的建议。

3.4、CIDB

CIDB是大家容易忽视的一点，Jenkins Master上面有核心的研发数据，所有的日志，任务信息都在Jenkins Master上，如果Master挂掉，数据丢失是非常严重的问题，尤其在有数量众多的Master的时候，做好过程数据的管理和收集将是我们能否进行持续改进的根本原因。

所以在我们的实践中，我们在后台建立了一个非常强大的数据库，把所有的研发过程信息都写入数据库。这就保证了我们的Jenkins Master可以随意挂掉，通过CIDB可以很快速的恢复。

另外有了元数据，就有了很大的想象空间，比如可以简单的汇聚多个数据，做一些监控，做一些预警，做一些性能的评估，这一切的一切都是基于数据的。

所以Jenkins上面的数据是企业的核心数据，我们希望能把这些数据用好，让这些数据创造价值，这也是为什么建立CIDB核心的原因。

3.5、Jenkins备份

简单提一下Jenkins的备份方案，按照需求和备份内容频率的不同，有多种方案供参考：

方案一、使用backup插件实现

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

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

3.6、Jenkins master容器化

这是我们现在正在实施的工作之一，我们打算把Jenkins Master放到了容器平台上，虽然没有实现完美的高可用，完美动态的扩容，但是可以实现的就是HA，当Jenkins挂掉的时候可以用同样的方式快速恢复。

现在对我们公司来说所有东西都是跑在容器里边的，我们非常高兴去拥抱容器技术，拥抱技术变革。

3.7、最后一点关于Jenkins Master Failover

因为我们有共享的存储，有比较成熟的调度平台，Jenkins Master切换就不是特别大的技术难题了。这里面的核心是做好数据同步，把所有的Jenkins Master尽量变成无状态化，回归服务的本质，让它可以尽快的起来和死掉，这对于多Master来说也是必备的能力。

我刚才讲了所有内容汇总起来就是希望提升整个Jenkins Master的可用性。