Apakah enjin storan terawal yang disokong oleh docker?

AUFS ialah enjin storan terawal yang disokong oleh docker. AUFS ialah Sistem Fail Kesatuan, yang merupakan pemacu storan peringkat fail Ia adalah pemacu storan yang digunakan pada hari-hari awal Docker Ia disyorkan sebelum versi 18.06 dan Ubuntu 14.04. Ia menyokong fail xfs dan ext4.

Persekitaran pengendalian tutorial ini: sistem linux7.3, docker versi 20, komputer Dell G3.

AUFS ialah enjin storan terawal yang disokong oleh docker.

Enjin storan Docker

Enjin storan Docker direka bentuk seperti ini, tetapi untuk sistem fail yang berbeza, ia terdiri daripada Storan yang berbeza pemandu untuk dicapai. Seterusnya mari bercakap tentang pemacu storan Docker.

Docker terutamanya mempunyai jenis pemacu storan berikut:

• tindihan2: Ia adalah pemacu storan yang disyorkan dalam versi semasa dan boleh mencapai prestasi cemerlang tanpa kebergantungan dan konfigurasi tambahan . Menggantikan pemacu storan tindanan selepas versi 18.09. Menyokong xfs, sistem fail ext4.

• aufs: Pemacu storan terawal yang digunakan oleh Docker , yang disyorkan sebelum versi Docker 18.06 dan versi Ubuntu 14.04. Menyokong xfs, sistem fail ext4.

• devicemapper: ialah pemacu storan yang disyorkan untuk versi lama sistem CentOS dan RHEL, kerana ia tidak menyokong tindanan2 dan memerlukan sokongan direct-lvm.

• btrfs: Untuk sistem fail btrfs sahaja.

• zfs: Hanya untuk sistem fail zfs.

• vfs: Tidak bergantung pada sistem fail, tetapi prestasinya sangat lemah, terutamanya digunakan untuk ujian.

Perlu diambil perhatian bahawa lapisan tindanan2, tindanan dan aufs adalah berdasarkan fail Apabila konkurensi tulis bagi satu fail tinggi, sokongan memori yang besar diperlukan dan bacaan dan tulis lapisan mungkin Satu fail menjadi sangat besar. Lapisan devicemapper, btrfs dan zfs adalah berdasarkan storan blok, jadi ia mempunyai sedikit kesan pada keselarasan tinggi satu fail. Tetapi btrfs dan zfs sangat intensif memori.

docker AUFS

AUFS ialah Sistem Fail Union Apa yang dipanggil UnionFS adalah untuk menggabungkan dan melekapkan direktori di lokasi fizikal yang berbeza ke dalam direktori yang sama. Salah satu aplikasi terpenting UnionFS adalah untuk memasang CD/DVD dan direktori cakera keras secara bersama Kemudian, anda boleh mengubah suai fail pada CD/DVD baca sahaja ini (sudah tentu, fail yang diubah suai disimpan dalam direktori. pada cakera keras).

AUFS juga dipanggil Another UnionFS, dan kemudiannya Alternative UnionFS, ia mungkin tidak cukup mendominasi, jadi ia dipanggil Advance UnionFS. Dibangunkan oleh Junjiro Okajima pada tahun 2006, AUFS telah menulis semula sepenuhnya UnionFS 1.x Tujuan utamanya adalah untuk kebolehpercayaan dan prestasi, dan ia memperkenalkan beberapa ciri baharu, seperti pengimbangan beban. AUFS serasi sepenuhnya dengan UnionFS yang sedang digunakan, dan jauh lebih baik dari segi kestabilan dan prestasi daripada UnionFS sebelumnya. Kemudian, UnionFS 2.x mula menyalin fungsi AUFS. Tetapi dia sebenarnya tidak masuk ke dalam trunk Linux kerana Linus tidak membenarkannya pada asasnya, ia adalah kerana jumlah kod yang agak besar dan ia ditulis dengan buruk (berbanding dengan hanya 3,000 baris union mount dan 10,000 baris UnionFS. , dan lain-lain, yang purata hanya 6,000 VFS mempunyai kira-kira 30,000 baris kod, dan AUFS sebenarnya mempunyai 30,000 baris kod). hari, AUFS tidak boleh memasuki trunk Linux (hari ini anda boleh melihat Kod kepada AUFS sebenarnya cukup bagus, N kali lebih baik daripada OpenSSL. Sama ada Linus mempunyai keperluan yang sangat tinggi untuk kualiti kod, atau Linus tidak menyukai AUFS).

Namun, mujurlah, banyak pengedaran menggunakan AUFS, seperti: Ubuntu 10.04, Debian6.0, Gentoo Live CD menyokong AUFS, jadi ia adalah OK.

Baiklah, selepas semua gosip ini, mari kita lihat contoh (persekitaran: Ubuntu 14.04)

Pertama, kami mencipta dua direktori (buah-buahan dan sayur-sayuran), dan dalam kedua-dua ini Letakkan beberapa fail dalam direktori Buah-buahan termasuk epal dan tomato, dan sayur-sayuran termasuk lobak merah dan tomato.

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

Kemudian, kita masukkan arahan berikut:

# 创建一个mount目录
$ mkdir mnt

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

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

Kita dapat lihat terdapat tiga fail dalam direktori ./mnt, epal, lobak merah dan tomato. Direktori buah-buahan dan sayur-sayuran digabungkan ke dalam direktori ./mnt.

Mari ubah suai kandungan fail:

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

Dalam contoh di atas, kita dapat melihat bahawa kandungan ./mnt/apple telah berubah, dan kandungan ./fruits /apple juga telah berubah.

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

$ cat ./fruits/carrots
mnt_carrots

Dalam contoh di atas, kita dapat melihat bahawa kami mengubah suai kandungan fail ./mnt/carrots, tetapi ./vegetables/carrots tidak berubah, ia muncul dalam direktori ./fruits /carrots Fail lobak merah dibuat, kandungannya adalah kandungan yang ada dalam ./mnt/carrots.

Dalam erti kata lain, dalam perintah mount aufs, kami tidak merujuk kepada kebenaran direktori sayur-sayuran dan buah-buahan Secara lalai, direktori pertama (paling kiri) pada baris arahan boleh dibaca dan ditulis , semuanya mengikuti adalah baca sahaja. (Secara umumnya, direktori pertama hendaklah boleh ditulis dan direktori berikut hendaklah dibaca sahaja)

Jadi, jika kami menentukan kebenaran untuk melekapkan aufs seperti berikut, anda akan mendapati bahawa tiada kesan yang sama ( ingat untuk memadam fail ./fruits/carrots di atas dahulu):

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

Atas ialah kandungan terperinci Apakah enjin storan terawal yang disokong oleh docker?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!