首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >让你的 Jenkins 更强壮的高可用实践

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

作者头像
DevOps时代
发布2018-02-02 16:30:30
5.3K0
发布2018-02-02 16:30:30
举报

前言:

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

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

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

轻量化 Jenkins 最佳实践

三、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的可用性。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-01-12,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DevOps时代 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言:
  • 三、Jenkins高可用实践。
    • 3.1、企业级jenkins产品化服务化思路
      • 3.2、Jenkins高可用方案
        • 3.3、Jenkins的分级应用。
          • 3.4、CIDB
            • 3.5、Jenkins备份
              • 3.6、Jenkins master容器化
                • 3.7、最后一点关于Jenkins Master Failover
                相关产品与服务
                容器服务
                腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
                领券
                问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档