当Dockerfile包含VOLUME指令（比如说）VOLUME [/opt/apache2/www, ...]时（希望这条路径存在于实际安装中），这意味着这条路径将被挂载到某个东西（对吗？）。而这个VOLUME指令是针对图像而不是针对它的一个实例（容器），而是针对每个实例。
无论图像是否包含定义的VOLUME，在启动容器时，run命令都可以通过将本地主机路径映射到容器路径来创建卷。
docker run --name understanding_volumes -v /localhost/path1:/opt/apache2/www -v /localhost/path2:/any/container/path image_name
以上内容应该清楚说明虽然/any/container/path未在Dockerfile中定义为VOLUME，但我们可以在运行容器时挂载它。
也就是说，这个SOF问题对它有所启发 - What is the purpose of defining VOLUME mount points within DockerFile rather than adhoc cmd-line -v?。这里提到了VOLUME指令的一个好处。也就是说，其他容器可以从中受益。使用--from-container（找不到docker run --help的此选项，不确定答案是否意味着--volumes-from）无论如何因此安装点可以某种自动方式访问其他容器。大。
我的第一个问题是，安装在容器上的其他卷路径/any/container/path image_name understanding_volumes 也可以使用--from-container或--volumes-from（第二个容器）使用（哪个选项是正确的）？
我的下一个问题是，使用VOLUME指令只是为了让其他容器链接到这条路径 - ＆gt;这是通过简单的链接使/opt/apache2/www上的数据可用于其他容器。所以它只是分享。或者是否有任何数据也可以提供给第一个容器。
答案 0 :(得分：7)
在Dockerfile中定义卷的优点是可以将图像定义中的卷位置指定为从图像创建者到图像用户的文档。这只是唯一的好处。
它很早就被添加到了docker中，很可能当数据容器是持久化数据的唯一方法时。我们现在有一个已废弃数据容器的命名卷的解决方案。我们还添加了compose文件，以易于理解和重用的语法定义容器的运行方式。
虽然自我记录图像有一个好处，但有很多缺点，我强烈建议不要在我的客户和任何发布图像的人中为图像内部定义 一般重用：
在最终用户处强制音量，无法取消图像中的音量。
如果未在运行时定义卷（使用-v或撰写文件），则用户将在其docker volume ls中看到与创建它们的内容无关的匿名卷。这些几乎总是无用的磁盘空间浪费。
它们破坏了扩展图像的能力，因为在VOLUME行之后对图像中的卷的任何更改通常都被docker忽略。这意味着用户永远不能添加他们自己的初始卷数据，这非常令人困惑，因为docker没有在图像构建期间忽略用户更改的警告。
如果您需要将卷作为用户运行时，您始终可以使用-v或compose文件对其进行定义，即使该数据库未在Dockerfile中定义也是如此。许多用户误以为您必须在映像中定义它才能在运行时使其成为命名卷。
使用--volumes-from的功能不受图像中定义音量的影响，但我建议您避免使用此功能。它在群集模式下不存在，您可以通过使用安装在两个容器中的命名卷来获得所有相同的功能以及更多粒度。