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