There are two ways to persist data in Docker,
bind mount, but there are other ways, such as
tmpfs in Linux and
named pipe in windows, but they are not universal, so I won’t go into them here. This article mainly introduces the differences between
bind mount and the usage scenarios, and takes out some details about them.
Data management diagram
|Figure 1: Common ways to manage data in Docker|
[email@example.com]# docker volume create redis [firstname.lastname@example.org]# docker run -v redis:/data redis:6.0 redis-server
bind mount Use
[email@example.com]# docker run -v /myredis/conf:/usr/local/etc/redis redis redis-server
Persistence method selection
volume usage scenarios
Volumes are the preferred way to persist data in Docker containers and services. Some usage scenarios for volumes include.
- Sharing data between multiple running containers. If you don’t create it explicitly, volume is created when it is first installed into a container. When that container is stopped or removed, the volume still exists. Multiple containers can mount the same volume at the same time, either read-write or read-only. Volumes are deleted only if you explicitly delete them.
- volume decouples the configuration of the Docker host from the container runtime when the Docker host is not guaranteed to have a given directory or file structure.
- When you want to store the container’s data on a remote host or cloud provider.
- When you need to back up, restore, or migrate data from one Docker host to another, volume is a better choice. You can stop using the volume’s containers and then back up the volume’s directory (e.g.
- When your application needs high performance I/O on Docker Desktop. volume is stored in a Linux virtual machine instead of the host, which means much lower latency and throughput for reads and writes.
- When your application needs to implement fully native file system behavior on Docker Desktop. For example, a database engine needs precise control over disk flushing for transaction durability. volume storage in a Linux virtual machine makes these guarantees, while a bind mount is remote to macOS or Windows, with slightly different file system behavior.
bind mount usage scenarios
In general, you should use volume whenever possible.
bind mount is suitable for the following scenarios.
- Sharing configuration files from the host to the container. This is the way Docker provides DNS resolution to containers by default, by mounting /etc/resolv.conf on the host to each container.
- Share source code or build components between the development environment and containers on the Docker host. For example, you can mount the Maven
target/directory into a container and each time you build a Maven project on the Docker host, the container can access the rebuilt components.
If you use Docker for development in this way, your production Dockerfile copies production-ready components directly to the image, rather than relying on binding mounts.
- When the file or directory structure of the Docker host is guaranteed to be consistent with the binding mounts required by the container.
bind mount can be used with
-mount, the difference between
--volume): simple and straightforward
-mount: more explicit, but lengthy, so if you need to specify the parameters for mount, then you should use this one
container directory is not empty
- If you mount a
volumeto a directory inside a container that already has content in it, then the behavior depends on whether your
volumeis empty or not
volumeis empty, then the contents of the directory inside the container will be copied to
volumeis not empty, then the directory inside the container will be hidden, but not deleted or modified.
- If the
bind mountmethod is used, then the directory inside the container will be hidden regardless of whether the host directory is empty or not.
host directory/volume does not exist
If you specify
volume or the host’s directory with
-v, but the directory or
volume does not exist, then docker will create one for you.
-bind mount: the directory created is always a directory; (
--volumewill be created automatically, but
-mountwill throw an error)
-volume: creates an empty
--mountwill be created)