为什么Docker（Dind）容器中的Docker使用主机路径装载卷？ [英] Why docker in docker (dind) containers mount volumes with host path?

问题描述

我在docker中安装了docker，并尝试安装文件夹。

I have a setup with docker in docker and try to mount folders.

假设我有一些要与他的父母共享的文件夹。在主机上，我在/ tmp / dind中创建了一个名为 foo 的文件。主机启动容器1，容器1启动容器2。这就是我想要的结果。

Let's say I have those folders that I wish to share with his parent. On the host, I created a file in /tmp/dind called foo. Host starts container 1, which starts container 2. This is the result I want to have.

Host      | Container 1 | Container 2

/tmp/dind |  /tmp/dind2 | /tmp/dind3
      <------->     <------->

相反，我得到

Host      | Container 1 | Container 2

/tmp/dind |  /tmp/dind2 | /tmp/dind3
      <------->
      <----------------------->

此处的代码：

docker run --rm -it \
  -v /tmp/dind:/tmp/dind2 \
  -v /var/run/docker.sock:/var/run/docker.sock docker sh -c \
    "docker run --rm -it \
      -v /tmp/dind2:/tmp/dind3 \
      -v /var/run/docker.sock:/var/run/docker.sock \
      docker ls /tmp/dind3"

此命令不输出任何内容，而下一条命令给出的结果为foo。我更改了挂载的卷：

This outputs nothing, while the next command gives foo as result. I changed the mounted volume:

docker run --rm -it \
  -v /tmp/dind:/tmp/dind2 \
  -v /var/run/docker.sock:/var/run/docker.sock docker sh -c \
    "docker run --rm -it \
      -v /tmp/dind:/tmp/dind3 \
      -v /var/run/docker.sock:/var/run/docker.sock \
      docker ls /tmp/dind3"

问题是，我需要做什么才能使用Container 1路径而不是主办？还是我对这里的Docker误解了？

The question is, what do I need to do in order to use Container 1 path and not host? Or do I misunderstand something about docker here?

推荐答案

对于您所说的 Docker-in-Docker和 dind ，此设置实际上不是Docker-in-Docker：您的container1正在向影响容器2的主机Docker守护进程提供指令。

For all that you say "Docker-in-Docker" and "dind", this setup isn’t actually Docker-in-Docker: your container1 is giving instructions to the host’s Docker daemon that affect container2.

Host      Container1
    /-----
 (Docker)
    |     Container2
    \---->

（注意：此通常是用于CI类型设置的推荐路径通常， Docker-in-Docker表示container1正在运行自己的单独的Docker守护进程，通常不建议这样做。）

(NB: this is generally the recommended path for CI-type setups. "Docker-in-Docker" generally means container1 is running its own, separate, Docker daemon, which tends to not be recommended.)

因为container1正在向主机的Docker，以及主机的Docker正在启动container2，任何 docker run -v 路径始终是主机的路径。除非您知道某个特定的目录已经安装到您的容器中，否则很难与子容器共享文件。

Since container1 is giving instructions to the host’s Docker, and the host’s Docker is launching container2, any docker run -v paths are always the host’s paths. Unless you know that some specific directory has already been mounted into your container, it’s hard to share files with "sub-containers".

一种解决此问题的方法是：断言存在某种共享路径：

One way to get around this is to assert that there is a shared path of some sort:

docker run \
  -v $PWD/exchange:/exchange \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e EXCHANGE_PATH=$PWD/exchange \
  --name container1
  ...

# from within container1
mkdir $EXCHANGE_PATH/container2
echo hello world > $EXCHANGE_PATH/container2/file.txt
docker run \
  -v $EXCHANGE_PATH/container2:/data
  --name container2
  ...

过去，当我这样做时（对于想要启动辅助容器的测试设置），我花了很多心血。 docker create ， docker cp ， docker start ， docker cp ， Docker rm 序列。这是非常手动的操作，但是它具有的优点是，即使您正在与主机的Docker守护进程进行通讯， docker cp 的本地端始终是当前文件系统上下文。在一个容器中。

When I’ve done this in the past (for a test setup that wanted to launch helper containers) I’ve used a painstaking docker create, docker cp, docker start, docker cp, Docker rm sequence. That’s extremely manual, but it has the advantage that the "local" side of a docker cp is always the current filesystem context even if you’re talking to the host’s Docker daemon from within a container.

这篇关于为什么Docker（Dind）容器中的Docker使用主机路径装载卷？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！