限制主服务器上的 Jenkins 共享库克隆答案

【问题标题】：Throttling Jenkins shared library clones on the master限制主服务器上的 Jenkins 共享库克隆
【发布时间】：2017-12-08 20:35:59
【问题描述】：

我不确定我是否在标题中很好地总结了这一点，所以欢迎提出建议。

Jenkins 配置：

具有 0 个执行程序的 Jenkins linux 主机。
许多不同的代理/代理执行者。
许多声明性管道作业大多具有脚本化阶段。
声明性管道指定agent { label "some-label" }
许多受信任的共享库（在主 Jenkins 配置中配置的库）是使用 git 作为 VCS 加载的。
上面的大多数共享库都是有意隐式加载的，而不是显式加载的。

假设： 当共享库被隐式加载时，它们总是被克隆到主服务器上，并且脚本在执行实际的管道代码之前被加载到内存中。

问题： 对于每个运行的管道，在任何管道代码可以序列化并在代理上运行之前，在主服务器上克隆 X 个受信任的共享库。我没有办法知道你可以告诉 Jenkins 一次只在主服务器上运行 N 个克隆。最终结果是，当大量管道同时运行时，同时在 master 上运行的 git clone 的数量很大，这会压倒 Jenkins 服务器或 git 服务器并导致构建失败（要么由于超时或其他相关原因）。

解决方法（排序） 隐式加载尽可能少的受信任共享库，然后显式加载它们，同时从 Lockable Resources Plugin 包裹在 lock ... { } 中，以限制 git 克隆的数量。但这并不能真正解决需求，因为您需要使用隐式加载与显式加载是有特定原因的。

希望我遗漏了一些明显的东西:)

【问题讨论】：

我相信你不能改变詹金斯的行为本身（现在）是正确的。我认为对此的大多数答案都是意见，但我会集思广益一些想法。 *通过限制连接和带宽在网络级别做一些事情。 * 将一些库合并在一起，因为它们无论如何都是隐式加载的。 * 定期将存储库从您的 VCS 同步到 Jenkins 主服务器，并将全局库配置点放在这些本地文件资源中。 * 确保 VCS 的大小和调整正确，可能使用只读副本。这些只是需要考虑的几件事，祝你好运！

标签： jenkins jenkins-pipeline throttling

【解决方案1】：

当然，我的建议是固执的。

以下项目引起了我的注意：

许多受信任的共享库（在主 Jenkins 配置中配置的那些）是使用 git 作为 VCS 加载的。

鉴于这张票是开放的，只有很少的 cmets/投票： https://issues.jenkins-ci.org/browse/JENKINS-48210,

Jenkins 社区并不觉得它对许多人有吸引力。

我认为 jenkins 网站上关于图书馆的文档，有一些隐藏的假设：

SHARED 库只有在其代码用于多个作业时才有意义，即减少代码重复。您可能会通过将每个作业的代码包装成伪“共享”库代码来滥用这个想法，......这是对术语的滥用，恕我直言
你不能通过网络推或拉超过它可以给予/接受的东西；）

那么你可以推断出哪些实用的 AI：

升级硬件：最便宜的解决方案（考虑开发人员的小时费率与硬件成本）是购买更好的 NIC 或启动更强大的虚拟机并为其分配更多吞吐量
我会重新审视您构建共享库的方式。将共享代码保留在 1 个包含多个类的快乐库中，这样可以将每个构建的 git 流量减少到 1 个。

此外，如果您想了解更多关于您的 CI 网络和 git 服务器之间的链接速度，以及有多少作业并行运行 [O(?)] 的信息，也很高兴。

请告诉我您是如何解决问题的。（听起来很有趣，我很想了解更多！）

【讨论】：