带有命名或匿名卷的`data-container` - 概念问题？ （讨论）

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到replace data containers中创建的，它们本身就是一种提供持久数据的有点黑客攻击的方法。命名卷对数据容器的优点包括：

• 您的数据管理与容器管理是分开的，您可以删除所有正在运行的容器，但仍然可以提供数据
• 使用卷驱动程序可以将数据存储在不同的位置，这意味着您可以将其放在nfs，分布式文件系统甚至本地持久目录上
• 您可以按任何顺序启动和停止任何容器，而不会在容器之间存在依赖关系
• 首次创建时，命名卷将接收首先挂载的图像文件系统的副本，与数据容器的行为相同，这意味着它是无缝转换（请注意，这不是一个行为）主机卷，又名绑定安装）

另请参阅this question that also discusses named volumes vs data containers和this answer其他类似问题。我工作的公司也有blog post on this。