Deep understanding of Docker Volume

This article mainly introduces the principle and usage of Docker volume, and is an extension of the Docker starter tutorial. The author introduces the working principle of volume from the data sharing, data container, backup, permission and delete Volume Five, and helps the reader to understand volume from the actual combat.

From the Docker IRC channel and StackOverflow, many people don't quite understand how Docker volume works. In this article, I'll try my best to explain how volume works, and show some of the greatest practices. This article is intended for Docker users who do not know about volume, and certainly experienced users can learn some of the volume details in this article.

If you want to learn about Docker Volume, first we need to know how Docker's file system works. Docker images are overlaid by multiple file systems (read-only layers). When we start a container, Docker loads the read-only mirror layer and adds a read-write layer on top of it (the translator's note: Mirror stack). If a running container modifies an existing file that already exists, it is copied from the read-only layer below the read-write layer to the read-write layer, and the read-only version of the file still exists, but is hidden by a copy of the file in the read-write layer. When you delete a Docker container and restart it through the mirror, the previous changes are lost. In Docker, the combination of read-only and top-level read-write layers is called the Union file System (federated filesystem).

To be able to save (persist) data and share data between containers, Docker presents the concept of volume. Simply put, volume is a directory or file that bypasses the default federated file system and is present on the host in the form of a normal file or directory.

There are two ways to initialize volume, and there are some small and important differences between the two ways. We can declare volume at run time using-V:

$ docker run-it--name container-test-h container-v/data Debian/bin/bash

root@container:/# Ls/data

root@container:/#

The above command mounts the/data to the container and bypasses the federated file system, and we can manipulate the directory directly on the host. Any files in the/data path of the image will be copied to volume. We can use the Docker inspect command to find where the volume is stored on the host:

$ docker inspect-f {{. Volumes}} container-test

You will see a similar output:

MAP[/DATA:/VAR/LIB/DOCKER/VFS/DIR/CDE167197CCC3E138A14F1A4F...B32CEC92E79059437A9]

This means that Docker has attached a directory under/var/lib/docker to the/data directory in the container. Let's add files from the host to this folder:

$ sudo touch/var/lib/docker/vfs/dir/cde167197ccc3e13814f...b32ce9059437a9/test-file

into our container you can see:

$ root@container:/# Ls/data

Test-file

As long as the directory of the host is attached to the directory of the container, the change takes effect immediately. We can achieve the same purpose in Dockerfile by using the VOLUME directive:

From Debian:wheezy

Volume/data

But there is another thing that only the-v parameter can do and dockerfile is not able to do is mount the specified host directory on the container. For example:

$ docker run-v/home/adrian/data:/data Debian Ls/data

This command mounts the host's/home/adrian/data directory to the/data directory in the container. Any files in the/home/adrian/data directory will appear inside the container. This is useful for sharing files between hosts and containers, such as mounting source code that needs to be compiled. To ensure portability (not all of the system's host directories are available), the Mount host directory does not need to be specified from Dockerfile. When you use the-v parameter, any files under the mirror directory are not copied to volume. (Translator Note: Volume will be copied to the mirror directory, the image will not be copied to the volume)
Data sharing

If you want to authorize a container to access the volume of another container, we can use the-volumes-from parameter to execute the Docker run.

$ docker run-it-h Newcontainer--volumes-from container-test Debian/bin/bash

root@newcontainer:/# Ls/data

Test-file

root@newcontainer:/#

It is important to note that it works regardless of whether the container-test is running. As long as the container is connected to the volume, it will not be deleted.
Data container

A common usage scenario is to use a pure data container to persist a database, configuration file, or data file. The official documentation is explained in detail. For example:

$ docker Run--name dbdata postgres echo "Data-only container for Postgres"

The command will create a postgres image containing the volume already defined in the Dockerfile, run the echo command and exit. When we run the Docker PS command, Echo can help us identify the purpose of an image. We can use the-volumes-from command to volume the other containers:

$ docker run-d--volumes-from dbdata--name db1 postgres

Two points of note using the data container:

Do not run the data container, which is purely a waste of resources.
Do not use "minimal mirroring" for data containers, such as busybox or scratch, just use database mirroring itself. You already have the image, so you don't need to take up extra space.

Backup

If you're using a data container, it's pretty easy to do backups:

$ docker Run--RM--volumes-from dbdata-v $ (PWD):/backup Debian tar cvf/backup/backup.tar/var/lib/postgresql/data

The example should compress everything in volume into a tar package (the official Postgres Dockerfile defines a volume in the/var/lib/postgresql/data directory)
Permissions and Licensing

Usually you need to set volume permissions or initialize some default data or configuration files for volume. The key point to note is that nothing after Dockerfile's VOLUME instruction can change the VOLUME, such as:

From Debian:wheezy

RUN useradd foo

Volume/data

RUN touch/data/x

RUN Chown-r Foo:foo/data

The Docker file runs as expected, and we would have liked the touch command to run on the mirrored file system, but it was actually running on the volume of a temporary container. As shown below:

From Debian:wheezy

RUN useradd foo

RUN Mkdir/data && touch/data/x

RUN Chown-r Foo:foo/data

Volume/data

Docker can mount the files under volume in the Mirror to volume and set the correct permissions. This behavior does not occur if you specify the host directory for volume.

If you do not set permissions through the RUN command, then you need to use CMD or entrypoint instructions when the container starts (the translator note: The cmd command is used to specify a container to run when it starts, similar to run, except that run is the command that the image runs at build time).
Delete Volumes

This feature may be more important if you have already used Docker RM to remove your container, there may be a lot of isolated volume still occupying space.

Volume can only be deleted if the following conditions are available:

The container can be removed with Docker rm-v and no other container is connected to the volume (and the host directory is not designated as volume). Note that-V is essential.
Using RM parameters in Docker run

Unless you're very careful and always run containers like this, you'll get some zombie files and directories in the/var/lib/docker/vfs/dir directory, and it's not easy to say what they represent.