Docker でサポートされている最も古いストレージエンジンは何ですか?-Docker-php.cn

AUFS は、Docker でサポートされている最も古いストレージエンジンです。 AUFS は Union File System であり、ファイルレベルのストレージドライバーです。これは、Docker の初期の頃に使用されていたストレージドライバーでした。Docker バージョン 18.06 および Ubuntu バージョン 14.04 より前に推奨されていました。xfs および ext4 ファイルをサポートしています。

Docker でサポートされている最も古いストレージエンジンは何ですか?

このチュートリアルの動作環境: linux7.3 システム、docker バージョン 20、Dell G3 コンピューター。

AUFS は、Docker でサポートされている最も古いストレージエンジンです。

Docker のストレージエンジン

Docker のストレージエンジンは次のように設計されていますが、ファイルシステムが異なると、異なるストレージで構成されます。達成するためのドライバー。次に、Docker のストレージドライバーについて説明します。

Docker には主に次のタイプのストレージドライバーがあります:

overlay2: 現在のバージョンで推奨されるストレージドライバーであり、追加の依存関係や構成なしで優れたパフォーマンスを実現できます。 . .バージョン 18.09 以降のオーバーレイストレージドライバーを置き換えました。 xfs、ext4 ファイルシステムをサポートします。
aufs: Docker で使用される最も古いストレージドライバー。Docker 18.06 バージョンおよび Ubuntu 14.04 バージョンより前に推奨されます。 xfs、ext4 ファイルシステムをサポートします。
devicemapper: これは、overlay2 をサポートしておらず、直接 LVM サポートを必要とするため、CentOS および RHEL システムの以前のバージョンに推奨されるストレージドライバーです。
btrfs: btrfs ファイルシステムのみ。
zfs: zfs ファイルシステムのみ。
vfs: ファイルシステムには依存しませんが、パフォーマンスは非常に低く、主にテストに使用されます。

overlay2、overlay、および aufs レイヤーはファイルに基づいていることに注意してください。単一ファイルの書き込み同時実行性が高い場合、大規模なメモリのサポートが必要になり、読み取り単一のファイルは非常に大きくなります。 devicemapper、btrfs、および zfs のレイヤーはブロックストレージに基づいているため、単一ファイルの高い同時実行性にほとんど影響を与えません。ただし、btrfs と zfs は非常にメモリを消費します。

docker AUFS

AUFS は Union File System です。いわゆる UnionFS は、異なる物理的な場所にあるディレクトリをマージしてマウントします。同じディレクトリです。 UnionFS の最も重要なアプリケーションの 1 つは、CD/DVD とハードディスクディレクトリを共同でマウントすることです。その後、この読み取り専用 CD/DVD 上のファイルを変更できます (もちろん、変更されたファイルはディレクトリに保存されます)ハードドライブ上にあります）。

AUFS は Another UnionFS とも呼ばれ、その後 Alternative UnionFS と呼ばれましたが、横暴さが足りないため Advance UnionFS と呼ばれるようになりました。 2006 年に岡島順次郎によって開発された AUFS は、初期の UnionFS 1.x を完全に書き直しました。その主な目的は信頼性とパフォーマンスであり、書き込み可能なブランチなどのいくつかの新機能が導入されました。 AUFS は、現在使用されている UnionFS と完全な互換性があり、以前の UnionFS よりも安定性とパフォーマンスが大幅に向上しており、その後、UnionFS 2.x が AUFS の機能をコピーし始めました。しかし実際には、Linus が許可しなかったため、彼は Linux トランクに入らなかったのです。基本的に、コードの量が比較的多く、記述が不十分だったためです (ユニオンマウントのわずか 3,000 行とユニオンFS の 10,000 行と比較して)。など、平均わずか 6,000 行のコードがありますが、VFS のコード行数は約 30,000 行で、AUFS の実際のコード行数は 30,000 行です)。したがって、岡島氏はコードの品質を向上させ続け、提出し続けましたが、常に Linus によって拒否されました。その日、AUFS は Linux トランクに入ることができません (今日、AUFS のコードは実際に非常に優れており、OpenSSL の N 倍優れていることがわかります。Linus はコード品質に対して非常に高い要件を持っているか、Linus が単に AUFS を好まないかのどちらかです)。

ただし、幸いなことに、Ubuntu 10.04、Debian6.0、Gentoo Live CD など、多くのディストリビューションで AUFS が使用されているため、問題ありません。

さて、このゴシップをすべて終えたので、例を見てみましょう (環境: Ubuntu 14.04)

まず、2 つのディレクトリ (果物と野菜) を作成し、これら 2 つのディレクトリにいくつかのファイルを置きます果物にはリンゴとトマトが含まれ、野菜にはニンジンとトマトが含まれます。

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

ログイン後にコピー

次に、次のコマンドを入力します。

# 创建一个mount目录
$ mkdir mnt

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

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

ログイン後にコピー

./mnt ディレクトリに、apple、キャロット、トマトという 3 つのファイルがあることがわかります。果物と野菜のディレクトリは ./mnt ディレクトリに結合されます。

ファイルの内容を変更してみましょう:

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

ログイン後にコピー

上の例では、./mnt/apple の内容が変更され、./fruits/ の内容が変更されたことがわかります。リンゴも変わってしまいました。。

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

$ cat ./fruits/carrots
mnt_carrots

ログイン後にコピー

上の例では、./mnt/キャロットのファイル内容を変更しましたが、./vegetables/キャロットは変更されておらず、代わりにニンジンがディレクトリ./fruits/キャロットに表示されていることがわかります。 . ファイルの内容は、./mnt/キャロットにあるものです。

つまり、mount aufs コマンドでは、野菜や果物のディレクトリ権限を参照しませんでした。デフォルトでは、コマンドラインの最初 (左端) のディレクトリは読み取りおよび書き込み可能です。以降はすべて読み取り可能です。は読み取り専用です。 (一般的に、最初のディレクトリは書き込み可能であり、次のディレクトリは読み取り専用である必要があります)

したがって、次のように aufs をマウントする権限を指定すると、同じ効果がないことがわかります (最初に上記の ./fruits/キャロットファイルを忘れずに削除してください):

$ 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 でサポートされている最も古いストレージエンジンは何ですか?

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

以上がDocker でサポートされている最も古いストレージエンジンは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。