CI/CD | 不可忽略的Jenkins基础架构修复问题
在系列文章第一篇和第二篇中,大家已经看到了在CloudBees的帮助下,让管理Jenkins解决方案从一个大麻烦变成轻而易举就能解决的事情。但是,现在让我们反思并退一步。有时候,这些问题并不是表面上的——它们是在成长的过程中造成的,特别是当您的公司现在就需要新功能时;或者是当您收购了一个新的团队,您需要在昨天就为他们安装好!
这并没有留下空间给您在增加工作流程时引入最佳实践,因为最简单的途径可能就是在您的Jenkins实例上堆积更多的东西,或者只是让人们离开并创建自己的实例,这就好比在公司里又建立自己的小公司。这确实是完成了工作,但现在看来呢?并没那么好用了。而且从长远来看,这将给您的软件发布流程带来挑战。在最后一篇文章中,我想提出一些Jenkins实施的基础设施问题——那些隐藏在表面之下的困境。看看有多少人和我有同样的遭遇。不过不用担心,隧道的尽头还是有一线希望的。
不完美的解决方案都有代价
随着您在前两篇文章中读到的困境波及到您的企业,您可能会遇到一系列的下游效应,每一个效应都会对您流水线的工作方式、发布代码的速度以及整个运营成本产生影响。理想情况下,所有这些问题都将受到严格控制,以推进您的业务目标,但正如你我都知道的那样,随着企业规模的扩大,事情很难这样发展。
Jenkins孤岛、Jenkinsteins,还是两者兼有?
不受管理的Jenkins缺点会造成的第一个也是最深刻的一个后果是,它们将不可避免地决定您的Jenkins环境的结构。Jenkins控制器往往会落入三个组织陷阱,每个都倾向优先考虑某些问题,而牺牲其他问题。底线是什么?这些方法代表了一种创可贴式的解决方案(哪里有问题补救哪里),并没有解决它们想要规避的潜在系统缺陷。
Jenkins孤岛:“控制器太多”的问题
由于不受管理的Jenkins会使协作和标准化变得困难,因此团队想要做自己的事情是很正常的。如果允许的话,他们会自行设置控制器,自定义工具链,并在自己认为合适的情况下维护SDLC。这对于少数团队来说已经是很有效的方法了,但对于拥有大量开发人员的企业来说,这只会增加他们的Jenkins困境。这种犹如狂野西部一般的场景产生了Jenkins孤岛现象——无数个互不相关的服务器/团队,经常出现分歧,还会放大沟通、治理、合规性和安全问题。
Jenkinsteins:“巨型单一控制器”的问题
与不受管理的Jenkins相关的大多数困难都来自于试图管理太多的控制器。许多企业都想通过将所有内容放在一个控制器上来解决这个问题。虽然这确实缓解了一些维护、治理和合规性问题,但这带来了新的问题:
一台服务器不可能成为团队的一切。有些团队将会放弃首选的定制,甚至是基本的插件(如果它们引入兼容性冲突的话);
在一台服务器上运行所有项目可能会使服务器超载,从而拖慢整个企业的构建和测试时间;
单个服务器就会成为故障的唯一来源,而服务器停机可能会破坏整个企业的生产力。
Jenkinsteins+孤岛:“两个世界中最糟糕的”问题
许多企业开始时采用单一控制器的方法,然后最终屈服于给团队自由发挥的需求。单一控制器于离群服务器的组合使得Jenkins环境特别混乱,它结合了这两种场景的缺点,同时还消除了大部分优点。
谁负责技术支持?
在我们探索不受管理的Jenkins带来的挑战时,重要的是要记住,当您遇到麻烦时,社区支持和您自己的团队成员是您寻求帮助的唯一途径。开源社区互助是一个鼓舞人心,但它们并不是企业级的。这可能会带来一些新的问题:
以快速增长/转型为目标的企业需要24/7全天候、权威的支持来保持节奏。缺乏专门、可靠的支持服务,将造成支持瓶颈,无形中抑制了企业发展;
内部支持会成为一项不受控的开支。随着团队成倍增加,团队成员在自助支持上花费的时间也会成倍增加。这在生产力、预算和增长方面的损失有多大,谁也说不准;
停机会使企业陷入瘫痪,造成重大损失。如果灾难发生时没有足够的支持人员待命,这就成为一个真正的风险。
这让我们付出了什么代价?
为什么这些问题都很重要?因为它们最终都会归结为一个价格标签。更糟的是,这个价格标签往往是看不见的。你通常能看到Jenkins是如何帮助你守护底线的,但你不一定能看到它是如何伤害你的底线的。不必要的预算项目可能包括:
由于管理开销、故障排除、服务器维护不善、安全漏洞等导致的生产力损失。
调度延迟,以为您的工程师每周可能会花费15+小时在管理和支持上,而不是写代码。
工作时间浪费在重复性任务、无望的治理和追求合规性上。
错失商机,因为您专注于解决流水线的挑战而不是创新。
工作人员因试图强力解决上述问题而气愤。
可扩展性瓶颈——当SDLC很混乱时,您如何根据需要扩展CPU、RAM和磁盘空间?您要么为未使用/闲置的资源付费,要么就在需要时因缺乏资源而阻碍发展。
更高的基础架构设施费用——如果您不知道空闲服务器何时处于活动状态,那还怎么从闲置服务器中收回成本?
任何来源导致的停机时间——损坏的Jenkinsteins、未识别的错误、兼容冲突、由风险代码引起的网络攻击等。
谁可以在基础设施方面提供帮助?
或者说,隧道尽头的希望在哪里?
又或者说,CloudBees CI帮助你实现最大的投资回报率
下一个问题很明显:你能从哪里得到这一切?最简单的答案是什么?那就是CloudBees软件交付平台。CloudBees CI是该平台的一部分。CloudBees CI缓解了上述所有问题,正如我们在之前的文章中看到的那样。作为Jenkins代码的最大贡献者,CloudBees及其工程师是权威的Jenkins专家。CloudBees团队都很爱Jenkins,但他们很清楚它的潜在陷阱,所以他们致力于最大限度地发挥Jenkins的潜力。
还记得第一篇文章中的这张图吗?它展示了CloudBees CI运营中心(我们之前谈到的集中控制平面)如何重构您的Jenkins环境以促进我们之前谈过的工具包,无论您部署在本地还是在云上。
与一个充满了插件(插件会支持不同的团队,许多许多job会减慢流水线并产生很长的队列)的单个巨型控制器所不同的是,每个团队都有自己的控制器、自己的对象,并在需要时访问共享代理池。
对我来说,这意味着我的团队实现了工作负载隔离——没有其他团队的插件干扰我的插件(我说的就是你们,Java-O团队)。在隔离之外,我们可以通过监视在流水线中可能排队的事件来与其他团队合作(自动化是一件非常美好的事,不是吗?),当我的容量激增时,我们甚至可以跨特定团队共享代理。
我们已经讨论了CloudBees CI可以做些什么来帮助管理Jenkins,你可以了解到客户是如何成功地加快他们的发布周期,但工具集中的另一个工具是CloudBees本身。不是功能,而是人。CloudBees CI是企业版Jenkins——我们了解Jenkins,并为开源社区做出贡献。由于我们为开源项目贡献了大量代码,因此我们有独门绝技,可以在出现问题时解决问题。
使用 CloudBees,您就等于拥有:
客户成功经理——客户成功经理通过提示、技巧和更新帮助您优化CloudBees CI体验,确保您始终走在增长的道路上;
专业服务——无论您是刚开始使用CloudBees、掌握DevOps,还是从旧模式转向新模式,我们的专业服务团队都能快速帮助您实现目标;
卓越的支持
最大的Jenkins认证工程师团队为你提供24/7全天候随叫随到的支持;
通过与我们的支持团队一起主动规划您的升级,辅助更新可以使CloudBees CI保持最新、稳定和合规;
CloudBees在中国的授权合作伙伴龙智为您提供咨询、实施、培训和技术支持等服务。
今天的Jenkins已不可同日而语——软件交付已经有了进步,开源社区也接受了这项技术,这使得它更容易与最新技术集成,从而推进您的应用程序开发工作流程。它有了更多的集成、更多的作业、更大的灵活性和更强的功能。让CloudBees来引导您实现灵活性,并使您的工作流到达所需的清洁、高效、合规及快速要求。您已经拥有这个力量,让我们来告诉您如何使用它。
文章来源:https://www.cloudbees.com/blog/whoa-the-woes-and-fix-your-infrastructure
如果您已准备好最大限度地发挥Jenkins的潜力,请立即联系CloudBees授权合作伙伴——龙智:
官网:www.shdsd.com
电话:400-666-7732
邮箱:marketing@shdsd.com