如何在Docker引擎群模式下跨多个主机共享卷？
我们可以在Docker引擎群模式下跨多个主机共享一个共同/单个命名卷，那么最简单的方法是什么？
如果你有一个NFS服务器设置，你可以使用一些nfs文件夹作为来自docker的音量，就像这样：
volumes: grafana: driver: local driver_opts: type: nfs o: addr=192.168.xxx.xx,rw device: ":/PathOnServer" 从头开始，Docker本身不支持这个。 您必须使用额外的组件，或者为您的卷提供新的图层types的docker插件，或者直接在您的FS上同步数据的同步工具。
从我的angular度来看，最简单的解决scheme是在rsync的守护进程版本中使用rsync或更准确地lsyncd rsync。 但我从来没有尝试过docker卷，所以我不知道它是否处理好。 其他解决scheme使用Infinit.sh提供。 它基本上和lsyncd一样。 这是一个单向同步。 所以，如果您的docker集装箱的RW容量不符合您的期望。 我尝试了这个解决scheme，它对于RO操作来说工作得非常好。 而不是在生产。 这仍然是一个alpha版本。 Infinit也在提供Docker驱动程序。 尚未公布。 所以我甚至没有尝试过。 风险太大。
我发现其他的解决scheme，但无法安装（以尝试）是flocker和glusterFS。 两者都旨在基于几台机器上的多个硬盘来创buildFS卷。 但是他们的仓库在过去几周都没有工作。
对不起，只给你弱解决scheme，但我面临同样的问题，还没有find一个完美的解决scheme。
干杯，奥利维尔
在事物的macros伟计划
其他答案是绝对正确的。 如果您觉得自己仍然错过了一些东西，或者得出这样的结论：在这个领域，事情可能永远不会真正改善，那么您可能需要重新考虑使用典型的类POSIX分层文件系统抽象。 并不是所有的应用程序真的需要它（我可能会说甚less）。 也许你也不会。
保护文件系统
这在很多圈子里仍然很常见，但是通常这些人很了解他们的远程/分布式文件系统，知道如何设置并正确利用它们（而且它们也可能是非常好的系统，尽pipe经常不会与现有的Docker卷驱动程序）。 有时也是因为他们被迫（代码库不能或不应该被重写来支持其他存储后端）。 使用，configuration甚至写任意的Docker卷驱动程序只是次要的问题。
备择scheme
如果您有select，然后评估您的应用程序的其他持久性解决scheme。 许多实现不会使用POSIX文件系统接口，而是使用networking接口，这不会在Docker Swarm等集群中造成特定的基础设施级别的困难。
由第三方pipe理的解决scheme（例如云提供商）
如果你能成功移除文件系统的永久和共享数据的依赖关系（对于瞬态本地状态它仍然可以），那么你可能声称拥有完全“无状态”的应用程序。 当然，国家经常总是坚持到某个地方，但是这个想法是你自己不去处理。 许多云提供商（如果这是您的东西托pipe）将提供完全托pipe的解决scheme来处理持久状态，使您根本不必关心它。 如果你要走这条路线，不妨考虑一下使用API的pipe理服务，这些API可以在本地进行testing（例如，通过运行一个基于第三方提供的实现的映像的Docker容器，或者你可以保持自己）。
DIY解决scheme
如果你想在Docker Swarm集群中自己pipe理持久状态，那么文件系统的抽象往往是不可避免的（无论如何，你可能会遇到更多难以定位块设备的困难）。 您将需要使用节点和服务约束，以确保您所使用的任何要求保持数据的满足。 对于某些中央数据库pipe理系统服务器来说，这可能很简单（“总是只在该特定节点上运行任务”），对于其他人来说，这可能更为复杂。
设置，扩展和监控这样一个设置的任务绝非是微不足道的，这就是为什么许多应用程序开发人员乐于让其他人（如云提供商）来做这件事的原因。 尽pipe如此，这仍然是一个非常酷的空间，但是由于你必须提出这个问题，如果你在最后期限之内，你可能不应该关注这个问题。
结论
像往常一样，使用正确的抽象工作，并暂停思考你的优点是什么以及在哪里花费你的资源。