具有命名卷或匿名卷的“数据容器”-概念问题？（讨论）

Question

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），并且想讨论/解释这两个概念上的问题/缺点。那么优点和缺点是什么。

我们可以将其进行比较的方面可能是：

1. 可移植性
2. 数据容器的可升级性（为什么我们要升级容器？）
3. 启动/停止（继续）兼容性？
4. 多栈问题？
5. 效率（卷的重用）

这个问题在这个问题上引起了讨论https://stackoverflow.com/a/38984689/3625317

Answer 1

简短的答案：命名数据卷是首选，不再需要数据容器，因此您永远不要volumes-from在任何新项目上使用。

您的命名卷版本正在合并一个命名容器和数据容器，它应该是：

version '2'
services:
  web:
    image: my-web-image
    volumes:
      - my-named-volume:/var/www

 volumes:
   my-named-volume:
     driver: local

通过合并两者，您增加了一个额外的间接层来达到您的命名卷，而没有任何其他好处。命名卷是在1.9版中创建的，用于替换数据容器，而数据容器本身就是提供持久性数据的一种骇人听闻的方法。命名卷相对于数据容器的优势包括：

• 您的数据管理与容器管理是分开的，您可以删除所有正在运行的容器，并且仍然可以使用数据
• 可以使用卷驱动程序将数据存储在不同的位置，这意味着您可以将其放在nfs，分布式文件系统甚至本地永久目录上
• 您可以按任何顺序启动和停止任何容器，而无需依赖容器
• 首次创建时，命名卷将收到它首先安装在其上的映像文件系统的副本，与数据容器的行为相同，这意味着它是无缝过渡（请注意，这不是主机卷的行为， aka绑定安装）

又见这个问题也讨论了名为卷VS数据容器和这个答案到另一个类似的问题。我们也为我工作的公司写了一篇博客文章。