docker-compose v2 named volumes and volumes on host - docker

Question

I am looking for guidance on how what is the cleanest way to make a docker-compose.yml version 2 that:
Has container state clearly separated from the container.
Has container state mounted to the host for simplicity (single data point, simply backup /data on the host and you're done). I'm open to be wrong about this, see questions below).
The app is a classic web app with a mysql & redis database for the backend, and with a webserver that is behind a proxy that serves static assets directly. Some details like depends_on, environment variables and the networks are intentionally left out.
Here is what I use at the moment:
version: "2"
services:
proxy:
build:
context: ./apps/nginx
ports:
- "80:80"
- "443:443"
volumes:
- /etc/localtime:/etc/localtime:ro
- ./data/web/assets:/var/www/assets:ro
- ./data/web/puma:/var/run/puma
web:
build:
context: ./apps/rails
volumes:
- /etc/localtime:/etc/localtime:ro
- ./data/web/assets:/srv/app/public/assets
- ./data/web/puma:/var/run/puma
db:
image: mysql:5.7
volumes:
- /etc/localtime:/etc/localtime:ro
- ./data/mysql:/var/lib/mysql
redis:
image: redis
volumes:
- /etc/localtime:/etc/localtime:ro
- ./data/redis:/data
Here is what I plan to use for the next release:
version: "2"
services:
proxy:
build:
context: ./apps/nginx
ports:
- "80:80"
- "443:443"
volumes_from:
- localtime
- web-assets-data:ro
- web-puma-data
web:
build:
context: ./apps/rails
volumes_from:
- localtime
- web-assets-data
- web-puma-data
db:
image: mysql:5.7
volumes_from:
- localtime
- db-data
redis:
image: redis
volumes_from:
- localtime
- redis-data
web-assets-data:
image: ubuntu:14.04
volumes:
- ./data/web/assets:/srv/app/public/assets
web-puma-data:
image: ubuntu:14.04
volumes:
- ./data/web/puma:/var/run/puma
db-data:
image: ubuntu:14.04
volumes:
- ./data/mysql:/var/lib/mysql
redis-data:
image: ubuntu:14.04
volumes:
- ./data/redis:/data
localtime:
image: ubuntu:14.04
volumes:
- /etc/localtime:/etc/localtime:ro
I think the benefits of the new version are:
It's more clear where the data is.
It's easier to share data among multiple containers (no need to remember the exact paths like in the current version).
So, my questions are:
Is it problematic to use different images between the container and it's container-data? for example, should db-data use mysql:5.7 instead of ubuntu:14.04?
Is it correct to say that there's no way of having "data stored at a specific path on the host" with a top level volumes: key?
What are the advantages and inconvenients of using a named volume (with a top-level "volumes" key)? Should I prefer using a named volume over a host mount? Workflow comparisons would be nice.

Answer 1

Is it problematic to use different images between the container and it's container-data
Not at all, this is normal.
Is it correct to say that there's no way of having "data stored at a specific path on the host" with a top level volumes: key?
Correct. The top level volumes key is for named volumes, but you can't name host volumes.
What are the advantages and inconveniences of using a named volume (with a top-level "volumes" key)? Should I prefer using a named volume over a host mount? Workflow comparisons would be nice.
Named volumes let you use volume drivers, so you could have the data stored somewhere other than the local filesystem. However named volumes need to be initialized with data, so you might have to add a script or something to do so.