Why have docker-compose volumes to be declared twice when not pointing to an actual folder on the host?

user_6630397 0
Viewed 866

In a docker-compose.yml file, do I really need to specify the volumes twice; inside and outside a service? If yes, Why? (the docker-compose part of the doc doesn't have much information on that)

docker-compose volume inside a service

I have the feeling that, in the case shown here where the myapp volume is not explicitly a folder on the host machine, we have to set it twice, but if it actually is a folder on the host machine, specifying it only inside the frontend service block is enough.

In addition, when the volume is specified outside the service block, it's almost always written as key: without any actual value (or sometime as key: {}), which makes me confused.

Moreover, when I run docker-compose down -v it actually only applies on volumes which are not explicitly specified as a folder on the host machine, according to the doc:

-v, --volumes           Remove named volumes declared in the `volumes`
                        section of the Compose file and anonymous volumes
                        attached to containers.

So maybe the declaration of a volume outside a service is for making this volume identifiable, hence 'removable'. And on the other hand, it will never be removable if it's not set outside the service?

docker-volume docker-compose docker
1 Answers

This is a whole bunch of questions - let's try to answer them sequentially:

1. Do I really need to specify the volumes twice (inside and outside the services section)?

This is not a duplicate specification: outside you declare the volume and inside you specify how to mount it into a container. A volume has an independent life cycle from services. It can be mounted by several services and it will retain data if services are restarted.

2. When the volume is specified outside the service block, it's almost always written as key: {}

This key-only notation is the default and does not require any driver configuration. However, if you needed to e.g. connect to NFS, you would have something like:

volumes:
  example:
    driver_opts:
      type: "nfs"
      o: "addr=10.40.0.199,nolock,soft,rw"
      device: ":/docker/example"

Also, please differentiate between bind mounts and regular volumes. While regular volumes are managed independently from services (and containers), e.g. with docker volumes list, bind-mounts are mere mappings between the host and the container file system. They are tied to the container they are mounted to.

3. When I run docker-compose down -v it actually only applies on volumes which are not explicitly specified as a folder on the host machine

Yes, this won't remove bind mounts, since bind mounts are mere host-container filesystem mappings and therefore Docker does not create an independent volume entity for them.

For deeper understanding, please consider this excerpt from the documentation:

Bind mounts have been around since the early days of Docker. Bind mounts have limited functionality compared to volumes. When you use a bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its absolute path on the host machine. By contrast, when you use a volume, a new directory is created within Docker’s storage directory on the host machine, and Docker manages that directory’s contents.

user_23858080
Related