Detailed Introduction to Docker Storage Driver

Detailed Introduction to Docker Storage Driver

Recently, during the project, I was not familiar with Docker storage drivers, so I found information on the Internet and solved it. Here, I record it.

Purpose

1. Understanding the storage method of docker
2. The directory structure of docker image and container on the host
3. The content and configuration of docker image and container are stored differently
   

Docker is an open-source application container engine that mainly utilizes Linux kernel namespace for sandbox isolation and Cgroup for resource limitation. Docker is used for lightweight Linux containers for unified development and deployment, trying to solve the problem of 'dependency hell', combining dependent services and components together, similar to shipping containers used in shipping, achieving quick installation and deployment.

1. Basic architecture of Docker — Client and Daemon

Let's first understand the basic architecture and startup process of docker, in fact Docker uses C/The architecture includes both the client and the server. The Docker daemon acts as the server to accept requests from clients and process these requests (create, run, commit containers). The client and server are on the same machine and communicate through RESTful API. Specifically, during the process of executing service docker start, a docker deamon process is generated on the host (host), running in the background and waiting to receive messages from the client (i.e., the input docker commands such as docker pull xxx, docker run ..., docker commit xxx), to achieve interaction with the docker deamon. After starting the docker service, you can see the docker process.

Default

[root@localhost ~]# ps -aux | grep docker
root  11701 0.0 0.4 359208 16624 ?  Ssl 21:05 0:00 /usr/bin/docker -d -H fd:// --selinux-enabled --insecure-registry 186.100.8.216:5000
root  11861 0.0 0.0 113004 2256 pts/0 S+ 23:01 0:00 grep --color=auto docker

This is mainly to specify the filesystem later, you need to do this first /etc/sysconfig/Configure the specific storage driver for Docker (this will be written in a separate Blog), and then start the Docker Daemon, and cannot be operated through the parameters of the run command. It can also be directly set on the host command line using docker –d.

2. Docker's storage method—Storage Driver

The core part of the Docker model is the effective use of the layered image mechanism, which can be inherited through layering. Based on the base image (without parent image), various specific application images can be created. Different Docker containers can share some basic filesystem layers, and with their own unique modification layers, it greatly improves storage efficiency. The main mechanism is the layered model and mounting different directories into the same virtual filesystem (unite several directories into a single virtual filesystem, from this article). For image storage, Docker uses several different storage drivers, including: aufs, devicemapper, btrfs, and overlay (from the official website). Below is a brief introduction to different storage drivers.

AUFS

AUFS (Another UnionFS) is a union file system. AUFS supports setting read-only (readonly), read-write (readwrite), and write-only (whiteout) permissions for each member directory (similar to Git branches).-permission, and AUFS has a similar hierarchical concept, which can logically incrementally modify the branches with read-only permissions (without affecting the read-only parts). The unique storage driver of AUFS can implement shared executable and shareable runtime libraries between containers, so when running thousands or even hundreds of containers with the same program code or runtime libraries, AUFS is a very good choice.

Device mapper

Device mapper is a Linux 2.6 A mapping framework mechanism provided in the kernel from logical devices to physical devices, under which users can conveniently formulate the implementation of storage resource management strategies according to their own needs (see details). The device mapper driver will create a100G simple file containing your image and container, each container is restricted in10G-sized volume (note: this is a sparse file created automatically using loopback, specifically) /var/lib/docker/devicemapper/devicemapper's data and metadata can be dynamically expanded. You can adjust the size of Docker containers, for more details refer to ） You can use parameters when starting the docker daemon-s Specify the driver, which means you can docker -d -s devicemapper sets the Docker storage driver. First, stop the Docker service and execute the command:

Default

[root@localhost ~]# docker -d -s devicemapper
INFO[0000] +job serveapi(unix:///var/run/docker.sock) 
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock) 
INFO[0000] +job init_networkdriver()     
INFO[0000] -job init_networkdriver() = OK (0)   
INFO[0000] Loading containers: start.     
....
INFO[0000] Loading containers: done.     
INFO[0000] docker daemon: 1.4.0 4595d4f/1.4.0; execdriver: native-0.2; graphdriver: devicemapper 
INFO[0000] +job acceptconnections()      
INFO[0000] -job acceptconnections() = OK (0)

Additionally, docker can specify –storage when starting containers-The opt parameter, but currently only devicemapper can accept parameter settings. There will be targeted Blog posts in the future.

BTRFS

The Btrfs Driver can be very efficient in docker build. However, like devicemapper, it does not support shared storage between devices (see official website). Btrfs supports creating snapshots and clones, and can also manage multiple physical devices conveniently. (For more information, refer to IBM's introduction to Btrfs)

overlay

overlay is very similar to AUFS, but it has better performance and good memory utilization, and has now been merged into the Linux kernel3.18. Specific command usage: docker –d –s overlay

Official website note: It is currently unsupported on btrfs or any Copy on Write filesystem and should only be used over ext4 partitions.

3 Docker directory structure

The two most important concepts of Docker are images and containers. Where are the images we pull stored? Where are the modifications we make stored after the container is started? Since the specific drivers are different, the final implementation effect is different. Below, we take the Device Mapper storage driver as an example to analyze the storage structure of Docker.

1. Enter /var/lib/List the contents of the docker directory:

Default

[root@localhost ~]# cd /var/lib/docker/
[root@localhost docker]# ls
containers devicemapper execdriver graph init linkgraph.db repositories-devicemapper tmp trust volumes

According to the content of the directory, it can be clearly seen that devicemapper driver is used.

Note: The following folders are all in/var/lib/in the docker.

2. Where is the pulled image file stored? (Reference)

The information of the pulled images is stored in the graph folder, and the content of the images is stored in devicemapper/ devicemapper/data.

3. Where does the started container run?

The configuration information of the started container is stored in containers, and there is also execdriver/native/ .

The content of the operations performed in the container is stored in devicemapper/devicemapper/data.

4. The role of graph

In the Docker architecture, it acts as a guardian for the downloaded container images and as a recorder of the relationships between the downloaded container images. In the local directory of graph, the specific information stored about each container image includes: the metadata (json) of the container image, the size (layersize) information of the container image, and the specific rootfs represented by the container image.

5. Experimental testing:

- No containers started initially:

Default

[root@localhost docker]# ll containers/
total 0

- Start a container:

Default

[root@localhost docker]# docker run -i -t --rm centos:7 /bin/bash
[root@187a8f9d2865 /#

]187a8f9d2865

- The UUID of the container started=/var/lib/docker/devicemapper/devicemapper/before starting the container, view

Default

[root@bhDocker216 docker]# du -h devicemapper/devicemapper/*
2.1G devicemapper/devicemapper/data
3.5M devicemapper/devicemapper/metadata

- View the actual size of the file under

Default

[root@bhDocker216 docker]# ls containers/
187a8f9d2865c2ac***91b981

View the content under the UUID folder of the running container:

Default

[root@bhDocker216 containers]# ll 187a8f9d2865c2ac***91b981
total 24
-rw-------. 1 root root 273 Mar 5 23:59 187a8f9d2865***-json.log
-rw-r--r--. 1 root root 1683 Mar 5 23:58 config.json
-rw-r--r--. 1 root root 334 Mar 5 23:58 hostconfig.json
-rw-r--r--. 1 root root 13 Mar 5 23:58 hostname
-rw-r--r--. 1 root root 174 Mar 5 23:58 hosts
-rw-r--r--. 1 root root 69 Mar 5 23:58 resolv.conf
- Add a file to the running container and view it.

First create a file inside the running container:

Default

[root@8a1e3ad05d9e /]# dd if=/dev/zero of=floppy.img bs=512 count=5760
5760+0 records in
5760+0 records out
2949120 bytes (2.9 MB) copied, 0.0126794 s, 233 MB/s

Then in/var/lib/docker/devicemapper/devicemapper/View the file below:

Default

[root@bhDocker216 docker]# du -h devicemapper/devicemapper/*
5.5G devicemapper/devicemapper/data
4.6M devicemapper/devicemapper/metadata

There is a bit of difference in size here because # dd if= was executed first/dev/zero of=test.txt bs=1M count=8000, create a8G-sized file, since it was too slow I terminated it, but it can be clearly seen that two folders have changed (increased) in the running container.

- Check graph, after pulling only one image (Ubuntu14.10) in this case, there was7directory named with a long UUID, how did this come about?

List the image tree structure with docker images –tree, and we can see the layered storage structure of the image. The final Ubuntu (the7The layer) is based on the6The layer modifications, that is, the base layer in the logical tree based on the logic of the nth layer is the nth-1The layer modifications, n layers depend on n-1The image of the layer. The 0th layer, with a size of 0, is called the base image.

- graph/What is the content under the UUID directory?

Default

[root@localhost graph]# ll 01bf15a18638145eb*** -h
total 8.0K
-rw-------. 1 root root 1.6K Mar 5 18:02 json
-rw-------. 1 root root 9 Mar 5 18:02 layersize

Check the content of layersize: The number represents the size of the layer (unit: B). josn: It saves the metadata of this image (such as: size, architecture, config, container,**parent's UUID** etc.).

- View devicemapper/devicemapper folder

There are two folders data and metadata, in fact, the device mapper driver is to store the files of the image and container in **data** This file. You can check the size of data and metadata by docker info. In addition, you can use du –h (used above) to view the actual size of these sparse files.

- execdriver

Default

[root@bhDocker216 docker]# ls execdriver/native/
8a1e3ad05d9e66a455e683a2c***2437bdcccdfdfa
//View the contents inside:
[root@bhDocker216 8a1e3ad05d9e66a455e***]# ls
container.json state.json

- volumes

not added-The v parameter's volumes are empty, after testing, if the container is started without adding-The v parameter, a UUID will be displayed under the volumes folder, it is searched globally in the host, only found in the volumes folder, and has nothing to do with the UUID of the image and container.

Default

[root@bhDocker216 docker]# find / -name 86eb77f9f5e25676f100***d5a
/var/lib/docker/volumes/86eb77f9f5e25676f100***d5a
//View the contents inside:
[root@bhDocker216 volumes]# ls 86eb77f9f5e25676f100***d5a
config.json
[root@bhDocker216 volumes]# cat 86eb77f9f5e25676f100***d5a /config.json 
{"ID":"86eb77f9f5e25676f100a89ba727bc15185303236aae0dcf4c17223e37651d5a","Path":"/home/"data","IsBindMount":true,"Writable":true}

Table of folder roles for description

Make a summary, make a table, and put/var/lib/The following is the description of the role of different folders under docker:

Thank you for reading, I hope it can help everyone. Thank you for your support of this site!