Jenkins 很酷,但是不完美,有历史局限性造成的问题。本文仅从“如何更好给研发团队赋能的角度”,剖析Jenkins, 探讨理想的持续交付平台, 不带货无广告~
提到DevOps/持续集成这些话题,由于开源免费,历史悠久,插件API丰富,群众基础好(可借鉴模仿案例实践资料多)等原因,Jenkins永远是那个最亮的“仔”,也是众多相关领域厂商或者企业**绕不开的“工具”。
不过,依然有很多“不完美”,仅仅是个没有“DevOps灵魂”的CI工具(理由如下),但不得不承认它又是“免费”又有“用户量”的CI工具。下面我通过以下几个方面详细做些剖析**
首先 Jenkins 是一个巨石系统,它是一个单体的结构。为什么到现在为止大家好像没有看过特别成熟的 Jenkins 集群级的方案,或者很少看到高可用的方案,大部分情况下大家看到的是给不同的团队或者是不同的部门分配多个 Master ,而不是共用一个大的 Master ,其实这个主要取决于 Jenkins 内部的实现原理和机制。
传统意义上来讲一个服务会有两层,一层是你的服务层,一层是你的数据层。但是 Jenkins 因为历史的一些原因,导致所有的存储都是以文件的方式存储在磁盘上,存储在磁盘上就会一个比较大的性能问题。在 Jenkins home 里有一个 jobs ,里面存储的就是大家构建的每一个任务,还会存构建任务的配置等等。一系列的东西都以文件的方式,以特定的目录结构存储在磁盘上。
当 Jenkins 第一个步骤,比如你重启 Jenkins 的时候,它会做什么?先把磁盘上 jobs 目录都扫一遍,加载到自己的内存里里,再去做后续的东西。比如刚才说的高可用的方案,假如用共享存储,现在在一台 Jenkins Master 上写了一个job,其实另一台 Jenkins 是没有感知的,因为没有加载这个job。
Jenkins 的插件那么多,到底该选哪一个?而且出现很多问题是1+1小于2,有时候必须安装第二个插件来满足,两个插件组合的时候又可能达不到很好的合力,这导致很多业务场景不得不去装很多额外的插件来满足自己的需求。开发者对 Jenkins 熟识的程度大部分在于自己插件的使用经验。
当jenkins支持的场景越复杂,你会发现你要管理很多插件,这是你构建Jenkins和复制Jenkins面对最大的问题;同时,插件由于是个人贡献维护,很多插件会有年久失修情况。
Jenkins的插件包括Jenkins本身,它是有一些漏洞的,当你去用一些插件的时候,你要不停的更新它。
不知道有没有人在一个Jenkins中配200个人,你肯定碰到到第80个人的时候,整个用户配置界面会卡。
要想 Jenkins 用得好,插件不能少。但是 Jenkins 的插件会带来一些性能问题,每一个插件都是在项目启动的时候就会加载到内存里,当插件越大的时候,对性能的损耗越大。要选择自己合适的插件去构建自己的 Jenkins 。
抛开Jenkins上面的缺点不谈,回到现实场景中,我们需要从更大的视角(即持续交付)来理解一个“持续交付平台”需要扮演的角色。
从上图中可以看出,从开发人员写下代码到服务最终用户是一个漫长过程,整体可以分成三个阶段:
如果从持续交付角度看,其最核心诉求就是要让上图三个阶段能够无缝连接并自动化运行起来,从而达到持续交付的两个核心目标:提高交付频率(部署次数)和降低部署延时(从代码提交到上线的时间差)。
参照如上持续交付的流程,可以发现持续交付对于一个部署系统的要求绝对不仅仅是一个自动化的部署过程,这也是在有了Jenkins和其相关部署插件后仍然需要搭建独立部署系统的原因所在。具体来说,我们可以从下面几点分析:
尽管持续交付希望自动化完成从代码到部署上线的整个流程。但是整个持续交付过程有多个不同角色的人参与其中(开发、测试、运维甚至还经理及市场人员)。其中有些角色(如开发/测试)需要关心构建过程,而更多的角色(如运维等)绝大时候都是从制品开始部署工作。这也就要求构建和部署过程相互解耦,能够独立操作。
构建和部署这两个过程通过制品(Artifact,又称为部署包)连接(制品是构建过程的产出,同时是部署过程的输入)。如果它们相互解耦,自然就需要有统一的地方管理存储和管理这些制品,即统一制品库。
有了统一制品库后,构建过程自动提交产生的制品到此,而部署过程则主动到制品库拉取需要的制品进行部署,从而实现构建和部署的完整解耦。
服务上线需要涉及到很多不同目的环境(开发、测试、预发、生产、演示等)。在云化基础设施中,环境内部的资源会频繁变化(例如,Auto-Scaling时刻都有可能添加或者减少你的云主机)。
这时候需要对部署流程隔离部署环境差异以及环境内频繁变化的基础设施。当需要执行一个部署时,操作人员只需要指定部署到哪个环境(即环境名称或者ID号),而不需要关心环境内部的任何信息,只需把部署请求分发到指定环境内的每台主机并自动执行。
如果基于Jenkins来直接部署,则必然把环境管理的很多复杂度引入到部署流程内部。
为保障服务的高可用,落实部署和发布的解耦以及其他业务需要,用户常需要支持如灰度发布、A/B测试发布等部署需求。一个独立的部署系统在此可以提供多种部署策略,并结合环境管理等其他功能满足业务上对部署和发布的各种需求。同样,Jenkins及其部署插件并没有提供这样的能力。
在一个公司内部经常有不同的项目,使用不同的编程语言,而部署流程也五花八门。从控制风险,减少重复操作,降低部署自动化难度等多重考量,公司都倾向制定一套标准的部署流程。
这时候,独立的部署系统就可以帮助用把这些规范落实下去并在日常的部署过程中时刻校验(在软件工程领域,几乎所有的规范落实都得靠工具来助一臂之力,否则基本都会变成纸面上的规范而已)。
如果基于Jenkins来直接部署,如何落实这些部署规范仍然是一个很困难的事情,因为Jenkins及其部署插件并未对此提供任何实质性的支持。
部署是一个团队从代码到服务的关键路径,这上面的所有操作数据都值得记录并用于各种运营支持(包括安全审计、部署记录查询、部署频率和失败率分析等等)。基于Jenkins直接部署当然也可以获取这些数据,但是把它做在独立的系统内会更灵活和方便。
如之前提到,部署不仅仅开发和测试人员需要,要努力让部署服务化,从而让团队内任何一个人都可以随时触发一次部署。Jenkins的操作界面对于开发或者测试人员可能还比较方便,但是对于其他人员来说则过于复杂。
当然,除了上面列出的这些原因外,你还要解决部署版本的管理等,这里就不一一列举。
如前所述,一个理想的持续交付系统需要包括的内容是非常丰富的,特别是要面临各种复杂场景,不同技术栈的团队,异构的各种内部系统(绝对不仅仅是Jenkins插件要做的那些事情)。
如下图所示,持续交付系统需要连接项目中涉及的人、代码,制品库,以及环境等,Jenkins仅仅起到了简单的连接作用。
所以,能够给研发过程赋能的“持续交付平台”需要具备如下特点
DevOps持续交付涉及的工具如同各类不同形状的积木,你的目标是建造一个房子,可能你现在手中只有很少的积木,或者你有很多重复的积木,但是唯独缺少三角形完成屋顶部分。
想清楚不迷路,不同的人搭建方法不同,只要最后搭建合理漂亮实用,恰到好处就可以,期待更好赋能研发过程的持续交付平台~
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://www.cnblogs.com/FLY_DREAM/p/17842858.html
内容来源于网络,如有侵权,请联系作者删除!