了解卷的可用性

Question

我来自单片应用程序的旧世界，这些应用程序将其数据写入数据库，或者有时使用某些文件。通常，在使用文件时，它们存储在app目录的子目录中，例如app / data。

现在Docker中有了卷的概念。

我想了解：

1. 何时应使用卷？
2. 为什么将文件存储在卷中，而不是存储在app目录的子目录（如app / data）中？
3. 我是否需要更改应用程序代码以写入卷而不是写入应用程序/数据，或者一旦应用程序由Docker托管，则所有相对路径文件将自动保存在已安装的卷中？

Answer 1

启动mount a volume into a container时，您就是https://github.com/tensorflow/tfjs-converter。容器内的程序不知道是否正在使用卷。您从卷路径读取或写入的任何内容都会自动使用该卷。

如果可以选择，则应完全避免将数据存储在卷中。如果可以，请选择数据库。如果所有数据都在容器外部，则在多个主机上运行容器的多个副本非常容易。如果要在卷中存储一些数据，则在扩展应用程序时，您需要担心保留，复制和移动这些数据。

卷的良好用途包括存储需要在容器重新启动之间保留的本地持久性数据。主机绑定挂载极为相似（恕我直言，它们更易于管理，但在某些平台上存在权限和性能问题），也可以填补此用例；主机绑定挂载还可以用于将配置文件注入应用程序并读取日志文件。

（出于非Docker的原因，将数据存储在应用程序目录 eg /var/lib/myapp之外比较方便。这在Docker中不太重要，在Docker中，您可以通过构建新代码来更新代码映像，启动一个新容器，然后将卷挂载到文件系统中的某个位置。数据是否在应用程序目录下并不重要。）

---

您还用“ Kubernetes”标记了此名称。以上所有内容都适用于此处（当我说“按比例放大”时，我特别是在考虑Kubernetes）。与Docker命名卷相比，Kubernetes持久卷的使用可能会有些棘手;避免使用hostPath类型的卷（它们在多个节点之间不会保持一致）。您可能需要使用StatefulSets而不是Deployments来为每个Pod提供自己的PersistentVolume。直接访问PV内容比Docker更加困难。相反，对于某些任务（例如注入配置文件），还有其他机制（例如ConfigMaps）。远离试图将应用程序代码绑定到容器的面向开发人员的模式，这比仅在需要时重建映像要困难得多。

Answer 2

1. 您需要用于状态应用程序的卷，即用于持久存储数据/状态。

2. 您仍然可以使用app / data的相同路径，但是请确保该路径已安装在持久卷上，以便在容器消失时数据也可以持久存在。这样，您不必进行太多更改。

3. 否，如果将应用程序/数据作为卷挂载，则无需更改任何内容。该应用程序不需要了解这一点。只需确保应用程序/数据是卷即可。