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

With the advent of the comprehensive cloud era, many companies have embarked on the containerization road, and Lao Liu's company is no exception. As a start-up Internet company, containerization does bring a lot of convenience and reduce the cost of the company, but Lao Liu has a worry. Xiao Wang, who used to get off work with him every day, has left work an hour earlier than him since the company went to the cloud. Everyone has the same work on hand, and it is wrong to be reasonable. after many explorations, tracking and investigation, Lao Liu finally found out where the secret is.

As a developer, there are always N test versions for debugging every day. After containerization, each version needs to be mirrored. Lao Liu found that it takes 20 minutes for him to make a mirror image, while Xiao Wang only takes 10 minutes. This is the only thing that is different by comparison!

Who on earth is Storage-Dirver? Why can it lead to a difference in build time? Now let's take a look.

Before we can answer this question, we need to answer three questions-what is a mirror image? What is a mirror build? What is storage-driver?

What is a mirror image?

When it comes to images, you can't get around the container. Let's first take a look at a picture from the official explanation of the image and the container:

After reading it is not more confused, we can be so simple and rough to understand that the mirror image is a stack of read-only layers. There is another simple and rude explanation for what is in the reading layer: there is a pile of altered files in it. This explanation may not be accurate under different storage-driver, but we can understand it so simply.

That's not right. When executing the container, you can obviously modify and delete the files in the container. How can you modify it if it is read-only? In fact, when we run the container, we add another read-write layer on top of that pile of read-only layers, and all operations are carried out in this read-write layer. When we need to modify a file, we will copy the file that needs to be modified from the bottom layer to the read-write layer and then modify it. If it is deleted, isn't there any way to delete the underlying files? Yes, there is no way to delete, but only need to hide the file in the upper layer, you can achieve the effect of deletion. Officially, this is Docker's write-time replication strategy.

To deepen your understanding of the mirror layer, let's take a chestnut and build an etcd image with the following Dockerfile:

After the build is completed, the following layer files are generated:

Every time I enter the container, I feel like I have entered a virtual machine, which contains the various system directories of linux. Is there a layer of directories that contain all the linux system directories?

Bingo got it right! The lowest layer directory does contain all the system directory files for linux.

There is a step in the above Dockerfile

ADD. / go/src/github.com/coreos/etcd

Copy the files from the external directory to the image, so what exactly is saved in this layer of image?

Open it and find that there is only one inside.

/ go/src/github.com/coreos/etcd this directory, the directory where the copied files are stored.

Is there a sense of a leopard in the pipe here? next, let's learn what mirror construction is, so we can basically get a glimpse of the whole picture.

What is a mirror build?

From the content of the first section, we know that the image is made up of a bunch of layer directories, and each layer directory contains the modified files of this layer. image construction is simply the process of making and generating mirror layers. so how is this process realized? The following figure flow is an example:

Docker Daemon first uses the basic image ubuntu:14.04 to create a container environment. Through the contents of the first section, we know that the top layer of the container is a read-write layer, in which we can write and modify. Docker Daemon first executes the RUN apt-update get command, and after the execution is completed, the contents of this read-write layer are saved into a read-only mirror layer file through the commit operation of Docker. Then continue to execute the ADD run.sh command on the basis of this layer, and then continue to commit into a mirror layer file after the execution is completed, and repeat until all the Dockerfile commands are submitted, and the image is done.

Here we can explain why there is only one go directory in a layer directory in etcd, because the build process is committed layer by layer, and only the files for the changes involved in this layer are saved in each layer.

So the mirror build is a process of repeatedly executing commands according to the Dockerfile startup container and saving it as a read-only file, so why is the speed different? Next, we have to talk about storage-driver.

What is storage-driver?

Let's review this picture again:

As we already know, the image is superimposed by one layer directory after another, and the container runtime only adds another read-write layer to it, and a write-time replication policy ensures that the contents of the underlying files can be modified at the top level. so how do these principles come true? It depends on storage-driver!

A brief introduction to three commonly used storage-driver:

AUFS

AUFS stacks multiple layer files by joint mounting to form a unified whole to provide a unified view. When reading and writing in the read and write layer, first check whether the file exists in this layer, if not, then look down layer by layer. The operation of aufs is based on files. When you need to modify a file, regardless of its size, the entire file will be copied from the read-only layer to the read-write layer. Therefore, if the file to be modified is too large, it will slow down the execution of the container. The official recommendation of docker is to mount large files instead of putting them in the mirror layer.

OverlayFS

OverlayFS can be considered as an upgraded version of AUFS. The files in the mirror layer of the container run form a lower-level directory by means of hard links, while the container layer works in the upper directory, the upper directory is read-write, and the lower directory is read-only. Due to the use of a large number of hard links, OverlayFS may run out of inode. Overlay2 optimizes this problem. And the performance has been greatly improved, but Overlay2 also has the same disadvantages as AUFS-it is slow to operate on large files.

DeviceMapper

There are great differences in implementation between DeviceMapper and the first two kinds of Storage-driver. First of all, each layer of DeviceMapper holds a snapshot of the previous layer, and secondly, the operation of DeviceMapper on data is no longer file-based but block-based.

The following figure shows the process of devicemapper reading files at the container layer:

First find the pointer to the underlying file in the snapshot of the container layer.

Then read the data from the data block pointed to by the lower 0xf33 location pointer to the storage area of the container

Finally, the data is returned to app.

When writing data, you also need to apply for 1 million 64K container snapshots according to the size of the data, which is used to save the copied block data.

DeviceMapper's block operation looks beautiful, but in fact, there are many problems. For example, frequently manipulating smaller files requires constantly allocating the database from the resource pool and mapping it to the container, so the efficiency becomes very low, and DeviceMapper needs to copy all the mirror layer information into memory every time the mirror runs, which takes up a lot of memory space when starting multiple mirrors.

We conducted a set of build tests with the dockerfile of the above etcd for different storage-driver

File storage system single build time concurrently 10 times average build time DevivceMapper44s269.5sAUFS8s26sOverlay210s269.5s

Note: the test results of this data may vary greatly depending on dockerfile, operating system, file system and network environment.

We found that in this experimental scenario, DevivceMapper is obviously inferior to AUFS and Overlay2 in time, while AUFS and Overlay2 are basically the same, of course, this data can only be used as a reference, and the actual construction is also affected by the specific Dockerfile content, operating system, file system, network environment and other aspects, so how to minimize the build time to improve our work efficiency?

Let's see the next decomposition!

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.