How Docker volume works?

Somebody creates a php and Apache project, with docker, using volumes to persist the files that this project generated (plain text files saved in a folder).

This person built the image and ran the project normally, with the exception of one detail, (s)he didn't link the folder where (s)he saved the messages (www/site/messages) (s)he simply used the /data folder, in which the project had no connection. And it worked.

How does the volume really work? Because to me it doesn't make sense.

This is the project:

https://github.com/matheusbattisti/curso_docker/tree/main/2_volumes

Dockerfile's VOLUME does not allow you to specify a host path.

On the host-side, the volumes are created with a very long ID-like name, these volumes are often referred to as unnamed/anonymous volumes.

Given this Dockerfile:

FROM php7:latest
VOLUME /var/www

Build it:

docker build -t myTest

Run it :

docker run --rm -it myTest

Inside the container, run ls and you'll notice the directory exists; /var/www

Running the container also creates a directory on the host-side.

While having the container running, execute docker volume ls on the host machine and you'll see something like this

DRIVER    VOLUME NAME
local     c984..e4fc

Back in the container, execute touch /var/www/myFile

This file is now available on the host machine, in one of the unnamed volumes.

ls /var/lib/docker/volumes/c984..e4fc/_data

Similarly, you can try to delete this file on the host and it will be deleted in the container as well.

Now run a new container, but specify a volume using -v:

docker run --rm -it -v /myVolume myTest

This adds a second volume and the whole system ends up having two unnamed volumes.
On the host-side, the new second volume is anonymous and resides together with the other volume in /var/lib/docker/volumes/.

It was stated earlier that the Dockerfile can not map to a host path which sort of pose a problem for us when trying to bring files in from the host to the container during runtime. A different -v syntax solves this problem.

Imagine I have a subfolder in my project directory ./src that I wish to sync to /src inside the container. This command does the trick:

docker run -it -v $(pwd)/src:/src myTest

Both sides of the : character expects an absolute path. Left side being an absolute path on the host machine, right side being an absolute path inside the container.

We run this command:

docker run -v $(pwd)/src:/src myTest

Is the specification purely informational?

No, it does mount a volume, it's similar to -v /var/www you just don't specify a mount point in the host machine, so docker will take care of it.

What are the (dis)advantages of (not) specifying volumes?

Why and in which cases should I use VOLUME and when shouldn't I?

It's probably a best practice to never use VOLUME.

The first reason we have already identified: We can not specify the host path.

The second reason is people might forget to use the --rm option when running the container, you will end up with a couple of unused volumes and it might be a daunting task to figure out which of all anonymous volumes are safe to remove

What about files that may optionally be mounted? Do they count as volumes in that case, too?

In this case you don't need volumes; mapping a single file does not make sense, I would use ADD or COPY inside the dockerfile.

StackExchange DevOps Q#15745, answer score: 3