Docker 管道的 "inside"在 Docker 容器内运行的 Jenkins 从属设备中不起作用

Question

我在使用 Jenkins 管道脚本运行时遇到问题，该脚本使用 Docker Pipeline 插件在 Docker 容器中运行部分构建。 Jenkins 服务器和从属服务器本身都在 Docker 容器内运行。

设置

• 在 Docker 容器中运行的 Jenkins 服务器
• 基于自定义镜像 ( https://github.com/simulogics/protokube-jenkins-slave ) 的 Jenkins 从属也在 Docker 容器中运行
• 基于 docker:1.12-dind 的 Docker 守护进程容器图片
• Slave 像这样开始:docker run --link=docker-daemon:docker --link=jenkins:master -d --name protokube-jenkins-slave -e EXTRA_PARAMS="-username xxx -password xxx -labels docker" simulogics/protokube-jenkins-slave

基本的 Docker 操作(拉取、构建和推送镜像)在此设置下运行良好。

(非)目标

• 我希望服务器根本不需要了解 Docker。这应该是从站/节点的一个特性。
• 我不需要动态分配从站或临时从站。手动启动的一个从站足以满足我的目的。
• 理想情况下，我想放弃从站的自定义 Docker 镜像，而是使用 inside由通用 Docker 从机中的 Docker 管道插件提供的功能。

问题

这是导致问题的代表性构建步骤:

image.inside {
    stage ('Install Ruby Dependencies') {
        sh "bundle install"
    }
}

这会导致日志中出现如下错误:

sh: 1: cannot create /workspace/repo_branch-K5EM5XEVEIPSV2SZZUR337V7FG4BZXHD4VORYFYISRWIO3N6U67Q@tmp/durable-98bb4c3d/pid: Directory nonexistent

以前，此警告会显示:

71f4de289962-5790bfcc seems to be running inside container 71f4de28996233340c2aed4212248f1e73281f1cd7282a54a36ceeac8c65ec0a but /workspace/repo_branch-K5EM5XEVEIPSV2SZZUR337V7FG4BZXHD4VORYFYISRWIO3N6U67Q could not be found among []

有趣的是，这个问题在 CloudBees 插件文档中有详细描述 https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/index.html#docker-workflow-sect-inside :

For inside to work, the Docker server and the Jenkins agent must use the same filesystem, so that the workspace can be mounted. The easiest way to ensure this is for the Docker server to be running on localhost (the same computer as the agent). Currently neither the Jenkins plugin nor the Docker CLI will automatically detect the case that the server is running remotely; a typical symptom would be errors from nested sh commands such as

cannot create /…@tmp/durable-…/pid: Directory nonexistent or negative exit codes.

When Jenkins can detect that the agent is itself running inside a Docker container, it will automatically pass the --volumes-from argument to the inside container, ensuring that it can share a workspace with the agent.

不幸的是，上一段中描述的检测似乎不起作用。

问题

由于我的服务器和从属服务器都在 Docker 容器中运行，我必须使用哪个卷映射才能使其工作？

Answer 1

我已经看到了此问题的各种变体，以及由 kubernetes-plugin 提供支持的 agents。

我认为要使其正常工作，agent/jnlp 容器需要与build 容器共享工作空间。

通过build容器，我指的是将运行bundle install命令的容器。

这可能通过 withArgs 来实现

问题是你为什么要这么做？无论如何，大多数管道步骤都在 master 上执行，实际构建将在 build 容器中运行。同时使用代理的目的是什么？