Volumes
Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure and OS of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:
- Volumes are easier to back up or migrate than bind mounts.
- You can manage volumes using Docker CLI commands or the Docker API.
- Volumes work on both Linux and Windows containers.
- Volumes can be more safely shared among multiple containers.
- Volume drivers let you store volumes on remote hosts or cloud providers, encrypt the contents of volumes, or add other functionality.
- New volumes can have their content pre-populated by a container.
- Volumes on Docker Desktop have much higher performance than bind mounts from Mac and Windows hosts.
In addition, volumes are often a better choice than persisting data in a container's writable layer, because a volume doesn't increase the size of the containers using it, and the volume's contents exist outside the lifecycle of a given container.
If your container generates non-persistent state data, consider using a tmpfs mount to avoid storing the data anywhere permanently, and to increase the container's performance by avoiding writing into the container's writable layer.
Volumes use rprivate bind propagation, and bind propagation isn't configurable for volumes.
Choose the -v or --mount flag
In general, --mount is more explicit and verbose. The biggest difference is that the -v syntax combines all the options together in one field, while the --mount syntax separates them. Here is a comparison of the syntax for each flag.
If you need to specify volume driver options, you must use --mount .
- -v or --volume : Consists of three fields, separated by colon characters ( : ). The fields must be in the correct order, and the meaning of each field isn't immediately obvious.
- In the case of named volumes, the first field is the name of the volume, and is unique on a given host machine. For anonymous volumes, the first field is omitted.
- The second field is the path where the file or directory is mounted in the container.
- The third field is optional, and is a comma-separated list of options, such as ro . These options are discussed below.
- The type of the mount, which can be bind , volume , or tmpfs . This topic discusses volumes, so the type is always volume .
- The source of the mount. For named volumes, this is the name of the volume. For anonymous volumes, this field is omitted. Can be specified as source or src .
- The destination takes as its value the path where the file or directory is mounted in the container. Can be specified as destination , dst , or target .
- The volume-subpath option takes a path to a subdirectory within the volume to mount into the container. The subdirectory must exist in the volume before the volume is mounted to a container. See Mount a volume subdirectory.
- The readonly option, if present, causes the bind mount to be mounted into the container as read-only. Can be specified as readonly or ro .
- The volume-opt option, which can be specified more than once, takes a key-value pair consisting of the option name and its value.
Warning
If your volume driver accepts a comma-separated list as an option, you must escape the value from the outer CSV parser. To escape a volume-opt , surround it with double quotes ( " ) and surround the entire mount parameter with single quotes ( ' ).
For example, the local driver accepts mount options as a comma-separated list in the o parameter. This example shows the correct way to escape the list.
,dst=,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:,"volume-opt=o=addr=,vers=4,soft,timeo=180,bg,tcp,rw"'
The examples below show both the --mount and -v syntax where possible, with --mount first.
Differences between -v and --mount behavior
As opposed to bind mounts, all options for volumes are available for both --mount and -v flags.
Volumes used with services, only support --mount .
Create and manage volumes
Unlike a bind mount, you can create and manage volumes outside the scope of any container.