写点什么

CI/CD | 不可忽略的 Jenkins 基础架构修复问题

  • 2023-03-10
    上海
  • 本文字数:3137 字

    阅读完需:约 10 分钟

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 来引导您实现灵活性,并使您的工作流到达所需的清洁、高效、合规及快速要求。您已经拥有这个力量,让我们来告诉您如何使用它。


作者:萨曼莎·弗罗斯特(Samantha Frost),CloudBees 公司产品营销经理。

文章来源:https://www.cloudbees.com/blog/whoa-the-woes-and-fix-your-infrastructure


用户头像

还未添加个人签名 2021-05-18 加入

分享DevSecOps解决方案最新动态,帮助您学习与使用Atlassian, Perforce, Whitesource, Cloudbees及龙智自研产品,实现软件研发的高度协同与自动化,提高交付效率与质量,并确保开发过程可追溯、可度量。

评论

发布
暂无评论
CI/CD | 不可忽略的Jenkins基础架构修复问题_ci_龙智—DevSecOps解决方案_InfoQ写作社区