Dockerizing Jenkins构建 - 奴隶作为容器或构建为容器？

Question

我正在努力找出使用Docker在Jenkins CI / CD基础设施中容纳构建版本的最佳策略。 从我看到我有2个选项：

（1）使用Docker插件在Docker主机上按需配置的短暂从属： https ： //wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin一旦构建完成，奴隶就会被处理掉。 因此，只有一个版本可以在单个从站上运行。

（2）使用CloudBees Docker自定义构建环境插件使用在Docker容器内运行构建的静态从属（例如VM）： https ： //wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Custom+Build+Environment +插件因此，多个（隔离的）构建可以在单个从属上运行。

一种方法相对于另一种方法的主要优点/缺点是什么？ 何时以及为什么我应该选择一个而不是另一个？ 对我来说，这似乎并不明显。

我怀疑构建的权重较轻，因此对于一个CI / CD基础设施来协调运行许多作业的大型端到端管道（2）将更具可扩展性 - 每个Jenkins从站在主节点上至少引入2个线程。

编辑

Answer 1

我的偏好是使用Docker插件的选项1（短暂的奴隶）。

使用此插件，您可以在全局Jenkins设置中声明构建映像，您可以影响Docker镜像的标签：

在您的工作中，您只需使用相关标签，Docker插件将创建相关的从属设备到新容器中。

使用Docker插件，Jenkins将在几秒钟内启动一个新的奴隶。 因此，即使您使用的是具有大量阶段的管道，它也能正常工作。

这就是我要在Forgerock（我的公司）实施的内容：

• 2台功能强大的裸机（带SSD，32核和1 TB RAM）
• Jenkins Docker插件
• 使用Artifactory缓存Maven工件（不下载互联网）
• docker容器将使用本地Maven缓存（所以我肯定不会使用旧的/奇怪的Maven工件）

我在一台小型裸机上做了POC，效果很好:)

如果您使用没有Maven缓存的短暂从属，则可能会成为性能问题。

关于Jenkins插件，有一个由Nicolas De Loof开发的新插件 ： Docker Slaves插件 。

我必须尝试这个新的插件。