大量的Docker卷

Question

有人可以帮我确认一下。

在具有swarm的docker中运行服务时，将使用本地驱动程序的docker卷与服务的运行容器位于同一节点上。

如果服务在两个不同的节点上生成任务，则每个容器将在各自的已装入卷中看到不同的数据。

例如，如果我有一个在创建/填充卷的node1上运行的服务，那么使用本地驱动程序创建卷时，该服务将永远仅对node1可见。

因此，如果我在node1上运行了一项服务，该服务会更新一个名为project-addons的卷。我在node2上生成了一个服务，它可以挂载项目附件卷，但它是空的。如果我想在任何地方正确填充项目附件。我必须在每个节点上运行一个任务，或者使用具有群集感知能力的卷驱动程序(例如在群集节点之间复制数据)。

因此，如果我的理解是正确的，则卷不是特定于群集节点的，可以从任何地方访问，但是如果卷驱动程序是本地的，则很有可能会挂载空的卷。

Answer 1

自从问这个问题的那一刻起，我就学到了很多，这是一个答案草案。
首先，了解什么是重要的。
卷是docker描述安装点的一种方式。创建卷后，它实际上不会物理安装在任何地方，直到容器需要它为止。
因此，如果您有一个docker swarm和多个节点，则在创建卷时，实质上，该卷的描述会在每个节点上复制，但是什么也没有发生。
容器启动时，它将尝试在正在启动的主机上装载一个卷。如果该卷实际上不存在，则将首次安装/创建该卷并在那里重新使用。因此，如果您使用的是本地驱动程序，它将实质上创建文件夹，仅此而已。
如果您有多个主机，则意味着每个主机将根据需要创建自己的文件夹。
因此，基本上可以通过至少四种方法来描述卷驱动器:

挂载

卸载

创建

删除

如果要设置群集感知驱动程序，则首先要定义一个插件，该插件将描述实现这4种方法的卷驱动程序。驱动程序被实现为与docker守护程序通信的http服务。驱动程序将收到操作，最终将例如创建或删除文件夹。
因此，在这一点上，您应该了解到，卷最终只能是挂载点。因此，可以挂载的任何东西都可以用作卷。
问题的思想是，即使您可以挂载网络驱动器，这也是一个非常愚蠢的过程，并且您唯一可以做的就是挂载某物。因此，除非您实现驱动程序以执行诸如在挂载之前创建远程挂载之类的时髦操作，否则您将不得不以其他方式进行操作。
让我们以Amazon EFS为例。您可以将其挂载为NFS驱动器，并且可以正常使用。但是，假设您要在不同服务之间共享NFS驱动器...如果将NFS驱动器的根目录挂载到卷中，则将无法做到这一点，因为根目录将在服务之间共享，并可能导致问题在不应该被容器看到的情况下。
我发现要实现的一种方法是使NFS驱动器的结构如下:

/根

/volumes/[volume_name]您要在服务

中挂载的卷

这是一种简化的定义方式，但总之可以这样进行。每个卷将属于共享网络驱动器的指定目录中的文件夹中。
但是，由于该过程非常愚蠢，因此不存在不存在的简单安装文件夹将失败，并且如果您安装了指向 /volumes/fun的卷，但 /volumes/fun不存在。运气不好， docker 不够聪明，默认情况下无法创建 /volumes/fun。这可以通过网络驱动程序来完成。
但幸运的是，有一种方法无需安装插件等就可以做到这一点。
在网络驱动器上实现卷创建的一种方法是拥有“看门狗”服务，该服务检查何时创建卷。该服务将挂载远程驱动器的/(NFS，SSHFS或任何无关紧要的东西，只要您具有写访问权即可)。
然后它将监听事件或轮询docker守护程序以获取卷。如果发现以某种方式标记的卷要装入正在监视的同一驱动器中。它会检查已安装的文件夹是否存在，如果不存在，则会创建它。
如果在创建文件夹之前启动了容器，则容器将无法正常工作，但是一旦远程驱动器看门狗创建了该文件夹，该服务将启动，就好像什么都没有发生一样。
最后，很可能无需借助各种奇怪的docker驱动程序卷插件实现就可以创建“大量”的卷。
最后，本地驱动程序只是一个安装点。重要的是找到一种挂载某种东西的方法，并且有一种方法来知道您尝试挂载的东西是否存在。您可以通过访问docker守护程序轻松创建它。
一种策略是在这样的卷上设置标签:

swarm.volume.source:源标签

swarm.volume.name:要挂载在/volumes/...中的文件夹的名称

这样，您就不必解析选项参数，并且可以直接使用已定义的标签，并且在定义了标签之后，就很容易知道您的看门狗实际上在乎哪个卷。
但是此时，它非常依赖于基础架构，因为您可以在创建卷的同时在/volumes上创建文件夹。
因此，说您需要群集感知驱动程序才能在docker swarm中拥有远程驱动器有点误导。没有“群居”的意识。所有卷都是“群居”的。最终得到您期望的结果。