All docker files look something like this
services:
service_name:
image: author/project:latest
container_name: service_name
volumes:
- service_data:/app/data/
volumes:
service_data:
Yes, this makes the data to persist, but it creates a directory with a random name inside /var/lib/docker/volumes/
This makes it really hard to actually have ownership of the data of the service (for example to create backups, or to migrate to another host)
Why is it standard practice to use this instead of having a directory mounted inside at the same level you have your docker-compose.yml?
Like this - ./service_data:/app/data
I’m not a huge docker expert, but I recently spun up a tandoor…dev, and their config instructions explicitly point out a couple of mounts that have to be volumes and can not be binds.
Docker’s own comments are https://docs.docker.com/engine/storage/volumes/ which my tl;dr is faster, can be shared by multiple containers, and can be a remote (NFS/CIFS) target.
I’d guess that maintainers use the volume structure to let docker handle the details of creating and maintaining the mount, rather than put it on the user, who may be spinning up their first-ever docker and may make all kind of naive mistakes.