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

This article is to share with you about the use of AUFS in Docker storage drivers. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Brief introduction

AUFS was the default preferred storage driver for Docker. It is very stable, with a lot of real-world deployment, and strong community support. It has the following main advantages:

Extremely short container startup time.

Effective storage utilization.

Effective memory utilization.

Even so, because it is not included in the Linux kernel mainline, many Linux distributions do not support AUFS.

Feature image tiering and deployment

AUFS is a federated file system. It uses multiple directories on the same Linux host and stacks them one by one to present a unified file system. AUFS uses this feature to achieve layering of Docker images. The following figure shows the layering of the mirror of ubuntu:latest.

Note: before Docker1.10, the ID of layer corresponds to its directory name under / var/lib/docker, but after Docker1.10, there is no longer such a direct correspondence.

For a container, only the top-level container layer is read-write, while the layer below is read-only.

Read and write files

Docker uses AUFS's CoW (Copy-on-Write) technology to achieve mirror sharing and minimize disk space usage. AUFS works at the file layer, which means that AUFS CoW copies the entire file-even if it modifies only a little bit. Therefore, it has a significant impact on the performance of the container, especially copying large files under multi-tier images, or searching in a deep directory tree.

However, in a given container, this copy to the top-level layer is done only once per file. Subsequently, the read and write operations on the file are only for the copy file of layer that can be read and written at the top level of the container.

Delete a file

Through the above introduction, it is easy to think of. If you want to delete a file that is not a top-level layer in the container, it will certainly not be deleted directly in the lower-level layer, because the lower-level layer is read-only to the container. The AUFS storage driver deletes a file by adding a whiteout file to layer at the top of the container. This whiteout file can hide the existence of files in the lower-level read-only layer, and the container is not aware of the existence of layer in the read-only layer. In fact, the container assumes that the file has been deleted, regardless of whether the file still exists in the lower read-only layer.

Rename directory

AUFS does not fully support the rename (2) rename operation and returns EXDEV ["cross-device link not permitted"], even if the source and destination paths are on the same AUFS layer. Therefore, your application needs to be able to handle EXDEV, and you can use the "copy and delete" strategy instead of rename operations.

I did a test here and wrote a simple C program that renamed directory test to directory gaga and printed out the results of rename. The program runs perfectly on an ordinary server, but what about in a container? Let's start the test.

Create the docker build directory and enter it. And create a subdirectory test under that directory. Mkdir build-rename$ cd build-rename$ mkdir test create file test.c$ vim test.c#include#include int main (void) {char oldname [100] = "test", newname [100] = "gaga"; int ret = rename (oldname, newname); if (ret = = 0) printf ("rename ok.\ n"); else printf ("ret =% d\ n", ret); return 0;}

Compile the program and generate the executable file a.out.

$gcc test.c creates Dockerfile$ vim DockerfileFROM ubuntuWORKDIR / usr/src/appCOPY. / * / usr/src/app/CMD / usr/src/app/a.out to generate an image. $docker build-t rename:v1.0. / run container $docker run-- rm rename:v1.0ret =-1

When the container starts, it executes the executable file a.out and renames a directory. As a result, rename did return a failure by renaming a directory.

Configure AUFS preparation

The AUFS storage driver can only be used if AUFS is installed in OS. Generally speaking, Debian/Ubuntu supports AUFS, while Redhat/CentOS does not support AUFS. So, you need to check to see if your system has AUFS installed.

$grep aufs / proc/filesystemsnodev aufs

If the above command has output, it supports AUFS, otherwise it means that AUFS is not installed. The following steps can be performed:

a. Upgrade the kernel version of your system to 3.13 or higher, and it is recommended to install kernel headers

b. For Ubuntu/Debian: install the linux-image-extra-* package:

$apt-get install linux-image-extra-$ (uname-r)\ linux-image-extra-virtual configuration

If the above is correct, you can use AUFS as the storage driver for your Docker Daemon.

$dockerd-storage-driver=aufs &

If you want to persist this configuration, you can edit your Docker configuration file (such as / etc/default/docker, although it is officially deprecated) and add the-storage-driver=aufs option to DOCKER_OPTS.

# Use DOCKER_OPTS to modify the daemon startup options.DOCKER_OPTS= "--storage-driver=aufs"

After restarting docker daemon (systemctl restart docker.service), confirm whether the default storage driver is configured successfully:

$docker info | grep "Storage Driver" Storage Driver: aufs local storage and AUFS

When dockerd uses the AUFS driver, the driver stores the images and containers in Docker host's local storage: / var/lib/docker/aufs.

Mirror image

The mirror layer is stored in / var/lib/docker/aufs/diff. After Docker 1.10, the directory name corresponding to the image no longer corresponds to the meaning of the mirror ID.

The / var/lib/docker/aufs/layers/ directory holds metadata information that shows how the image layers are superimposed. Each file in this directory corresponds to a layer, and the content of this file is the layer below that layer. Such as:

$cat / var/lib/docker/aufs/layers/91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267cd74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82c22013c8472965aa5b62559f2b540cd440716ef149756e7b958a1b2aba421e87d3a1f33e8a5a513092f01bb7eb1c2abf4d711e5105390a3fe1ae2248cfde1391

Since there are no other layers under the base layer, the contents of the files corresponding to all base layer are empty.

Container

The running container is mapped under / var/lib/docker/aufs/mnt/, which is a mount point that AUFS gives to the container and its underlying layer. If the container is not running, there is still this directory, but it is an empty directory, because AUFS is only mapped when the container is running. In the version above Docker 1.10, the directory name also does not correspond to the container ID.

Container metadata and various configuration files are stored in this directory.

$ls / var/lib/docker/aufs/mnt/670e0053b2ba02ab33dc24daca293e200aa98e871cefec016a5cbf9d41b7cfbfbin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

The writable layer of the container is stored in the directory / var/lib/docker/aufs/diff/,. Even if the container stops, the corresponding directory of the container still exists. Only when the container is deleted will the corresponding directory be deleted.

Performance of AUFS in Docker

For the PaaS layer, AUFS storage driver is a good choice. Because AUFS effectively shares images among multiple running containers, it speeds up the container startup time and reduces the disk space used by the container.

The underlying mechanism used by AUFS to share files between multiple mirror layers and containers uses the system's page cache efficiently.

At the same time, the AUFS storage driver also brings some hidden troubles in container write performance. This is because the first time the container modifies any file, it needs to locate the image level of the file and copy it to the read-write layer at the top of the container. Performance problems are especially serious when these files exist at a very low level, or when the files themselves are very large.

AUFS is the default storage driver for Docker in Ubuntu/Debian, although it may be replaced later. But for the time being, it fits perfectly with the characteristics of Docker. And, how to use it reasonably, its performance is very excellent. In addition, it should be noted that AUFS does not support directory renaming well, which should be noted when writing programs.

Thank you for reading! This is the end of this article on "what is the use of AUFS in Docker storage drivers?". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.