What's the difference between declaring in docker-compose.yml volume as section and under a service?

Question

What's the difference between declaring in the docker-compose.yml file a volume section and just using the volumes keyword under a service?

For example, I map a volume this way for a container:

services:
   mysqldb:
      volumes:
         - ./data:/var/lib/mysql

This will map to the folder called data from my working directory.

But I could also map a volume by declaring a volume section and use its alias for the container:

services:
   mysqldb:
      volumes:
         - data_volume:/var/lib/mysql
volumes:
   data_volume:
      driver: local

In this method, the actual location of where the mapped files are stored appears to be somewhat managed by docker compose.

What are the differences between these 2 methods or are they the same? Which one should I really use?

Are there any benefits of using one method over the other?

Answer 1

The difference between the methods you've described is that first method is a bind mount , and the other is a volume . These are more of Docker functions (rather than Docker Compose), and there are several benefits volumes provide over mounting a path from your host's filesystem. As described in the documentation, they:

• are easier to back up or migrate
• can be managed with docker volumes or the API (as opposed to the raw filesystem)
• work on both Linux and Windows containers
• can be safely shared among multiple containers
• can have content pre-populated by a container (with bind mounts sometimes you have to copy data out, then restart the container)

Another massive benefit to using volumes are the volume drivers , which you'd specify in place of local . They allow you to store volumes remotely (ie cloud, etc) or add other features like encryption. This is core to the concept of containers, because if the running container is stateless and uses remote volumes, then you can move the container across hosts and it can be run without being reconfigured.

Therefore, the recommendation is to use Docker volumes. Another good example is the following:

services:
  webserver_a:
    volumes:
      - ./serving/prod:/var/www
  webserver_b:
    volumes:
      - ./serving/prod:/var/www
  cache_server:
    volumes:
      - ./serving/prod:/cache_root

If you move the ./serving directory somewhere else, the bind mount breaks because it's a relative path. As you noted, volumes have aliases and have their path managed by Docker, so:

1. you wouldn't need to find and replace the path 3 times
2. the volume using local stores data somewhere else on your system and would continue mounting just fine

---

TL;DR: try and use volumes. They're portable, and encourage practices that reduce dependencies on your host machine.