The effective differences to optimization are these: there is no reason to ever add -v /my/mount/point:/mount/here and thus users need not be concerned with it.īinding mounts (like the example above with -v) must always be present if they are required. Users of such an image will always get a volume at that location when running docker run This inherently bypasses the union filesystem docker uses. Volumes in the dockerfile allow a path to be specified in the image that should always be created as a volume. Otherwise it's a local named volume that can be easily used with docker-compose. If it's deployed with swarm mode, I'll point to a NFS server with a named volume to allow the data to be reached as the containers migrate to different hosts. A simple example of this is: $ docker volume create -driver local \įor defining my volumes, since you do not want to do this in a Dockerfile, I use a docker-compose.yml and define my volumes in there.
If I really need access outside of docker directly to the data, then I try to use a named volume that points to a bind mount instead of the default local driver settings. The initialization of data and better handling of uid/gid issues trump the convenience of a host volume. This is the worst way to store volumes in my opinion, and the reason that no one should ever define a volume inside their Dockerfile.
Other drivers let you reference data in even more locations (e.g.
The source identifies the type of volume, so a path (including the leading slash) to a file/directory results in a host volume.