Was ist die früheste von Docker unterstützte Speicher-Engine?

AUFS ist die früheste von Docker unterstützte Speicher-Engine. AUFS ist ein Union File System, ein Speichertreiber auf Dateiebene. Er wurde vor Docker-Version 18.06 und Ubuntu-Version 14.04 empfohlen.

Die Betriebsumgebung dieses Tutorials: Linux7.3-System, Docker20-Version, Dell G3-Computer.

AUFS ist die früheste von Docker unterstützte Speicher-Engine.

Die Speicher-Engine von Docker

Die Speicher-Engine von Docker ist so konzipiert, wird jedoch von unterschiedlichen Speichertreibern für unterschiedliche Dateisysteme implementiert. Lassen Sie uns als Nächstes über den Speichertreiber von Docker sprechen.

Docker verfügt hauptsächlich über die folgenden Arten von Speichertreibern:

• Overlay2: Dies ist der in der aktuellen Version empfohlene Speichertreiber, der ohne zusätzliche Abhängigkeiten und Konfigurationen eine hervorragende Leistung erzielen kann. Der Overlay-Speichertreiber wurde nach Version 18.09 ersetzt. Unterstützt xfs, ext4-Dateisystem.

• aufs: Der früheste von Docker verwendete Speichertreiber, der vor der Docker-Version 18.06 und der Ubuntu-Version 14.04 empfohlen wird. Unterstützt xfs, ext4-Dateisystem.

• devicemapper: Dies ist der empfohlene Speichertreiber für frühere Versionen von CentOS- und RHEL-Systemen, da diese Overlay2 nicht unterstützen und Direct-LVM-Unterstützung erfordern.

• btrfs: Nur für Btrfs-Dateisystem.

• zfs: Nur für ZFS-Dateisysteme.

• vfs: Hängt nicht vom Dateisystem ab, aber die Leistung ist extrem schlecht und wird hauptsächlich zum Testen verwendet.

Es ist zu beachten, dass die Ebenen Overlay2, Overlay und Aufs dateibasiert sind. Wenn die Schreibparallelität einer einzelnen Datei hoch ist, ist eine große Speicherunterstützung erforderlich und die Lese-/Schreibebene kann sehr groß werden aufgrund einer einzelnen Datei. Die Schichten von Devicemapper, Btrfs und ZFS basieren auf Blockspeicher und haben daher kaum Auswirkungen auf die hohe Parallelität einer einzelnen Datei. Btrfs und zfs sind jedoch sehr speicherintensiv.

docker AUFS

AUFS ist ein Union File System. Das sogenannte UnionFS dient dazu, Verzeichnisse an verschiedenen physischen Standorten im selben Verzeichnis zusammenzuführen und bereitzustellen. Eine der wichtigsten Anwendungen von UnionFS ist das gemeinsame Mounten einer CD/DVD und eines Festplattenverzeichnisses. Anschließend können Sie die Dateien auf dieser schreibgeschützten CD/DVD ändern (natürlich werden die geänderten Dateien in einem Verzeichnis gespeichert). auf der Festplatte).

AUFS hieß auch Another UnionFS und später Alternative UnionFS. Später war es möglicherweise nicht dominant genug, also wurde es Advance UnionFS genannt. AUFS wurde 2006 von Junjiro Okajima entwickelt und hat das frühe UnionFS 1.x komplett neu geschrieben. Sein Hauptzweck bestand darin, Zuverlässigkeit und Leistung zu gewährleisten, und es wurden einige neue Funktionen eingeführt, beispielsweise beschreibbare Zweige. AUFS ist im Einsatz vollständig kompatibel mit UnionFS und weist eine viel bessere Stabilität und Leistung als das vorherige UnionFS auf. Später begann UnionFS 2.x, die Funktionen von AUFS zu kopieren. Aber er kam tatsächlich nicht in den Linux-Trunk, weil Linus es nicht zuließ. Im Grunde lag es daran, dass die Codemenge relativ groß und schlecht geschrieben war (im Vergleich zu nur 3.000 Zeilen Union Mount und 10.000 Zeilen UnionFS). , und andere, die im Durchschnitt nur 6.000 VFS haben, haben etwa 30.000 Zeilen Code, und AUFS hat tatsächlich 30.000 Zeilen Code. Daher verbesserte Okajima die Codequalität weiter, reichte sie weiter ein und wurde daher von Linus ständig abgelehnt Tag kann AUFS nicht in den Linux-Trunk gelangen (heute können Sie sehen, dass der Code für AUFS tatsächlich ziemlich gut ist, N-mal besser als OpenSSL. Entweder hat Linus sehr hohe Anforderungen an die Codequalität, oder Linus mag AUFS einfach nicht).

Glücklicherweise verwenden jedoch viele Distributionen AUFS, wie zum Beispiel: Ubuntu 10.04, Debian6.0 und Gentoo Live CD unterstützen AUFS, daher ist es in Ordnung.

Okay, nach all diesem Klatsch schauen wir uns ein Beispiel an (Umgebung: Ubuntu 14.04)

Zuerst erstellen wir zwei Verzeichnisse (Obst und Gemüse) und legen einige Dateien in diesen beiden Verzeichnissen ab. Zu den Früchten gehören Äpfel, Tomaten und Gemüse Dazu gehören Karotten und Tomaten.

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

Dann geben wir den folgenden Befehl ein:

# 创建一个mount目录
$ mkdir mnt

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

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

Wir können sehen, dass sich im ./mnt-Verzeichnis drei Dateien befinden: Apfel, Karotten und Tomaten. Die Obst- und Gemüseverzeichnisse sind im Verzeichnis ./mnt zusammengefasst.

Ändern wir den Inhalt der Datei:

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

Im obigen Beispiel können wir sehen, dass der Inhalt von ./mnt/apple geändert wurde und der Inhalt von ./fruits/apple ebenfalls geändert wurde.

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

$ cat ./fruits/carrots
mnt_carrots

Im obigen Beispiel können wir sehen, dass wir den Dateiinhalt von ./mnt/carrots geändert haben, aber ./vegetables/carrots hat sich nicht geändert. Stattdessen wurde die Karottendatei im Verzeichnis von ./fruits/carrots angezeigt. und sein Inhalt Es ist der Inhalt, den wir in ./mnt/carrots haben.

Mit anderen Worten, im Befehl mount aufs haben wir nicht auf die Verzeichnisberechtigungen von Gemüse und Obst verwiesen. Standardmäßig ist das erste Verzeichnis (ganz links) in der Befehlszeile lesbar und beschreibbar, und alle nachfolgenden Verzeichnisse sind lesbar und beschreibbar. Es ist schreibgeschützt. (Im Allgemeinen sollte das erste Verzeichnis beschreibbar sein und die folgenden Verzeichnisse sollten schreibgeschützt sein.)

Wenn wir also die Berechtigungen zum Mounten von aufs wie folgt festlegen, werden Sie unterschiedliche Auswirkungen feststellen (Denken Sie daran, die oben genannten ./fruits/ zu löschen. Karottenfeile zuerst):

$ 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视频教程》

Das obige ist der detaillierte Inhalt vonWas ist die früheste von Docker unterstützte Speicher-Engine?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!