docker-compose v2 named volumes and volumes on host

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.