From my experience with Docker one should just avoid docker-supplied volumes and manage the storage oneself using host bind mounts for containers and consistently using --read-only for containers themselves.
With that it is really weired to read all complains and issues about volumes management. It seems Docker just picked up wrong model for their storage. Then they try forever to fix impedance mismatch between that model and how people want to use Docker.
Care to clarify issues you have with volume management?
I think the biggest issue is around the `-v` syntax (and the corrosponding API).
In the UX we call things a volume which are actually a mount (which happen to use a volume).
I like the way we have implemented this in the new services API.... `docker run --mount type=volume,source=important_data,volume-driver=foo,volume-options=...`
For me the biggest issue with docker volumes is lack of any notion of subvolumes or volume grouping. Consider an application consisting of few containers communicating over unix sockets each with its own state. Surely I can create a bunch of volumes for the containers, but those would not have any notion of grouping. That complicates administration and development.
For example, it is very useful to have a shell view of all volumes for the application to poke inside or debug issues. Surely I can do docker run ubuntu and mount all relevant volumes under /mnt there, but that is not user friendly.
Or consider that during development or debugging I want to transfer the state to another machine. Why it is not possible to tar all application volumes with single command and restore them in a new place again with single command? I.e, something similar for docker save/load, but for volumes?
All those issues are trivially solvable if I use some directory on a file system for the whole application state and use subdirectories there for individual volumes for the containers and then pass those with -v to relevant containers.
With that it is really weired to read all complains and issues about volumes management. It seems Docker just picked up wrong model for their storage. Then they try forever to fix impedance mismatch between that model and how people want to use Docker.