Jenkins - Docker 云代理 VS 管道中的 Docker

Question

我试图理解为什么这么多人选择在 Manage Jenkins -> Clouds 中设置“Docker 云代理”（tutorial1、tutorial2），而不是仅仅在管道中使用“Docker 代理” ，这是官方支持的（官方文档）。

在我看来，如果我采用“Docker云代理”方式，

1. 我必须登录到托管 Jenkins 的服务器。
2. 我需要编辑 Docker 的服务文件“/lib/systemd/system/docker.service”并手动公开 REST API 端口。
3. 在管理 Jenkins Cloud 中进行设置。
4. 创建您自己的 Docker 镜像。
5. 在“Docker 代理模板”下添加该 Docker 镜像
6. 最后在管道中引用该模板的名称。

如果我直接在管道内使用“Docker 代理”支持，而不是所有这些额外的步骤（官方文档），

1. 我什至不需要登录托管 Jenkins 的服务器。
2. 我还可以使用“Dockerfile”进行更多自定义并将其提交到源代码。

选择“Docker云代理”的具体原因是什么？或者什么时候应该选择“Docker云代理”？

像这样公开 Jenkins REST API 端口的官方文档在哪里？

谢谢你。

Answer 1

我不知道我是否可以对这个问题给出全面的答案，但我想到了一个方面——工作隔离。当您使用 docker-plugin （提供 Docker 云）时，Jenkins 会为每个作业运行创建一个新代理。当您在

docker

级别使用 agent 中的

stage

symbol

时，您正在重用管道级别代理，而当您在

pipeline

级别执行此操作时，您的容器正在控制器上运行，这不是可扩展。

一般来说，一次性代理更具确定性和安全性，因此您最终会使用它们，而 docker-cloud 可能是最简单的方法。当然这不是最好的方法，正如 @alexander-pletnev 提到的，k8s 可能更灵活。