问码头数据卷的优缺点是什么？

EN

基本上可以有三种方法来管理容器中的数据，也许最好的方法是概述并提供一些逐例的例子，说明何时和为什么使用这些方法。

首先，您可以选择使用联合文件系统。每个运行的容器都有一个由UFS提供的相关的可写层，因此如果我基于我的选择映像运行一个容器，那么我在该会话期间执行的写操作(当容器运行时)可以提交回映像并持久化，方法是它们与图像的构建永久关联。因此，如果您有一个Debian映像并执行apt-get update && apt-get install -y python，您就有可能将其提交回该映像，与其他人共享它，并为每个人节省执行所有这些多个网络请求所需的时间，以便拥有一个带有Python预安装的最新容器。

其次，您可以使用卷。当容器运行时，将写入以卷为目标的目录，以保持UFS的独特性，并保持与容器的关联。只要关联容器存在，卷也存在。假设您有一个容器，它的入口点是一个在/var/logs/myapp上生成日志的进程。如果没有卷，进程编写的数据可能会在不经意间被提交回映像，不必要地增加图像的大小。相反，只要容器存在，如果进程崩溃并关闭容器，您就可以访问日志并检查所发生的事情。从本质上说，存储在与此类容器相关的卷中的数据是短暂的--丢弃容器，进程生成的数据就消失了。如果容器的映像被更新，并且您处理了一个新的映像，或者您不再需要生成的日志，那么您可以简单地删除和重新创建容器，并有效地从磁盘中刷新生成的日志。

虽然这看起来很棒，但是用数据库编写的数据会发生什么呢？当然，它不是作为UFS的一部分而保留的，但是如果您更新DB映像或从foo/postgresql切换到bar/postgresql，并且在每种情况下都有一个新的容器，您就不能简单地让它刷新。显然，这是不可接受的，这也是第三种选择，即拥有一个具有关联卷的持久性命名容器，并充分利用卷功能的范围，例如能够与其他容器共享它们，即使关联容器没有实际运行。使用此模式，您可以拥有一个dbdata容器，并将/var/lib/postgresql/data配置为卷。然后，您可以可靠地拥有临时数据库容器，并在不丢失重要数据的情况下轻松地删除和重新创建它们。

因此，简要介绍一下有关卷的一些事实：

• 卷与容器相关联。
• 写入卷目录直接写入卷本身，绕过UFS
• 这样就可以在多个容器之间独立地共享卷。
• 当移除最后一个关联容器时，卷将被销毁。
• 如果您不希望在移除瞬态容器时丢失存储在卷中的重要数据，请将卷与永久的命名容器关联起来，并与非持久化容器共享以保留数据。

然后，作为一般的经验法则：

• 您希望成为每个容器环境的永久特性的数据应该写入UFS并提交到映像中。
• 由容器的托管过程生成的数据应该写入卷
• 如果删除容器，写入卷时不希望意外丢失的数据应该与您打算保存的命名容器相关联，然后与其他可以安全删除的临时容器共享。

我不认为它们是不同的方法。

卷是绕过Union文件系统的机制，从而允许与其他容器和主机轻松地共享数据。数据-容器只需包装一个卷(或多个卷)，以提供一个方便的名称，您可以在--volumes-from语句中使用它在容器之间共享数据。没有数据卷就不能有数据容器。

数据容器提供：

1. 为您的存储提供合理的抽象层。组成卷的文件由Docker为您存储和管理。
2. 使用特殊的“卷”指令共享数据容器非常方便。
3. 删除数据容器将自动清除数据。
4. 类似于絮凝器的项目演示了与容器关联的存储最终将如何在docker主机之间共享。
5. 可以使用"docker“命令将文件从容器中拖出主机。

数据卷映射提供：

1. 简单易懂
2. 对数据存储位置的显式和直接控制。
3. 我经历过文件所有权和权限问题。例如，Docker进程作为根进程在容器中运行，在文件系统上创建根用户拥有的文件。(是的，我知道数据卷以同样的方式存储数据，但是使用"docker“命令可以提取我拥有的文件：-)

总之，我认为这实际上取决于您希望对底层存储施加多大的控制。就我个人而言，我喜欢Docker提供的抽象和间接，因为我喜欢端口映射。