Docker Community Forums

Share and learn in the Docker community.

Why use the VOLUME instruction?


(Gvenzl) #1

Hey everybody,

This discussion originated out of https://github.com/oracle/docker-images/issues/640 and this is a follow up from https://twitter.com/FrenchBen/status/953677514576158720

The question is: Why should you use the VOLUME instruction in your Dockerfile?

The obvious answer is so that you document which VOLUME binds are exposed to the user. However, the implementation makes that somewhat useless. You still have to specify the exact path within the container that you are going to expose anyway, i.e. “-v myvol:/path/to/expose” and you can just expose any path, regardless whether or not you have a VOLUME set on it or not.
So you might as well just document the path in some other way or form and don’t use the VOLUME instruction.
Of course, if you don’t specify any mount point the data will end up in an anonymous volume, but even that gives you anything given that the volume is anonymous and you have no clue of what to reuse it for. So even if you say that the VOLUME instruction will guarantee that files reside outside the container that should/have to, those files are rendered useless as well as you have no idea which container created which anonymous volume once the container is gone.

The big issues that VOLUMES bring with them is when extending images. They cannot be undone in the inherited image. As the user in the GitHub issue states:

There are no benefits to declaring a volume line in a dockerfile. Even if you do, the client still has to declare a volume anyway to make any use of it (for example, by declaring it in a run statement or in their docker-compose.yaml file). And removing this line will have no effect, because the client can still create a volume anytime they want to be putting it in their run statement or docker-compose file.

So I’m trying to understand what VOLUMES were actually designed for and whether it makes sense to use them in Dockerfiles at all, especially as they cannot be undone in images which inherited them.