Docker 手动创建的NFS卷装载但显示空内容

服务器：

docker ubuntu，18.06.3-ce

本地：

docker for mac，2013年3月19日

我已经在swarm中手动创建了一个卷，连接到远程nfs服务器。当我尝试在服务中装载此卷时，它似乎可以工作，但内容是空的，任何写入操作似乎都会成功（调用代码不会崩溃），但字节消失了。甚至可能到/dev/null

当我在compose文件中声明一个类似的卷时，它就工作了。我能找到的唯一区别是标签“com.docker.stack.namespace”

检查网络时，除该标签外，它们是相同的

{
    "CreatedAt": "2020-20-20T20:20:20Z",
    "Driver": "local",
    "Labels": {
        # label missing on the manually created one
        "com.docker.stack.namespace": "stackie"
    },
    "Mountpoint": "/var/lib/docker/volumes/externl_nfs/_data",
    "Name": "compose_nfs",
    "Options": {
        "device": ":/data/",
        "o": "addr=10.0.1.100",
        "type": "nfs"
    },
    "Scope": "local"
}

---

回答这个问题，因为它是docker的旧版本，考虑到NFS部分，可能与大多数人无关

这似乎是docker/swarm中的某种缺陷

在swarm上创建NFS卷（通过api，从远程）

已联系的manager节点上的卷正确

卷缺少所有其他工作节点上的

选项

由于一些奇怪的副作用，音量似乎起作用。它可以挂载，写入成功而不会出现问题，但写入的所有字节都会消失。读取工作正常，但每个文件都“未找到”，考虑到写入正在消失，这是合乎逻辑的

关于经理：

> docker network inspect external_nfs
[{
    "CreatedAt": "2020-11-03T15:56:44+01:00",
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/externl_nfs/_data",
    "Name": "externl_nfs",
    "Options": {
        "device": ":/data/",
        "o": "addr=10.0.1.100",
        "type": "nfs"
    },
    "Scope": "local"
}]

关于工人：

> docker network inspect external_nfs
[{
    "CreatedAt": "2020-11-03T16:22:16+01:00",
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/externl_nfs/_data",
    "Name": "externl_nfs",
    "Options": null,
    "Scope": "local"
}]

---

如果您使用外部卷，swarm会将该卷的创建延迟给您。卷也是在其上创建的节点的本地卷，因此您必须在swarm可以安排此作业的每个节点上创建该卷。出于这个原因，许多人会将卷创建委托给swarm模式本身，并将定义放入compose文件中。因此，在您的示例中，在安排服务之前，在每个节点上运行：

---

否则，当在未定义卷的节点上调度服务时，swarm将创建容器，并且create命令生成一个默认命名卷，将内容存储在该本地节点上（我也可以看到swarm由于缺少卷而无法调度服务，但您的示例显示了其他情况）.

该卷是否存在于计划任务的同一节点上？显示该节点上docker volume inspect externl\u nfs的输出。他妈的好点。这些卷存在于容器引用它们的所有主机上，但我只在manager上执行了

inspect

。在workers上，“选项”节点为空

{“Driver”：“local”，“Name”：“some_other_nfs”，“Options”：null，“Scope”：“local”，…}

我创建了一个新卷，并使用一个虚拟容器来测试它，它当然是可重复的。看起来像是swarm创建的卷，我以为问题是关于使用外部定义的卷？你说得对！我把问题贴出来了。我只是复制了以前的输出，没有注意。我对它进行了编辑，以反映它的实际外观（谢天谢地，我仍然有一个挂在周围），它看起来不像您在更新的输出中使用NFS选项在worker上创建了外部卷。时间戳是如何相同的也令人困惑，您是用脚本创建这些卷的吗？请记住，外部卷不是通过swarm模式或compose创建的，因此这将是一个关于如何在该worker上创建卷的问题。同样，这只是一个示例。我输入了假日期，我认为重复的

20

会有所帮助。此外，如果有帮助的话，这个名称实际上不是“external_nfs”，而是一个特定于产品的名称。当远程连接到该群集时，我使用

docker volume create…

。该卷应该显示在工作人员引用它的任何位置，而且它确实显示在任何位置（碰巧是所有节点）。为了提供帮助，我输入了实际日期，并验证了其余内容（外部名称）是否相同。此外，IP不是真正的IP（但在相同的一般范围内）。请注意，日期的差异在于网络创建和堆栈部署时间。感谢您的帮助！所以swarm不会因为外部卷不存在而失败，它只是创建了一个具有该名称的卷。和我想象的完全不同。它有一半的效果：D也许“不崩溃”的情况在更新的版本上得到了修复。正因为如此，我移动了这样的卷，每个stack.yml重新声明一个相同的nsf卷。保持同步和重复检查很糟糕，但它很有效：）如果swarm有办法管理集群中的卷，那就太好了，但我想这其中有相当多的逻辑问题。此外，“许多人将把卷创建委托给swarm”这句话在第三次阅读时对我来说是有意义的，而不是像你这样的专家马上就可以理解。不过，我不知道如何更好地使用它，也许“大多数人会将定义放在撰写文件中，但如果您想自己使用，则需要在每个节点上手动创建定义”。：耸耸肩：再次感谢，很高兴能解释得这么好！

> docker network inspect external_nfs
[{
    "CreatedAt": "2020-11-03T15:56:44+01:00",
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/externl_nfs/_data",
    "Name": "externl_nfs",
    "Options": {
        "device": ":/data/",
        "o": "addr=10.0.1.100",
        "type": "nfs"
    },
    "Scope": "local"
}]

> docker network inspect external_nfs
[{
    "CreatedAt": "2020-11-03T16:22:16+01:00",
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/externl_nfs/_data",
    "Name": "externl_nfs",
    "Options": null,
    "Scope": "local"
}]

docker volume create --driver local \
    --opt type=nfs \
    --opt o=addr=10.0.1.100 \
    --opt device=:/data/ \
    external_nfs