我想将持久存储附加到我的 Docker 容器。我尝试过使用 TrueNAS 的 NFS，但似乎没有成功。
当然，我的做法是错误的。将持久存储附加到容器外部的常见惯例是什么，这样如果容器发生故障或重建，数据就会重新附加或至少仍然存在。
编辑：抱歉造成混淆。我不是在谈论绑定挂载或卷，我很清楚这些技术。我指的是底层文件系统，即 NFS 等。是否有标准工具或管理系统，例如用于 Kubernetes 上块存储的 Longhorn。是使用文件、对象还是块存储解决方案等更好...
编辑 2：我已经准备好了 Docker 文档中的所有内容。我了解卷和驱动程序。我不知道如何正确使用它们以及相应的选项，因为它们没有正确记录，或者这些东西通常如何安装到解决方案中。是的，我可以“使用驱动程序”，但具体怎么做呢？NFS 是一个常见主题吗？块存储呢？对象存储？这在系统级别上是如何架构的。
编辑：我之所以添加此编辑，是因为有些狡猾的人关闭了它，因为它不够具体。好像问这个问题不相关。我是唯一一个有实际答案的人。即使是 docker 的普通用户也不知道这一切在幕后是如何运作的。你不认为我们应该就这个问题发表一篇文章吗？哦，不，当然不应该……只是让人们一遍又一遍地重复同样的事情。
答案1
在容器外部附加持久存储的常见约定是什么
没有。
整个 Docker 范式都基于这样的假设：您可以随意创建和销毁容器。容器不是持久性的，也不应该是持久性的。
如果你的容器期望有东西存在，你做错了™。
答案2
就底层文件系统技术而言，惯例似乎是使用块存储解决方案，例如 Cinder、BGFS 等（可以使用 Ceph、iSCSI 和其他块文件类型）或对象存储，例如 Minio
这些类型的解决方案有助于轻松管理底层磁盘空间，同时也考虑到分布式文件系统的隐性需求。
这确实取决于用例，NFS 非常适合性能不是问题用例，例如写入文件。这样，wikijs 容器将成为 NFS 的完美候选者，这样写入用户生成的内容就可以与容器分开。
块存储解决方案对容器的另一个好处是，能够在快速的创建-销毁周期中轻松部署。这是典型的用例。
再说一次，如果你正在运行大量具有无限生命周期的容器（就像我使用 Nextcloud、Heimdall、pihole 等...），那么块存储解决方案也可能为你提供更灵活的安排。我喜欢在这种情况下使用块存储的想法，因为磁盘和文件系统由应用程序/容器处理，而不是依赖于外部因素。这可能是也可能不是一个现实世界的问题，但我可以想象由于这些原因或更具体地说：块存储解决方案的妥协较少，NFS 可能会出现潜在问题。
最后，我需要确认的是，跟踪与每个容器关联的卷本身就是一项任务。这些块存储解决方案可能提供一种简洁且易于管理的方法来跟踪备份和恢复的创建-销毁周期。