`data-container` with named or anonymous volumes -

问题:

a) Anonymous volumes

When using data-containers, you can either use anonymous volumes like this

version '2'
services:
  consumer:
    volume_from:
      - data-container:rw
  data-container:
    image: cogniteev/echo
    command: echo 'Data Container'
    volume:
      - /var/www

b) Name volumes

or you can use named volumes like this

version '2'
services:
  consumer:
    volume_from:
      - data-container:rw
  data-container:
    image: cogniteev/echo
    command: echo 'Data Container'
    volume:
      - my-named-volume:/var/www

 volumes:
   my-named-volume:
     driver: local

I usually go with b) and would like to discuss / get explained the conceptual issues / flaws of maybe both of those. So what are the pros and cons.

The aspects we can compare them against are / could be:

1. portability
2. upgradeability of the data-container (why would we ever upgrade the container ? )
3. Start/Stop (continue) compatibility?
4. multiple-stack issues?
5. efficiency ( reuse of the volume )

This question spwaned du to the discussion on this question https://stackoverflow.com/a/38984689/3625317

回答1:

Short answer: named data volumes are preferred, data containers are no longer needed, so you should never use volumes-from on any new project.

Your version of named volumes is merging a named and data container, it should be:

version '2'
services:
  web:
    image: my-web-image
    volumes:
      - my-named-volume:/var/www

 volumes:
   my-named-volume:
     driver: local

By merging the two, you've added an extra layer of indirection to reach your named volume, without any added benefits. Named volumes were created in 1.9 to replace data containers which were themselves a somewhat hacked method to provide persistent data. Advantages of named volumes over data containers include:

• Your data management is separate from your container management, you can remove all running containers and still have your data available
• Data can be stored in different locations using volume drivers, which means you can put it on nfs, a distributed file system, or even a local persistent directory
• You may start and stop any container in any order without dependencies between containers
• When first created, a named volume will receive a copy of the image filesystem it is first mounted on top of, identical to the behavior of data containers, which means it's a seamless transition (note that this is not the behavior of a host volume, aka bind mount)

See also this question that also discusses named volumes vs data containers and this answer to another similar question. We also have a blog post on this by a company that I work for.