docker数据卷有什么优点和缺点？
我正在查看在容器中pipe理数据。 在Docker中有两种pipe理数据的方法。
- 数据量和
- 数据容量容器
https://docs.docker.com/userguide/dockervolumes/
我的问题是：这两种方法的优缺点是什么？
谢谢！
基本上有三种方法可以在一个容器中pipe理数据，最好概述并提供一些具体的案例，说明何时以及为什么要使用这些数据。
首先，您可以select使用联盟文件系统 。 运行的每个容器都有一个由UFS提供的相关可写层，所以如果我根据自己select的映像运行一个容器，那么当容器运行时，我在该会话期间执行的写操作可以被提交回映像并通过手段持久化他们永远与图像的构build相关联。 所以，如果你有一个Debian镜像，并执行apt-get update && apt-get install -y python ，你可以将其提交回镜像，与其他人共享，并为每个人节省执行所有这些多个networking所需的时间请求使用Python安装最新的容器。
其次，你可以使用卷。 当容器运行时，写入作为卷的目标的目录与UFS区别开来，并保持与容器关联。 只要相关的容器存在，容量也一样。 假设你有一个容器，它的入口点是一个在/var/logs/myapp生成日志的进程。 如果没有卷，那么由进程写入的数据可能会无意中被提交回映像，不必要的增加它的大小。 相反，只要容器存在，如果进程崩溃并将容器放下，则可以访问日志并检查发生了什么。 通过这种非常自然的方式，存储在与这些容器相关联的卷中的数据是暂时的 – 丢弃该容器并且由该过程生成的数据消失。 如果容器的映像被更新，并且您的映像已经更新，或者您不再需要生成的日志，则可以简单地删除并重新创build容器，并有效地将生成的日志从磁盘清理。
虽然这看起来不错，但数据库写的数据会发生什么情况呢？ 当然，这不是UFS的一部分，但是如果你更新数据库镜像，或者从foo/postgresql切换到bar/postgresql并且最终得到一个新的容器，你不能简单地刷新它每个案例。 很明显，这是不可接受的，这也是第三种select的出发点，即拥有一个持久的命名容器和相关的容器，并利用容量的全部function，例如能够与其他容器共享容器，即使相关联的容器不是“实际上运行。 有了这个模式，你可以有一个dbdata容器，把/var/lib/postgresql/dataconfiguration成一个卷。 然后，您可以可靠地拥有临时数据库容器，并在不丢失重要数据的情况下轻松删除并重新创build它们。
那么，回顾一下关于卷的一些事实：
- 卷与容器相关联
- 写入卷目录直接写入卷本身，绕过UFS
- 这使得可以跨多个容器独立共享卷
- 当最后一个关联的容器被移除时，卷将被销毁
- 如果您不想在删除瞬时容器时丢失存储在卷中的重要数据，请将该卷与永久的命名容器相关联，并与非持久容器共享以保留数据
那么，作为一般的经验法则：
- 您希望成为每个容器环境的永久function的数据应写入UFS并提交给映像
- 通过容器的被pipe理进程生成的数据应该写入一个卷
- 如果你删除一个容器，写入到你不想意外丢失的卷的数据应该与你打算保留的一个已命名的容器相关联，然后与其他可以安全移除的临时容器共享
我不会认为他们是不同的方法。
卷是绕过联盟文件系统的机制，从而允许数据容易与其他容器和主机共享。 数据容器只是简单地包装一个或多个卷来提供一个方便的名称，您可以在--volumes-from语句中使用它来在容器之间共享数据。 您不能拥有没有数据卷的数据容器。
数据容器提供：
- 一个明智的抽象层为您的存储。 构成您的卷的文件由Docker存储和pipe理。
- 数据容器非常方便使用特殊的“–volumes – from”指令进行共享。
- 数据通过删除数据容器自动清理。
- 像Flocker这样的项目演示了如何最终与容器相关的存储将在Docker主机之间共享。
- 可以使用“docker cp”命令将文件从容器中移出到主机上。
数据卷映射提供：
- 更容易理解
- 显式直接控制数据的存储位置。
- 我遇到过文件所有权和许可问题。 例如，在容器内以root用户身份运行的Docker进程在文件系统上创build由root用户拥有的文件。 （是的，我知道数据卷以相同的方式存储他们的数据，但使用“docker cp”命令提取我拥有的文件:-)）
总之，我认为这真的归结为您希望在底层存储上施加多less控制。 就我个人而言，我喜欢Docker提供的抽象和间接性，因为我喜欢端口映射。