Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to use Docker volumes". In daily operation, I believe many people have doubts about how to use Docker volumes. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "how to use Docker volumes"! Next, please follow the editor to study!

Docker supports both persistent and non-persistent storage.

Non-persistent storage is automatically created, belongs to the container, and has the same life cycle as the container, that is, deleting the container will also delete all non-persistent data. If you want to preserve the data in the container, that is, persistence, you need to store the data on the volume. The volume is decoupled from the container so that the volume can be created and managed independently, and the volume is not bound to any container declaration cycle, that is, the user deletes a container associated with the volume, but the volume is not deleted. Non-persistent storage

Each container is automatically allocated local storage. By default, all files and directories in the container are stored with this. Non-persistent storage is part of the container and is the same as the lifecycle of the container-non-persistent storage is created when the container is created, and it is deleted as the container is deleted.

On Linux systems, the storage directory is under / var/lib/docker/ and is part of the container. This storage-driver refers to the storage driver to be used. If you want to run Docker using Linux in a production environment, you need to verify that the current storage driver conforms to the current Linux version:

The Overlay2 driver is used in RedHat Enterprise Linux:Docker 17.06 or later. Ubuntu: use Overlay2 or AUFS drivers. If you are using Linux 4.x or later kernels, Overlay2 is recommended.

Overall, Overlay2 drivers are becoming more and more popular and may become the recommended storage drivers on most platforms in the future.

Persistence

Volumes are recommended for persisting data in containers, that is, volumes are created first, and then mounted to the container. At this point, the volume is mounted to a directory in the container file system, and anything written to that directory is written to the volume. Even if the container is deleted, the volume and the data on it still exist.

As shown in the following figure, the Docker volume is mounted to the container's / code directory, so any data written to the / code directory is actually written to the Docker volume, and the Docker volume still exists after the container is deleted. Other directories use temporary local storage.

★

A volume is essentially a directory on a Docker host. This means that the container can no longer only access the container's file system, but also the file system where the Docker host resides.

"see how to create and view volumes docker volumn create myvol # create a volume named myvol

By default, Docker uses the built-in local driver when creating new volumes, which means that the created volume can only be used by the Docker host where the container resides (the local driver is used above).

In addition to local drivers, you can also use the-d parameter to specify different drivers. Third-party drivers can also be accessed through plug-ins, which provide advanced storage features and integrate external storage systems for Docker. Volume plug-ins cover block storage, file storage, object storage and so on.

Block storage: relatively high performance, suitable for random access load of small blocks of data. Such as Amazon EBS or OpenStack block storage services. File storage: systems that include NFS and SMB protocols perform well in high-performance scenarios. Such as NetApp FAS, Azure file storage. Object storage: suitable for large, long-term storage of binary data with few changes. Typically, object storage is addressable based on content and has low performance. Such as Amazon S3. Docker volumn ls

Docker volumn inspect [VOLUMN_NAME]

The inspect command outputs the details of the corresponding volume. Both Driver and Scope are local, which means that the volume is created using the default local driver and can only be used for containers on the current Docker host. "Mountpoint represents the location of the volume on the Docker host, and volumes created with local drives have dedicated directories on the Docker host." In Linux, it is located in the / var/lib/docker/volumes directory.

[

{

"CreatedAt": "2020-09-28T16:07:25+08:00"

"Driver": "local"

"Labels": {}

"Mountpoint": "/ var/lib/docker/volumes/myvol/_data"

"Name": "myvol"

"Options": {}

"Scope": "local"

}

]

★

Volumes can be deployed using VOLUMN directives in Dockerfile. It is important to note that the host directory cannot be specified in Dockerfile, because the host directory is usually a directory relative to the host (that is, the directory related to the host), so this directory will vary from host to host and may cause the build to fail. If specified through Dockerfile, the host directory needs to be specified for each deployment.

"the volume uses docker container run-it-- name voltainer-- mount source=bizvol,target=/vol alpine

The above command creates a new stand-alone container and mounts the / vol directory inside the container to a volume named bizvol. Similarly, if there is no volume called bizvol in the system, this command will also create one; if it already exists, use it.

Suppose that if we delete the container, then the volume bizvol is still there. Also, the data you write to the / vol directory while the container is running is also in this volume. As shown below, write a piece of data to / vol/file while the container is running, then exit and delete the container. After that, look at the directory where the volume is located and find that the created file and the written data are still there.

In-depth

The above description of the volume is more from the perspective of persistence, and another important function of the volume is to "open" the container file system and the host file system, so that the files created in the specified directory in the container can be accessed by the host, and the files in the specified directory on the host can be accessed by the processes in the container. So how do you do this?

The binding and mounting (bind mount) mechanism of Linux is mainly used here. Its main function is to mount a directory or file to a specified directory. Moreover, anything you do at the mount point will only occur on the mounted directory or file, while the contents of the original mount point will be hidden and unaffected. Binding mount is actually a process of inode replacement. For example, executing mount-- bind / home / test will mount / home on / test as bind. This is actually equivalent to redirecting / test to the inode of / home. So when we modify the / test directory, we actually change the inode of the / home directory.

Therefore, we only need to mount the host directory specified by volume to the corresponding directory on the host after the container process is created and the container rootfs is ready, but before chroot (because the container process can always see the entire file system on the host, and because the container has been created when the mount operation is performed So at this point, mount namespace is already on, so the mount event is only visible in the container.

★

The container process here is a container initialization process (dockerinit) created by Docker, not an application process (ENTRYPOINT+CMD). Dockerinit is responsible for preparing the root directory, mounting devices and directories, configuring hostname, and a series of initialization operations that need to be done in the container. Finally, through the execv () system call, let the process replace itself and become the process of PID=1 in the container.

"

Since the volume is mounted to the specified container directory and the corresponding directory on the host is located in the read / write layer, will it be submitted during docker commit? No, I won't. This is mainly because the docker commit occurs in the host space, while the mount occurs in the container, and due to the isolation of the mount namespace, the mount does not affect the host, that is, it is not mounted on the host. Therefore, only an empty directory will be committed at the time of submission, because / test is actually created in the read-write layer (this new creation is not affected by mount namespace, because mount namespace only affects mount-related).

Let's experiment. First start a container and have the container use a volume and mount it in the / test directory in the container. Then create a new file called test.txt in the container's / test directory.

Then go to the location where the volume is located to see if the corresponding test.txt file is created, and the result shows that the test.txt file is created. After that, we go to the directory corresponding to the read / write layer to see if there are test.txt files. The results show that there are test directories, but there are no test.txt files. Therefore, when docker commit, only an empty test directory will be submitted.

Common commands summarize # to create a volume named myvol. By default, new volume creation starts with local, but you can also use-d to specify a different driver

Docker volumn create myvol

# list all volumes on the local Docker host

Docker volumn ls

# View the details of the volume. You can use this command to view the specific location of the volume in the Docker host file system

Docker volumn inspect [VOLUMN_NAME]

# Delete all volumes that are not mounted to a container or service, and cannot delete volumes that are being used by a container or service

Docker volumn prune

# Delete the specified volume. You cannot delete the volume that is being used by the container or service

Docker volumn rm [VOLUMN_NAME]

# creates a new container and mounts the / vol directory inside the container to a volume named bizvol. If the / vol directory does not exist in the container's file system, it will be created; if it already exists, it will be used (the contents of this directory will then become the contents of the volume). Similarly, if there is no volume called bizvol in the system, this command will also create one; if it already exists, use it.

Docker container run-it-name voltainer-mount source=bizvol,target=/vol alpine

Docker run-v / test...

# Mount the host's / home directory to the container's / test directory

Docker run-v / home:/test...

At this point, the study on "how to use Docker volumes" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.