Three ways to mount docker data

Table of contents

Foreword
A more detailed Diff
is suitable for Volumes scenarios.
It is suitable for bind mounts scenarios.
It is suitable for tmpfs mounts scenarios.
Usage
Preface
Back to directory
We can write data to the writable layer of the container, but this kind of writing has shortcomings:

When the container stops running, the written data is lost. It is also difficult for you to take this data out of the container and make it available to other applications.
The writable layer of the container is tightly coupled with the host. These written data can be easily deleted.
Writing to the writable layer of a container requires a storage driver to manage the file system. This storage driver provides a union filesystem through the linux kernel. Compared to data volumes (data volume), this additional abstraction will reduce performance.
Docker provides 3 methods to mount data from the Docker host to the container:

volumes,
bind mounts
tmpfs mounts.
Generally speaking, volumes are always the best choice.

No matter which mounting method you choose, the view from the container will be the same. Data is displayed as a directory or a single file in the container's file system.

A simple way to differentiate between volumes, bind mounts, and tmpfs mounts is to think about how the data exists on the host.

Volumes are managed by Docker and stored somewhere on the host machine (/var/lib/docker/volumes/ on Linux). Non-Docker applications cannot modify the data in this location. Volumes are the best data persistence method for Docker.
The data of Bind mounts can be stored anywhere on the host machine. The data can even be important system files or directories. Non-Docker
applications can change this data.
The data of tmpfs mounts is only stored in the host's memory and will not be written to the host's file system.

A more detailed Diff
back to the directory
Volumes: Created and managed by Docker. You can create a volume explicitly through the docker volume create command, or Docker can create a volume itself when creating a container or service.

When you create a volume, it will be stored in a directory on the host machine. When you mount this volume to a container, this directory is what is mounted to the container. This is similar to bind mounts, except that the volumes are created by Docker and are isolated from the host's core functionality.

A volume can be mounted to several containers at the same time. Even if there are no running containers using this volume, the volume still exists and will not be automatically cleared. Volumes that are no longer used can be cleared through docker volume prune.

Volumes also supports volume driver, which can store data on another machine or the cloud.

Bind mounts: Docker has supported this feature since its early days. Bind mounts support limited functionality compared to volumes. When using bind mounts, a file or directory on the host is mounted to the container.

Warning: A side effect of using Bind mounts is that programs running in the container can modify the host's file system, including creating, modifying, and deleting important system files or directories. There may be security issues with this feature.

tmpfs mounts: The data of tmpfs mounts will not be written to disk. During the life cycle of the container, it can be used to store some state or sensitive data that does not need to be persisted. For example, the swarm service uses tmpfs mounts to mount secrets into a service container.

适合Volumes的场景
回到目录
在不同的容器中共享数据。If you don’t explicitly create it, a volume is created the first time it is mounted into a container. When that container stops or is removed, the volume still exists. Multiple containers can mount the same volume simultaneously, either read-write or read-only. Volumes are only removed when you explicitly remove them.
When the Docker host is not guaranteed to have a given directory or file structure. Volumes help you decouple the configuration of the Docker host from the container runtime.
When you want to store your container’s data on a remote host or a cloud provider, rather than locally.
When you need to be able to back up, restore, or migrate data from one Docker host to another, volumes are a better choice. You can stop containers using the volume, then back up the volume's directory (such as /var/lib/docker/volumes/).
Suitable for bind mounts scenarios
. Return to directory
. The host and container share configuration files. This is the DNS solution provided by Docker, which mounts the host's /etc/resolv.conf into each container.
The development environment requires sharing code between the host and the container. This is the case for the development of docker. After all, there is generally no editor in the container.
When the file or directory structure of the Docker host is guaranteed to be consistent with the bind mounts the containers require. It
is suitable for the scenario of tmpfs mounts .
Return to the directory
tmpfs mounts are mainly used When you don't want to save data either in the container or in the host file system. This may be for security reasons, or it may be that your application needs to write a lot of non-persistent data. In this case, tmpfs mounts can ensure container performance.

Using
the return to directory
volume(-v)
parameter –volume (or -v for short) can only create a bind mount. Example:

docker run --name $CONTAINER_NAME -it
-v /localhost/app:/container/app:rw
-v /localhost/app:/container/app:ro
nginx:latest /bin/bash
注释：

Command format: [Host directory:]Container directory[:OPTIONS]]]
If you specify the host directory, it must be an absolute path. If the path does not exist, it will be created automatically.
rw in the instance is read-write, and ro is read-only.

–mount

The parameter –mount is used to mount the volume by default, but can also be used to create bind mounts and tmpfs. If the type option is not specified, the default is to mount volume.

Volume is a more flexible data management method. Volume can be managed through the docker volume command set.

Example:

docker run --name $CONTAINE{R}_{N}AME-it--mounttype=bind,source=$PWD/$CONTAINE{R}_{N}AME/app,destination=/app--mountsource=${CONTAINER_NAME}-data,destination=/data,readonly
avocado-cloud:latest /bin/bash
注释：

Mount volume command format: [type=volume,]source=my-volume,destination=/path/in/container[,…]
Create bind mount command format: type=bind,source=/path/on/host,destination =/path/in/container[,…]
If you create a bind mount and specify the source, it must be an absolute path, and the path must already exist.
In the example, readonly means read-only
mount. There is a table of parameters in the official document:

original:

Propagation setting Description
shared Sub-mounts of the original mount are exposed to replica mounts, and sub-mounts of replica mounts are also propagated to the original mount.
slave similar to a shared mount, but only in one direction. If the original mount exposes a sub-mount, the replica mount can see it. However, if the replica mount exposes a sub-mount, the original mount cannot see it.
private The mount is private. Sub-mounts within it are not exposed to replica mounts, and sub-mounts of replica mounts are not exposed to the original mount.
rshared The same as shared, but the propagation also extends to and from mount points nested within any of the original or replica mount points.
rslave The same as slave, but the propagation also extends to and from mount points nested within any of the original or replica mount points.
rprivate The default. The same as private, meaning that no mount points anywhere within the original or replica mount points propagate in either direction.

Usage example:

docker run --name $CONTAINE{R}_{N}AME-it--mounttype=bind,source=$PWD/$CONTAINER_NAME/app,destination=/app,bind-Propagation=slave
avocado-cloud:latest /bin/bash

tmpfs
tmpfs is not stored persistently on the disk, nor is it stored in the Docker container. It is stored in the memory of localhost, and it can be used by the container throughout the container's life cycle.

Usage example:

docker run -d -it -p 80:80 --name tmptest
–mount type=tmpfs,destination=/usr/share/nginx/html
nginx:
All read and write operations on the directory by the latest container are in memory.

Specify the permissions of tmpfs:

docker run -d -it -p 80:80 --name tmptest
–mount type=tmpfs,destination=/usr/share/nginx/html,tmpfs-mode=1770
nginx:latest