Question

我有一个容器，其中包含用于协调主机上微服务部署的逻辑-让我们将此服务称为 deployer 。为此，我已经将主机上的/var/run/docker.sock文件安装到该 deployer 容器中。

因此，在 deployer 容器中执行docker run hello-world时， host 会运行它。该系统按预期运行，除了我现在不确定一件事，因为我已经看到一些意外的行为。

执行docker run -v "/path/to/src:/path/to/dest" hello-world时，Docker将查找哪个文件夹？我看到了两个有效的理由：

A）它将从{em> deployer 内将/path/to/src挂载到 hello-world容器，因为那是执行命令。
B）它会将/path/to/src从 source 挂载到 hello-world容器，因为docker.sock确定了上下文并且该命令正在主机上运行。

其中哪些是正确的？此外，在使用相对路径（例如docker-compose）时，将使用什么路径？

预先感谢

Answer 1

它将始终使用主机文件系统。无法将一个容器的文件系统直接挂载到另一个文件系统。

例如：

host$ sudo docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock docker sh
0123456789ab# docker run -v /:/host --rm -it busybox sh
13579bdf0246# cat /host/etc/shadow

最后一条命令将打印出主机的加密密码文件，而不是中间容器中的任何内容。

如果从示例中不能明显看出，将Docker套接字安装为以编程方式运行Docker命令会带来巨大的安全隐患，因此您应仔细考虑这是否真的是一种好方法。

我敢肯定docker-compose.yml中的相对路径在此设置下实际上不会起作用（因为您无法将内容绑定安装到中间容器之外）。您必须将相同的内容装载到两个容器中，一个容器才能将文件发送到另一个容器。在这里使用命名卷可能会有所帮助（因为卷名实际上并不取决于主机路径）；根据您的实际操作，可以使用docker create然后是docker cp的回旋路径。

在实现级别上，只有一个Docker守护程序，它在主机上运行。您可以将其套接字发布到各个位置，但最终该守护程序会接收到诸如“创建一个安装主机目录/ x / y的容器”之类的请求，并且该守护程序会在主机上下文中解释这些请求。它不知道请求来自其他容器（或可能是其他主机；但是请参阅上面的安全性问题）。

将/var/run/docker.sock挂载到容器中时，哪个文件系统用于卷挂载？

1 个答案: