Docker管道&x27；s"；“内部”；不在Docker容器内运行的Jenkins slave中工作

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

安装程序

• Jenkins服务器在Docker容器中运行
• Jenkins slave基于Docker容器中运行的自定义映像（）
• 基于Docker:1.12-dind的Docker守护程序容器
• 从站是这样启动的：

  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映像，转而使用通用Docker slave中Docker管道插件提供的

  inside

  函数

问题 这是导致问题的典型构建步骤：

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

这将导致日志中出现如下错误：

sh:1:无法创建/workspace/repo_分支-K5EM5XEVEIPSV2SZZUR337V7FG4BZXHD4VORYFYISRWIO3N6U67Q@tmp/持久-98bb4c3d/pid:目录不存在

以前，此警告将显示：

71f4de289962-5790bfcc似乎在容器71F4DE28996233340C2AED4212248F1E73281FD7282A54A36CEEAC8C65EC0A内运行 但是在[]中找不到/workspace/repo_branch-K5EM5XEVEIPSV2SZZUR337V7FG4BZXHD4VORYFYISRWIO3N6U67Q

有趣的是，CloudBees的插件文档中描述了这个问题：

为了让inside工作，Docker服务器和Jenkins代理必须使用相同的文件系统，以便可以装载工作区。确保这一点的最简单方法是让Docker服务器在本地主机（与代理相同的计算机）上运行。目前，Jenkins插件和Docker CLI都不会自动检测服务器远程运行的情况；一个典型的症状是嵌套的sh命令出错，例如

无法创建/…@tmp/durable-…/pid:目录不存在 或负出口代码

当Jenkins能够检测到代理本身正在Docker容器内运行时，它会自动将--volumes from参数传递给内部容器，确保它可以与代理共享一个工作区

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

问题:

---

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

我已经看到了这个问题的变化，也看到了由

kubernetes插件提供动力的
代理的变化

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

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

这可能是通过
withArgs

问题是你为什么要这么做？大多数管道步骤都在master上执行，实际构建将在
build
容器中运行。还使用
代理的目的是什么？
是否可以运行ps aux并检查容器是否确实使用
--来自
的卷启动？此外，该标志将来也将被弃用。至少来自composet Docker管道插件记录向Docker发出的命令，但它不包含--volumes from标志。@Lunikon-请注意这是一个老问题。你还记得有没有达成过解决方案？相关-提供赏金。@Arceldon我们已经切换到GitLab来满足我们所有的CI/CD需求，我不确定我们在这样做之前是否或如何解决这个Docker问题。对不起，原因是我不想让詹金斯自己接触Docker。我想将该功能限制为代理。您实际上如何使代理与生成容器共享工作区？共享是使用卷实现的