当 Dockerfile 包含 VOLUME 指令时（例如）VOLUME [/opt/apache2/www, ...]（希望这个路径在实际安装中存在），这意味着这个路径将被安装到某个东西上（对吗？）。此 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 问题对此有所启发 -在 DockerFile 中定义 VOLUME 挂载点而不是 adhoc cmd-line -v 的目的是什么？ https://stackoverflow.com/questions/33148754/what-is-the-purpose-of-defining-volume-mount-points-within-dockerfile-rather-tha。这里提到了 VOLUME 指令的一个好处。也就是说，其他容器可以从中受益。使用--from-container（找不到此选项docker run --help，不确定答案是否意味着--volumes-from）无论如何，其他容器可以通过某种自动方式访问安装点。伟大的。
我的第一个问题是，是另一个卷路径/any/container/path image_name安装到容器上理解卷也可用于第二个容器使用--from-container or --volumes-from（哪个选项是正确的）？
我的下一个问题是，使用 VOLUME 指令只是为了让其他容器链接到这个路径 --> 就是让数据/opt/apache2/www通过简单的链接可用于其他容器。所以这只是分享。或者是否有任何数据也可以提供给第一个容器。
在 Dockerfile 中定义卷的优点是可以将镜像定义中的卷位置指定为镜像创建者向镜像用户提供的文档。这只是唯一的好处。
它很早就被添加到 Docker 中，很可能当时数据容器是持久数据的唯一方法。我们现在有一个针对已过时数据容器的命名卷的解决方案。我们还添加了 compose 文件来定义容器如何以易于理解和重用的语法运行。
虽然自我记录图像有一个优点，但也有很多缺点，以至于我强烈建议不要在图像内定义体积致我的客户和任何发布图像以供一般重复使用的人：
该卷被强制提供给最终用户，无法取消定义映像中的卷。
如果在运行时未定义卷（使用-v或撰写文件），用户将在其目录中看到匿名卷docker volume ls与创造它们的事物没有任何关联。这些几乎总是无用的磁盘空间浪费。
它们破坏了扩展图像的能力，因为在扩展之后图像中的体积发生任何变化VOLUME该行通常会被 docker 忽略。这意味着用户永远无法添加自己的初始卷数据，这非常令人困惑，因为 docker 不会发出警告，表明它在镜像构建期间忽略了用户的更改。
如果您需要作为用户运行时拥有一个卷，您始终可以使用-v或撰写文件，即使该卷未在 Dockerfile 中定义。许多用户有这样的误解：您必须在映像中定义它才能在运行时使其成为命名卷。
使用能力--volumes-from不受定义图像中体积的影响，但我建议您避免使用此功能。它在群体模式中不存在，并且您可以通过使用安装在两个容器中的命名卷来获得所有相同的功能以及更细的粒度。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
