具有命名或匿名卷的“数据容器” – 概念性问题？ （讨论）
a）匿名卷
使用数据容器时，可以使用这样的匿名卷
version '2' services: consumer: volume_from: - data-container:rw data-container: image: cogniteev/echo command: echo 'Data Container' volume: - /var/www b）名称卷
或者你可以像这样使用命名卷
version '2' services: consumer: volume_from: - data-container:rw data-container: image: cogniteev/echo command: echo 'Data Container' volume: - my-named-volume:/var/www volumes: my-named-volume: driver: local
我通常和b）一起去讨论/解释这两个概念问题/缺陷。 那么有什么优点和缺点。
我们可以比较他们的方面是/可以是：
- 可移植性
- 数据容器的可升级性（为什么我们要升级容器？）
- 开始/停止（继续）兼容性？
- 多堆栈问题？
- 效率（重用量）
关于这个问题的讨论，这个问题变得很激动https://stackoverflow.com/a/38984689/3625317
简短的回答：首选命名的数据卷，不再需要数据容器，所以你不应该使用任何新项目的卷。
您的命名卷的版本正在合并命名和数据容器，它应该是：
version '2' services: web: image: my-web-image volumes: - my-named-volume:/var/www volumes: my-named-volume: driver: local
通过合并这两个，你已经添加了一个额外的间接层到达你的命名卷，没有任何额外的好处。 命名卷是在1.9中创build的，以replace数据容器 ，这些数据容器本身是一种有点黑客的方法，以提供持久的数据。 命名卷比数据容器的优点包括：
- 您的数据pipe理与您的容器pipe理是分开的，您可以删除所有正在运行的容器，并仍然有可用的数据
- 数据可以使用卷驱动器存储在不同的位置，这意味着您可以将它放在nfs，分布式文件系统，甚至是本地永久目录
- 您可以以任何顺序启动和停止任何容器，而不依赖容器
- 第一次创build时，一个命名卷将接收它首次安装在其上的映像文件系统的副本，与数据容器的行为相同，这意味着它是一个无缝转换（请注意，这不是主机卷的行为，又名绑定安装）
另请参阅这个问题，也讨论命名卷VS数据容器和这个答案到另一个类似的问题。 我们也有一个我为之工作的公司的博客文章 。