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