21

我们可以在 docker engine swarm 模式下跨多个主机共享一个公共/单个命名卷，最简单的方法是什么？

4

3 回答 3

3

如果你有一个 NFS 服务器设置，你可以使用一些 nfs 文件夹作为来自 docker compose 的卷，如下所示：

volumes:
    grafana:
      driver: local
      driver_opts:
        type: nfs
        o: addr=192.168.xxx.xx,rw
        device: ":/PathOnServer"
于 2017-08-11T10:01:01.230 回答
1

在宏伟的计划中

其他答案肯定是正确的。如果您觉得您仍然缺少某些东西，或者得出的结论是，在这个领域可能永远不会真正改善，那么您可能需要重新考虑使用典型的类似 POSIX 的分层文件系统抽象。并非所有应用程序都真正需要它（我可能会说很少有人这样做）。也许你的也没有。

为文件系统辩护

它在许多圈子中仍然很常见，但通常这些人非常了解他们的远程/分布式文件系统，并且知道如何正确设置和利用它们（它们也可能是非常好的系统，尽管通常不使用现有的 Docker 卷驱动程序）。有时这也部分是因为它们只是被迫（不能或不应该重写的代码库以支持其他存储后端）。使用、配置甚至编写任意 Docker 卷驱动程序只是次要问题。

备择方案

但是，如果您有选择权，请为您的应用程序评估其他持久性解决方案。许多实现不会使用 POSIX 文件系统接口，而是使用网络接口，这在 Docker Swarm 等集群中没有特别的基础设施级别的困难。

由第三方（例如云提供商）管理的解决方案

如果您成功地为持久性和共享数据删除了对文件系统的所有依赖项（对于瞬态本地状态仍然可以），那么您可能会声称拥有完全“无状态”的应用程序。当然，通常总是在某个地方仍然存在状态，但想法是你自己不处理它。许多云供应商（如果你在那里托管东西）将提供完全托管的解决方案来处理持久状态，这样你就不必关心它了。如果您要走这条路，请考虑使用与您可以在本地用于测试的实现兼容的 API 的托管服务（例如，通过运行基于第三方提供的该实现的映像的 Docker 容器或你可以自己维护）。

DIY解决方案

如果您确实想在 Docker Swarm 集群中自己管理持久状态，那么文件系统抽象通常是不可避免的（而且您可能会更难直接针对块设备）。您将需要使用节点和服务约束来确保满足您用于持久化数据的任何要求。对于像中央 DBMS 服务器这样的某些事情，它可能很容易（“始终只在该特定节点上运行任务”），对于其他事情，它可能会涉及更多。

设置、扩展和监控此类设置的任务绝对不是微不足道的，这就是为什么许多应用程序开发人员乐于让其他人（例如云提供商）来做这件事的原因。然而，这仍然是一个非常酷的探索空间，尽管你不得不问这个问题，如果你在截止日期前，你可能不应该关注它。

结论

与往常一样，为工作使用正确的抽象，并停下来思考你的优势是什么以及将资源花在哪里。

于 2017-11-26T22:27:28.270 回答
0

从头开始，Docker 本身并不支持这一点。您必须使用其他组件，或者使用 docker 插件为您的卷提供新的层类型，或者直接在您的 FS 上使用同步工具来为您同步数据。

从我的角度来看，最简单的解决方案是rsync或更准确地说lsyncd是 rsync 的守护程序版本。但我从来没有尝试过它用于 docker 卷，所以我不知道它是否处理得很好。使用Infinit.sh提供其他解决方案。它基本上做同样的事情 lsyncd。这是一种单向同步。因此，如果您的 docker 容器的容量为 RW，它将不符合您的期望。我尝试了这个解决方案，它非常适合 RO 操作。而不是在生产中。它仍然是一个 alpha 版本。Infinit 也正在提供一个 docker 驱动程序。尚未公布。所以我什至没有尝试过。太冒险了。

我发现但无法安装（因此尝试）的其他解决方案是flocker和glusterFS。两者都旨在基于来自多台机器的多个 HDD 创建 FS Volume。但是在过去的几周里，他们的存储库都没有工作。

很抱歉只给你弱的解决方案，但我面临同样的问题，还没有找到一个完美的解决方案。

干杯，奥利维尔

于 2017-08-25T10:09:05.267 回答