Detailed explanation of several storage methods of docker containers

Written in front

In the previous article, we learned about container networks and gave a relatively detailed introduction to the working principle of the container network driver bridge. Today, let’s take a look at another key area in the container - storage.

Container storage can be divided into two categories:

One is related to the image, which is the container layer Copy-On-Write feature mentioned in the article "Basics of Docker Container Technology: Union File System OverlayFS". By default, all files created in a container are stored on a writable container layer. This method of storing files directly in the container layer makes data difficult to persist and share. Due to the reliance on storage drivers, this additional abstraction reduces performance compared to using data volumes that write directly to the host file system.

The other is host storage, which is to bind or mount the host directory to the container for use, so that the data can persist even after the container is stopped. This short essay mainly introduces the latter.

Several storage mounting methods

Here we draw the following diagram based on the different locations where data is stored on the Docker host:

1.bind mounts

Bind mounts have limited functionality compared to volumes. When using a bind mount, a file or directory on the host is mounted into the container. A file or directory is referenced by its full path on the host machine. The directory does not need to already exist on the Docker host. If it does not exist, Docker will create it for us. Please note that only directories can be created automatically.

Let's bind-mount a directory /nginx/html to the container using the -v option.

docker run -dt -v /nginx/html:/usr/share/nginx/html --name nginx nginx

View the container Mounts field through docker inspect nginx

"Mounts": [
    {
        "Type": "bind",
        "Source": "/nginx/html",
        "Destination": "/usr/share/nginx/html",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    }
],

Next, we create an index.html on the docker host and write hello nginx, then access the container IP. Obviously, our mount has taken effect.

[root@localhost ~]# echo "hello nginx" > /nginx/html/index.html
[root@localhost ~]# curl 172.17.0.4
hello nginx

There is a problem here. We can modify files through the Docker host to make the files in the container take effect. Conversely, the container can modify, create, and delete the content on the host file system. To solve this problem, we can configure the permissions of the mount directory when creating the container, such as the following read-only permissions:

docker run -dt -v /nginx/html:/usr/share/nginx/html:ro --name nginx nginx

So when we use bind mount, you are operating the host file system, you must be aware of the following:

• What does the directory you mounted contain to avoid affecting other applications.
• Should your container have permissions to operate on these directories?
  

2. Volumes

Volume storage volumes are created and managed by Docker. We can create volumes explicitly using the docker volume create command, or create volumes when the container is created.

[root@localhost ~]# docker volume create nginx_volume
nginx_volume
[root@localhost volumes]# docker inspect nginx_volume
[
    {
        "CreatedAt": "2021-08-12T01:58:04-04:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/nginx_volume/_data",
        "Name": "nginx_volume",
        "Options": {},
        "Scope": "local"
    }
]

You can see that the mount point is in the root directory of docker /var/lib/docker/volumes

Clear single or all unused volumes with docker volume rm/prune. The ability to manage volumes with docker commands is an advantage over bind mounts.

[root@localhost ~]# docker volume ls
DRIVER VOLUME NAME
local owncloud-docker-server_files
local owncloud-docker-server_mysql
local owncloud-docker-server_redis
[root@localhost ~]# docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
owncloud-docker-server_files
owncloud-docker-server_mysql
owncloud-docker-server_redis
​
Total reclaimed space: 199.4MB

If the source of the container mount is not specified when creating a container, Docker will automatically create an anonymous volume for us, which is also located in the Docker root directory.

[root@localhost volumes]# docker run -dt -v /usr/share/nginx/html --name nginx_with_volume nginx
d25bdfce9c7ac7bde5ae35067f6d9cf9f0cd2c9cbea6d1bbd7127b3949ef5ac6
[root@localhost volumes]# docker volume ls 
DRIVER VOLUME NAME
local d8e943f57d17a255f8a4ac3ecbd6471a735aa64cc7a606c52f61319a6c754980
local nginx_volume
[root@localhost volumes]# ls /var/lib/docker/volumes/
backingFsBlockDev d8e943f57d17a255f8a4ac3ecbd6471a735aa64cc7a606c52f61319a6c754980 metadata.db nginx_volume

When we create a mounted volume, the storage is consistent with bind mounts. However, when the Docker host cannot guarantee a given directory or file structure, the volume can help us separate the configuration of the Docker host from the container runtime. This way, when we need to back up, restore, or migrate data from one Docker host to another, volumes are very convenient and can be freed from the limitations of the host path.

When using bind mounts and volumes we must pay attention to the following propagation overlay principles:

When mounting an empty volume: the contents of the directory inside the container are propagated (copied) to the volume.

When bind-mounting or non-empty volumes: The contents of the directory inside the container will be overwritten by the volume or bound host directory.

3.tmpfs mount

tmpfs mounts are only available on linux hosts, when we create a container with a tmpfs mount, the container can create files outside of the container's writable layer. Keep the data in memory, and when the container stops, the written data will also be removed. Mainly used for temporary storage of sensitive files that you don't want to remain in the host or container writable layer.

Mount a memory block with the --tmpfs option.

docker run -dt --name busybox_tmpfs --tmpfs /etc/running busybox

Use the --mount method to bring parameters and specify the temporary storage size.

docker run -dt --name busybox_tmpfs2 --mount type=tmpfs,tmpfs-size=2048,destination=/etc/running busybox

Storage data sharing

There are two main ways to share data between containers. The first one is relatively simple and only requires mounting a directory or volume into multiple containers. I won't go into details here. Let's take a look at how to achieve sharing through an intermediate container.

We create an intermediate container that contains the bind mounted directory and a volume.

docker create -v /share:/volume1 -v /volume2 --name volume_share busybox

In the container we need to share, we can use the option --volumes-from to get it.

docker run -d -t --volumes-from volume_share --name container1 busybox

Let's inspect the Mounts field. At this time, container1 has been mounted to a bind directory and a volume.

"Mounts": [
    {
        "Type": "bind",
        "Source": "/share",
        "Destination": "/volume1",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
    },
    {
        "Type": "volume",
        "Name": "21605e49a0ba90a1b952a32c1b3f0d42735da8bfe718f0dc76c37e91f1e51c0e",
        "Source": "/var/lib/docker/volumes/21605e49a0ba90a1b952a32c1b3f0d42735da8bfe718f0dc76c37e91f1e51c0e/_data",
        "Destination": "/volume2",
        "Driver": "local",
        "Mode": "",
        "RW": true,
        "Propagation": ""
    }
],

This is all we have learned about Docker container storage. I hope this short article will be useful to you when you need it.

This concludes this article on several storage methods for docker containers. For more information about docker container storage, please search previous articles on 123WORDPRESS.COM or continue browsing the following related articles. I hope you will support 123WORDPRESS.COM in the future!