问题描述
当Dockerfile包含VOLUME指令（例如） VOLUME [/ opt / apache2 / www，...] （希望此路径存在于实际安装中）时，这意味着该路径将被安装到某物上（对吗？）。并且此VOLUME指令用于图像，而不是用于图像的一个实例（容器），而是用于每个实例。
When a Dockerfile contains VOLUME instruction (say) VOLUME [/opt/apache2/www, ...] (hope this path exists in real installation), it means this path is going to be mounted to something (right?). And this VOLUME instruction is for the image and not for one instance of it (container) but for every instance.
无论如何，无论图像是否包含定义的VOLUME ，在启动容器时，运行命令可以通过将本地主机路径映射到容器路径来创建卷。
Anyway irrespective of whether an image contains a VOLUME defined or not, at the time of starting a container the run command can create a volume by mapping a local host path to a container path.
docker run --name understanding_volumes -v /localhost/path1:/opt/apache2/www -v /localhost/path2:/any/container/path image_name
上面的内容应该使我们清楚，尽管 / any / container / path 在Dockerfile中未定义为VOLUME，我们可以在运行容器时将其挂载。
The above should make it clear that though /any/container/path is not defined as a VOLUME in Dockerfile, we are able to mount it while running container.
这个SOF问题对此有所启发-。这里提到了VOLUME指令的一个好处。也就是说，其他容器也可以从中受益。使用-from-container （对于 docker run --help 找不到此选项，不确定是否答案的意思是-volumes-from ）无论如何，其他容器可以通过某种自动方式访问挂载点。大。
That said, this SOF question throws some light on it - What is the purpose of defining VOLUME mount points within DockerFile rather than adhoc cmd-line -v?. Here one benefit of VOLUME instruction is mentioned. Which is, other containers can benefit from it. Using the --from-container (could not find this option for docker run --help, not sure if the answer meant --volumes-from) Anyway thus the mount point is accessible to other container in some kind of automatic way. Great.
我的第一个问题是，是否将另一个卷路径 / any / container / path image_name 安装到了容器上 understanding_volumes 也可以使用-from-container 或-volumes-from （哪个选项正确）？
My first question is, is the other volume path /any/container/path image_name mounted on to the container understanding_volumes also available to the second container using --from-container or --volumes-from (whichever option is correct)?
我的下一个问题是，是否使用VOLUME指令只是让其他容器链接到此路径->即通过轻松链接使 / opt / apache2 / www 上的数据可用于其他容器。所以只是分享。还是也有任何数据可用于第一个容器。
My next question is, is the use of VOLUME instruction just to let the other containers link to this path --> that is to make the data on /opt/apache2/www available to other containers through easy linking. So it's just sharing out. Or is there any data that can be made available to first container too.
推荐答案
在Dockerfile中定义卷的好处是，可以将映像定义内的卷位置指定为映像创建者到文档的文档。图像的用户。这只是唯一的好处。
Defining a volume in a Dockerfile has the advantage of specifying the volume location inside the image definition as documentation from the image creator to the user of the image. That's just about the only upside.
它是很早就添加到docker的，很可能是在数据容器是持久保存数据的唯一方法的情况下。现在，我们为已废弃的数据容器的命名卷提供了解决方案。我们还添加了compose文件，以定义容器如何以易于理解和重用的语法运行。
It was added to docker very early on, quite possibly when data containers were the only way to persist data. We now have a solution for named volumes that has obsoleted data containers. We have also added the compose file to define how containers are run in an easy to understand and reuse syntax.
尽管存在自记录图像的一个优点，缺点很多，以至于我强烈建议不要在我的客户和任何发布图像以供一般重用的人中定义图像内的卷：
While there is the one upside of self documented images, there are quite a few downsides, to the point that I strongly recommend against defining a volume inside the image to my clients and anyone publishing images for general reuse:
-
已将卷强加给最终用户，无法在图像中取消定义卷。
The volume is forced on the end user, there's no way to undefine a volume in the image.
如果未在运行时定义卷（使用 -v 或撰写文件），则用户将在其 docker卷ls 中看到匿名卷。 code>与创建它们的原因无关。这些几乎总是浪费磁盘空间。
If the volume is not defined at runtime (with a -v or compose file), the user will see anonymous volumes in their docker volume ls that have no association to what created them. These are almost always useless wastes of disk space.
它们破坏了扩展图像的能力，因为在<$ c之后对图像中的卷进行的任何更改$ c> VOLUME 行通常被docker忽略。这意味着用户永远无法添加自己的初始卷数据，这非常令人困惑，因为docker不会警告它在映像构建期间会忽略用户更改。
They break the ability to extend the image since any changes to a volume in an image after the VOLUME line are typically ignored by docker. This means a user can never add their own initial volume data, which is very confusing because docker gives no warning that it is ignoring the user changes during the image build.
如果您需要在运行时将卷作为用户使用，则始终可以使用 -v 或撰写文件对其进行定义，即使该卷未在Dockerfile。许多用户误以为必须在映像中定义它才能在运行时将其命名为卷。
If you need to have a volume as a user a runtime, you can always define it with a -v or compose file, even if that volume is not defined in the Dockerfile. Many users have the misconception that you must define it in the image to be able to make it a named volume at runtime.
使用-volumes-from 的功能不会因定义图像中的音量而受到影响，但我建议您避免使用此功能。它在群模式下不存在，并且可以通过使用装入两个容器的命名卷来获得所有相同的功能以及更细的粒度。
The ability to use --volumes-from is unaffected by defining the volume in the image, but I'd encourage you to avoid this capability. It does not exist in swarm mode, and you can get all the same capabilities along with more granularity by using a named volume that you mount in two containers.
这篇关于Dockerfile命令“ Volume”的目的是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！