所以我的问题是如何管理服务器池，以便可以选择任何可用的池服务器对于构建版本
声明拥有该构建版本的服务器无法用于其他构建版本
成功构建之后，该服务器将再次可用（之后需要手动返回到池中）。
我不能只是在从属节点上使用执行程序，因为我们重新启动服务器，这将导致工作中断。
我当前的解决方案是：
将池服务器设置为Jenkins从属服务器，每个服务器都有一个执行程序，并具有一个公共标签
将管道级分配给该公共标签，选择其中一个从属服务器一个免费的执行程序-此阶段移动
slave.jar以防止Jenkins重新启动分配的从属（这很烦人）下一个管道阶段使用
node.getComputer().disconnect()禁用s奴隶-看来这必须在主服务器上运行，因此必须处于不同的阶段post { success { ... } }使用ssh将slave.jar移回到服务器上的适当位置，然后将node.getComputer().connect(true)移回服务器，以使其再次被拾取这通常可以正常工作，而且有点酷，但会给管道增加很多噪音，更糟的是，它会遭受步骤2和步骤3之间的竞争。之前的作业断开节点之前，从节点断开连接。发生这种情况时，事情会严重中断。
是否有人使用Jenkins来管理需要支持池中重启的服务器池，以及如何做？
关于在Jenkins之外管理池的方法有任何想法，但是以某种方式将分配的节点放入Jenkins中进行测试运行？我错过了插件，等等。
我检查了google返回的有关奴隶断开问题的一些结果，最有前途的是https://groups.google.com/forum/#！ topic / jenkinsci-dev / ch2lQZvZdkw-由于我无法在我的管道中解析
OfflineCause.UserCause类，因此该建议对我来说失败了。我只知道足够的Java和Groovy危险！#1 楼
我在Lockable资源插件中找到了丢失的部分。lock(label: 'server-pool', quantity: 1) {
...
}
现在用于测试的服务器根本不需要作为从属服务器进行管理，这非常重要。简化了事情。
#2 楼
对我而言，但如果我错了，请纠正我，不应重新启动Jenkins服务器，但它们应创建VM并重新引导它们。当我读到这个问题时，我得到了从属重新启动的印象，即I can't just use the executor on the slave node because we reboot the server and that would kill the job.对我来说，jenkins从属似乎应该创建一个VM，运行测试，重新启动系统，运行一些其他测试，最后删除VM。 > 从生产的角度来看，但是如果我错了，请再次纠正我，该团队没有使用Jenkins来配置系统并随后重新启动节点？他们可能会使用Jenkins来开始供应步骤，但是他们不会重启Jenkins系统，对吗？
我建议从Production透视图开始，例如团队目前如何配置系统？例如。厨师？如果是这样，他们将如何运行？如果他们运行厨师应用程序，则可以由Jenkins从属服务器运行，但是我不会重新启动jenkins从属服务器，而是自动创建，配置，重新启动并杀死它的VM。后者仅适用于测试目的。
评论
“自动执行创建VM的过程，对其进行配置，重新启动并杀死它”-我完全同意，但是不幸的是，我们的一些基础架构提供商没有提供这种能力，因此测试其基础架构中的宠物是一个问题。
– mghicks
2017年12月4日2:00
评论
好像您在使用Jenkins一样，是伪监控程序。您正在使用公共云，私有云还是裸机？使用适用于您的云提供商的API来管理系统池可能会更好。@jayhendren我们确实为我们的IaaS提供程序调用了API，因为它们是我们必须测试的一部分-但是，遗憾的是，我们没有能力按需启动服务器。
设置过程我应该考虑一个CMS，例如人偶吗？
@ 030是的，特别可以。