docker - 带有命名卷或匿名卷的`data-container`-概念问题？ (讨论)

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

我们可以将它们进行比较的方面可能是:

可移植性

数据容器的

可升级性(为什么我们要升级容器？)

开始/停止(继续)兼容性？

多堆栈问题？

效率(卷的重用)

这个问题在关于这个问题的讨论中迅速发展。

最佳答案

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

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

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

 volumes:
   my-named-volume:
     driver: local

通过合并两者，您增加了一个额外的间接层来达到您的命名卷，而没有任何其他好处。命名卷是在replace data containers的1.9中创建的，它们本身是提供持久数据的一种被黑的方法。命名卷相对于数据容器的优势包括:

您的数据管理与容器管理是分开的，您可以删除所有正在运行的容器，并且仍然可以使用数据

可以使用卷驱动程序将数据存储在不同的位置，这意味着您可以将其放在nfs，分布式文件系统甚至本地持久目录

上

您可以以任何顺序启动和停止任何容器，而无需依赖容器之间的依赖关系

首次创建时，命名卷将收到它首先安装在其上的镜像文件系统的副本，与数据容器的行为相同，这意味着它是无缝过渡(请注意，这不是主机卷的行为) ，又名绑定(bind)安装)

另请参见this question that also discusses named volumes vs data containers和this answer，以解决另一个类似的问题。我也为我工作的公司提供了blog post on this。

关于docker - 带有命名卷或匿名卷的`data-container`-概念问题？ (讨论)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39013222/