What is the earliest storage engine supported by docker?

AUFS is the earliest storage engine supported by docker. AUFS is a Union File System, which is a file-level storage driver. It was the storage driver used in the early days of Docker. It was recommended before Docker version 18.06 and Ubuntu version 14.04. It supports xfs and ext4 files.

The operating environment of this tutorial: linux7.3 system, docker version 20, Dell G3 computer.

AUFS is the earliest storage engine supported by docker.

Docker’s storage engine

Docker’s storage engine is designed like this, but for different file systems, it is composed of different Storage driver to achieve. Next let’s talk about Docker’s storage driver.

Docker mainly has the following types of storage drivers:

• overlay2: It is the recommended storage driver for the current version and can achieve excellent performance without additional dependencies and configurations. . Replaced the overlay storage driver after version 18.09. Support xfs, ext4 file system.

• aufs: The earliest storage driver used by Docker, which is recommended before Docker 18.06 version and Ubuntu 14.04 version. Support xfs, ext4 file system.

• devicemapper: It is the recommended storage driver for earlier versions of CentOS and RHEL systems, because they do not support overlay2 and require direct-lvm support.

• btrfs: For btrfs file systems only.

• zfs: Only for zfs file systems.

• vfs: Does not depend on the file system, but the performance is extremely poor, mainly used for testing.

It should be noted that the overlay2, overlay, and aufs layers are based on files. When the write concurrency of a single file is high, large memory support is required, and the read and write layers may be A single file becomes very large. The layers of devicemapper, btrfs, and zfs are based on block storage, so they have little impact on the high concurrency of a single file. But btrfs and zfs are very memory intensive.

docker AUFS

AUFS is a Union File System. The so-called UnionFS is to merge and mount directories in different physical locations into the same directory. . One of the most important applications of UnionFS is to jointly mount a CD/DVD and a hard disk directory. Then, you can modify the files on this read-only CD/DVD (of course, the modified files are stored in in a directory on the hard drive).

AUFS was also called Another UnionFS, and later it was called Alternative UnionFS. Later, it may not be domineering enough, so it was called Advance UnionFS. Developed by Junjiro Okajima in 2006, AUFS completely rewrote the early UnionFS 1.x. Its main purpose was for reliability and performance, and it introduced some new features, such as writable branches. Load balancing. AUFS is fully compatible with UnionFS in use, and is much better in stability and performance than the previous UnionFS. Later, UnionFS 2.x began to copy the functions of AUFS. But he actually didn't get into the Linux trunk because Linus wouldn't let him. Basically, it was because the amount of code was relatively large and it was poorly written (compared to only 3,000 lines of union mount and 10,000 lines of UnionFS, and others, which averaged only 6,000 VFS has about 30,000 lines of code, and AUFS actually has 30,000 lines of code). Therefore, Okajima continued to improve the code quality, kept submitting, and was constantly rejected by Linus. Therefore, to this day, AUFS cannot enter the Linux trunk (today you can see The code to AUFS is actually pretty good, N times better than OpenSSL. Either Linus has very high requirements for code quality, or Linus just doesn't like AUFS).

However, fortunately, many distributions use AUFS, such as: Ubuntu 10.04, Debian6.0, Gentoo Live CD supports AUFS, so it is OK.

Okay, after all this gossip, let’s look at an example (environment: Ubuntu 14.04)

First, we create two directories (fruits and vegetables), and in these two Put some files in a directory. The fruits include apples and tomatoes, and the vegetables include carrots and tomatoes.

$ tree
.
├── fruits
│   ├── apple
│   └── tomato
└── vegetables
    ├── carrots
    └── tomato

Then, we enter the following command:

# 创建一个mount目录
$ mkdir mnt

# 把水果目录和蔬菜目录union mount到 ./mnt目录中
$ sudo mount -t aufs -o dirs=./fruits:./vegetables none ./mnt

#  查看./mnt目录
$ tree ./mnt
./mnt
├── apple
├── carrots
└── tomato

We can see that there are three files in the ./mnt directory, apple, carrots and tomatoes. The fruit and vegetable directories are unioned into the ./mnt directory.

Let’s modify the content of the file:

$ echo mnt > ./mnt/apple
$ cat ./mnt/apple
mnt
$ cat ./fruits/apple
mnt

In the above example, we can see that the content of ./mnt/apple has been changed, and the content of ./fruits/apple has also been changed. .

$ echo mnt_carrots > ./mnt/carrots
$ cat ./vegetables/carrots 

$ cat ./fruits/carrots
mnt_carrots

In the above example, we can see that we modified the file content of ./mnt/carrots, but ./vegetables/carrots did not change. Instead, carrots appeared in the directory ./fruits/carrots. file, its content is what we have in ./mnt/carrots.

In other words, in the mount aufs command, we did not refer to the directory permissions of vegetables and fruits. By default, the first (leftmost) directory on the command line is readable and writable. , everything after is read-only. (Generally speaking, the first directory should be writable, and the following directories should be read-only)

So, if we specify permissions to mount aufs as follows, you will find that there is no The same effect (remember to delete the above ./fruits/carrots file first):

$ sudo mount -t aufs -o dirs=./fruits=rw:./vegetables=rw none ./mnt

$ echo "mnt_carrots" > ./mnt/carrots 

$ cat ./vegetables/carrots
mnt_carrots

$ cat ./fruits/carrots
cat: ./fruits/carrots: No such file or directory

现在，在这情况下，如果我们要修改./mnt/tomato这个文件，那么究竟是哪个文件会被改写？

$ echo "mnt_tomato" > ./mnt/tomato 

$ cat ./fruits/tomato
mnt_tomato

$ cat ./vegetables/tomato
I am a vegetable

可见，如果有重复的文件名，在mount命令行上，越往前的就优先级越高。

你可以用这个例子做一些各种各样的试验，我这里主要是给大家一个感性认识，就不展开试验下去了。

那么，这种UnionFS有什么用？

历史上，有一个叫Knoppix的Linux发行版，其主要用于Linux演示、光盘教学、系统急救，以及商业产品的演示，不需要硬盘安装，直接把CD/DVD上的image运行在一个可写的存储设备上（比如一个U盘上），其实，也就是把CD/DVD这个文件系统和USB这个可写的系统给联合mount起来，这样你对CD/DVD上的image做的任何改动都会在被应用在U盘上，于是乎，你可以对CD/DVD上的内容进行任意的修改，因为改动都在U盘上，所以你改不坏原来的东西。

我们可以再发挥一下想像力，你也可以把一个目录，比如你的源代码，作为一个只读的template，和另一个你的working directory给union在一起，然后你就可以做各种修改而不用害怕会把源代码改坏了。有点像一个ad hoc snapshot。

Docker把UnionFS的想像力发挥到了容器的镜像。你是否还记得我在介绍Linux Namespace上篇中用mount namespace和chroot山寨了一镜像。现在当你看过了这个UnionFS的技术后，你是不是就明白了，你完全可以用UnionFS这样的技术做出分层的镜像来。

下图来自Docker的官方文档Layer，其很好的展示了Docker用UnionFS搭建的分层镜像。

关于docker的分层镜像，除了aufs，docker还支持btrfs, devicemapper和vfs，你可以使用 -s 或 storage-driver= 选项来指定相关的镜像存储。在Ubuntu 14.04下，docker默认Ubuntu的 aufs（在CentOS7下，用的是devicemapper，关于devicemapper，我会以以后的文章中讲解）你可以在下面的目录中查看相关的每个层的镜像：

/var/lib/docker/aufs/diff/<id>

AUFS的一些特性

AUFS有所有Union FS的特性，把多个目录，合并成同一个目录，并可以为每个需要合并的目录指定相应的权限，实时的添加、删除、修改已经被mount好的目录。而且，他还能在多个可写的branch/dir间进行负载均衡。

上面的例子，我们已经看到AUFS的mount的示例了。下面我们来看一看被union的目录（分支）的相关权限：

• rw表示可写可读read-write。

• ro表示read-only，如果你不指权限，那么除了第一个外ro是默认值，对于ro分支，其永远不会收到写操作，也不会收到查找whiteout的操作。

• rr表示real-read-only，与read-only不同的是，rr标记的是天生就是只读的分支，这样，AUFS可以提高性能，比如不再设置inotify来检查文件变动通知。

推荐学习：《docker视频教程》

The above is the detailed content of What is the earliest storage engine supported by docker?. For more information, please follow other related articles on the PHP Chinese website!