Dockerfile 命令“Volume”的目的是什么？

Question

当一个 Dockerfile 包含 VOLUME 指令（比如）VOLUME [/opt/apache2/www, ...]（希望这个路径在实际安装中存在），这意味着这个路径将被挂载到某个东西上（对吧？）。而且这个 VOLUME 指令是针对图像的，而不是针对它的一个实例（容器），而是针对每个实例。

无论如何，无论图像是否包含定义的 VOLUME，在启动容器时，运行命令都可以通过将本地主机路径映射到容器路径来创建卷。

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）无论如何，其他容器可以以某种自动方式访问挂载点。伟大的。

我的第一个问题是，安装在容器 understanding_volumes 上的另一个卷路径 /any/container/path image_name 是否也可用于使用 --from-container 或 --volumes-from 的第二个容器（无论哪个选项正确）？

我的下一个问题是，是否使用 VOLUME 指令只是为了让其他容器链接到该路径 --> 即通过简单的链接使/opt/apache2/www 上的数据对其他容器可用。所以只是分享出来。或者是否有任何数据也可以提供给第一个容器。

Answer 1

在 Dockerfile 中定义卷的优点是可以在映像定义中指定卷位置作为从映像创建者到映像用户的​​文档。这只是唯一的好处。

它很早就被添加到 docker 中，很可能是在数据容器是保存数据的唯一方式时。我们现在有一个解决方案，用于具有过时数据容器的命名卷。我们还添加了 compose 文件来定义容器如何以易于理解和重用的语法运行。

虽然自我记录的图像有一个优点，但也有很多缺点，以至于我强烈建议不要在图像内定义卷给我的客户和任何发布图像的人一般重用：

1. 音量是强制在最终用户身上的，无法取消定义图像中的音量。

2. 如果未在运行时定义卷（使用-v 或撰写文件），用户将在其docker volume ls 中看到与创建它们的内容无关的匿名卷。这些几乎都是无用的磁盘空间浪费。

3. 它们破坏了扩展映像的能力，因为在 VOLUME 行之后对映像中的卷所做的任何更改通常都会被 docker 忽略。这意味着用户永远无法添加自己的初始卷数据，这非常令人困惑，因为 docker 没有发出警告，表明它在映像构建期间忽略了用户更改。

4. 如果您需要将卷作为用户作为运行时，您始终可以使用 -v 或 compose 文件定义它，即使该卷未在 Dockerfile 中定义。许多用户有这样的误解，即您必须在映像中定义它才能使其在运行时成为命名卷。

使用--volumes-from 的能力不受在图像中定义音量的影响，但我建议您避免使用此功能。它在 swarm 模式下不存在，您可以通过使用挂载在两个容器中的命名卷来获得所有相同的功能以及更精细的粒度。