0

The compose specification says:

To reuse a volume across multiple services, a named volume MUST be declared in the top-level volumes key.

I am currently trying to debug an application with a docker bind mount issue. I noticed that the compose.yaml file for this application declares the volume ${EXTRA_VOLUME} under every service.

Every other reused volume is (1) declared under the services that use it and (2) declared under the top level volumes key. Therefore, the other volumes are compliant with the specification.

The ${EXTRA_VOLUME} is (1) declared under the services that use it, but NOT declared under the top level volumes key.

So, I am wondering: What happens to ${EXTRA_VOLUME}? What problems should I expect?

Christian Galo
  • 11
  • 3
  • Either `EXTRA_VOLUME` will resolve to a filesystem path, in which case you get a bind mount, or it will look like a volume name and fail with an error like "ERROR: Named volume "foo:/foo:rw" is used in service "my_service" but no declaration was found in the volumes section.". – larsks Sep 23 '22 at 12:38

1 Answers1

0

Docker has a page dedicated to this, where they go over the differences between volumes, bind-mounting implicitly (with --volume) and bind-mounting explicitly (with --mount).

To summarise, and to put in the context of docker compose, the volumes: top-level section is for declaring volumes that have to go through a volume driver (e.g. local filesystem-backed volumes under /var/lib/docker/volumes, NFS mounts, SMB mounts, EBS block volumes, etc). Docker controls the volume's lifecycle, when it gets created, mounted, deleted, etc.

Bind-mounting a filesystem path provides similar functionality, but it's unmanaged by docker: it's simply a filesystem path/file being made accessible at a given (inside) path when starting the container. Because it's so much simpler, and there's no volume driver involved, it doesn't need (indeed, it shouldn't!) be declared as a volume: entry.

Guto Andreollo
  • 76
  • 5