从我的角度来看，最简单的解决方案是 rsync 或更准确地说是rsync的守护进程版本 . 但是我从未尝试过它用于码头工作量，所以我不知道它是否处理得很好 . 使用Infinit.sh提供其他解决方案 . 它基本上与 lsyncd 做同样的事情 . 它's a one way sync. So if your docker container are RW in their volumes it won' t符合您的期望 . 我试过这个解决方案，它对RO操作非常有效 . 而不是 生产环境 . 它甚至尝试过它 . 太冒险了 .
3 回答
如果你有一个NFS服务器设置，你可以使用一些nfs文件夹作为来自docker的卷组成如下：
从头开始，Docker本身并不支持这一点 . 您必须使用其他组件，即可以为您的卷提供新图层类型的docker插件，或者直接在FS上为您同步数据的同步工具 .
从我的角度来看，最简单的解决方案是
rsync或更准确地说是rsync的守护进程版本 . 但是我从未尝试过它用于码头工作量，所以我不知道它是否处理得很好 . 使用Infinit.sh提供其他解决方案 . 它基本上与lsyncd做同样的事情 . 它's a one way sync. So if your docker container are RW in their volumes it won' t符合您的期望 . 我试过这个解决方案，它对RO操作非常有效 . 而不是 生产环境 . 它甚至尝试过它 . 太冒险了 .我发现但无法安装（以及尝试）的其他解决方案是flocker和glusterFS . 两者都是基于多台机器上的几个硬盘创建FS卷 . 但过去几周他们的存储库都没有工作 .
很抱歉只给你很弱的解决方案，但我遇到了同样的问题，还没有找到一个完美的解决方案 .
干杯，奥利维尔
在宏伟的计划中
其他答案肯定是正确的 . 如果您觉得自己仍然缺少某些东西或者得出的结论是在这个领域可能永远无法改进，那么您可能需要重新考虑使用典型的POSIX类分层文件系统抽象 . 并非所有应用程序都需要它（我可能会说很少有人这么做） . 也许你的也不是 .
为文件系统辩护
它在许多圈子中仍然非常普遍，但通常这些人非常了解他们的远程/分布式文件系统并且知道如何设置它们并正确利用它们（并且它们也可能是非常好的系统，尽管通常不使用现有的Docker卷驱动程序） ） . 有时它也部分是因为它们只是被迫（代码库不能或不应该被重写以支持其他存储后端） . 使用，配置甚至编写任意Docker卷驱动程序只是次要问题 .
替代品
但是，如果您有选项，则为您的应用程序评估其他持久性解决方案 . 许多实现不会使用POSIX文件系统接口，而是使用网络接口，这在Docker Swarm等集群中不会造成特定的基础架构级别的困难 .
由第三方管理的解决方案（例如 Cloud 提供商）
如果您成功删除了文件系统的所有依赖关系以获取持久性和共享数据（它仍适用于 transient 本地状态），那么您可能声称拥有完整的"stateless"应用程序 . 当然，在某个地方经常会出现持续存在的状态，但这个想法是，你根本不需要关心它 . 如果您要使用此路由，请考虑使用与本地可用于测试的实现兼容的API的托管服务（例如，通过基于第三方提供的实现的映像运行Docker容器或你可以保持自己） .
DIY解决方案
如果你确实想在Docker Swarm集群中自己管理持久状态，那么文件系统抽象通常是不可避免的（并且你可能在直接针对块设备时遇到更多困难） . 您将需要使用节点和服务约束来确保满足您用于保存数据的任何要求 . 对于像中央DBMS服务器这样的某些事情，它可能很容易（“总是只在特定节点上运行任务”），对于其他人来说，它可能更容易参与 .
设置，扩展和监视这样的设置的任务绝对不是微不足道的，这就是为什么许多应用程序开发人员乐于让其他人（例如 Cloud 提供商）这样做的原因 . 然而，它仍然是一个非常酷的探索空间，但是如果你不得不提出这个问题，那么如果你在截止日期前，你可能不应该关注这个问题 .
结论
一如既往，为工作使用正确的抽象，并停下来思考你的优势是什么以及在哪里花费你的资源 .