问题描述
在项目中使用Jenkins时，需要扩展Jenkins的能力。他们有一个AWS服务器，上面运行着Jenkins Master和一个Jenkins slave（2个执行器），但是他们需要更多的执行器来增加构建能力。他们有三个选项：
1. 扩展：将AWS实例变大并添加更多的执行器。
2. 扩展：将AWS实例变大并添加另一个Jenkins slave进程。
3. 扩展：创建另一个AWS实例，并将其作为Jenkins slave连接到主服务器。
由于他们是一个大型组织，当前的Jenkins Master已经可以访问到他们需要的所有地方，所以他们希望选择第二个选项。但是第三个选项需要经过繁琐的审批流程，需要几周的时间。
用户的问题是：
1. 第二个选项是否存在技术问题？也许每个Jenkins slave的执行器不知道其他slave的执行器？
2. 一般来说，扩展Jenkins的最佳方法是什么？扩展还是扩展？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在同一台机器上运行多个Jenkins slave没有根本性的技术问题。事实上，Running Multiple Slaves on the Same Machine列出了几个理由支持这样做：
– 您希望在配置的节点之间有更多的可配置性。例如，您可以将一个节点设置为尽可能多地使用，将另一个节点设置为仅在需要时使用。
– 您可能有多个Jenkins主服务器安装，构建不同的项目，因此这种配置允许您在同一台机器上为多个主服务器拥有多个slave。是的，使用Jenkins，您真的可以为两个主服务器提供服务。
– 您可能希望利用启动/停止/替换虚拟机的便利性，也许结合Jenkins插件（如Libvirt Slaves Plugin）。
一般来说，扩展是首选的，主要是因为扩展的能力通常受到可用物理资源类型/大小的限制。
特别是在增加构建能力时，我建议分析您实际的构建情况，确定它如何使用机器资源，它的瓶颈在哪里以及它引发的可扩展性限制，以确定扩展是否有帮助。
例如，我遇到过这样的情况：在同一台机器上并行构建的两个构建的时间比同一台机器上顺序执行（不重叠）的这两个构建的总时间还要长。在这种情况下，我甚至不会考虑扩展，因为它实际上会降低整体的构建能力。
方案2
使用Kubernetes和Helm。
我建议使用Jenkins Helm chart。使用helm install stable/jenkins命令进行安装，并自动进行扩展。
https://github.com/kubernetes/charts/tree/master/stable/jenkins
方案3
我认为你应该选择两者都不做；）
好吧，有点道理。我认为你需要更多的执行器，也许你的构建非常耗费资源？我会运行至少4个，但我们运行6到8个，具体取决于作业。我喜欢将执行器数量与核心数匹配。因此，您可能需要扩展节点，我们为我们的4-8个执行器运行一个M4大型实例。
我还认为你应该明智地进行扩展。Jenkins有一个插件，可以根据构建队列中的内容自动在AWS上进行扩展。基本上，您告诉它有多少作业以及在启动新slave并将作业发送到新slave之前等待多长时间。您还可以设置slave的最大数量、最小数量等。
方案4
我会选择扩展而不是扩大，选择第三个选项。我们已经建立了一个设置，所有Jenkins代理都在一个ECS上运行（基于自定义的Docker Jenkins），并具有自动扩展组。我们所有的Jenkins主服务器都与ECS通信，从而在ECS上共享工作负载，无需重新创建Jenkins主服务器。
以上是几种扩展Jenkins的方法，您可以根据您的具体需求和环境选择最适合您的方法。
请注意，无论您选择哪种方法，都需要确保您的Jenkins Master和Jenkins slave之间的通信和连接是可靠和稳定的，以确保构建的顺利进行。
参考链接：
– Running Multiple Slaves on the Same Machine
– Libvirt Slaves Plugin
– Jenkins Helm Chart
– Amazon EC2 Plugin