AUFS ストレージドライバの使用¶

AUFS は「ユニオンファイルシステム(union filesystem) 」です。 aufs ストレージドライバとは、 Ubuntu 、Debian Stretch 未満の Docker で、イメージとレイヤーを管理するために使う、デフォルトのストレージドライバでした。Linux kernel がバージョン 4.0 以上で、Docker Engine コミュニティ版を使っているのであれば、より新しい overlay2 の利用をご検討ください。そちらのほうが、 aufs ストレージドライバよりも性能面で有利な可能性があります。

注釈

ディストリビューションと Docker エディションによっては AUFS はサポートされていません。サポートされているプラットフォームの詳細は、動作環境をご覧ください。

AUFS は Docker に使われた初めてのストレージドライバです。そのため、Docker の歴史で長く使われており、非常に安定し、多くの実際の開発に使われ、強力なコミュニティのサポートがあります。AUFS には複数の機能があります。これらは Docker の良い選択肢となるでしょう。次の機能を有効にします。

（以下は古い内容を含むため、確認予定）正確な内容は、原文を参照ください https://docs.docker.com/storage/storagedriver/aufs-driver/

コンテナ起動時間の高速化
ストレージの効率的な利用
メモリの効率的な利用

性能に拘わらず Docker で長い間使われてきていますが、いくつかのディストリビューションは AUFS をサポートしていません。たいていの場合、AUFS は Linux カーネルのメインライン（upstream）ではないためです。

以下のセクションでは、AUFS 機能と Docker がどのように連携するか紹介します。

AUFS でコンテナの読み書き ¶

Docker は AUFSのコピー・オン・ライト技術をテコに、イメージ共有とディスク使用量の最小化をできるようにします。AUFS はファイルレベルで動作します。つまり、AUFSのコピー・オン・ライト処理は、ファイル全体をコピーします。それがファイルの一部を変更する場合でもです。この処理はコンテナの性能に大きな影響を与えます。特に、コピーする対象のファイルが大きい場合は、配下のイメージ・レイヤが多くあるか、あるいは、コピー・オン・ライト処理により深いディレクトリ・ツリーを検索する必要なためです。

考えてみましょう。例えばコンテナで実行しているアプリケーションが、大きなキーバリュー・ストア（ファイル）に新しい値を追加したとします。これが初回であれば、コンテナの一番上の書き込み可能なレイヤに、まだ変更を加えるべきファイルが存在していません。そのため、 CoW 処理は、下部のイメージからファイルを 上にコピー する必要があります。AUFS ストレージドライバは、各イメージ・レイヤ上でファイルを探します。検索順番は、上から下にかけてです。ファイルが見つかれば、対象のファイルをコンテナの上にある書き込み可能なレイヤに コピー （copy up）します。そして、やっとファイルを開き、編集できるようになります。

小さなファイルに比べて、大きなファイルであれば明らかにコピー時間がかかります。そして、高いイメージ・レイヤにファイルがあるよりも、低いレイヤにある場合も時間がかかります。しかしながら、コピー作業が発生するのは、対象のコンテナ上では１度だけです。次にファイルの読み書き処理が発生しても、コンテナの一番上のレイヤにコピー済みのファイルがある場合は、ファイルを再度コピーしません。

AUFS ストレージドライバでのファイル削除 ¶

AUFS ストレージドライバでコンテナからファイルを削除したら、コンテナの一番上のレイヤに ホワイトアウト・ファイル（whiteout file） が置かれます。読み込み専用のイメージ・レイヤの下にあるファイルを、ホワイトアウト・ファイルが効果的に隠します。以下の単純化した図は、３つのイメージ・レイヤのイメージに基づくコンテナを表しています。

ファイル3 はコンテナ上で削除されました。すると、AUFS ストレージドライバは、コンテナの最上位レイヤにホワイトアウト・ファイルを置きます。このホワイトアウト・ファイルは、イメージの読み込み専用レイヤに存在するオリジナルのファイルを隠すことにより、コンテナ上から事実上 ファイル3 が削除されたものとします。この処理はイメージの読み込み専用レイヤに対し何ら影響を与えません。

Docker で AUFS を使う設定 ¶

AUFS ストレージドライバを使えるのは、AUFS がインストールされた Linux システム上でのみです。以下のコマンドを使い、システムが AUFS をサポートしているかどうか確認します。

$ grep aufs /proc/filesystems
nodev   aufs

この出力は、システムが AUFS をサポートしています。自分のシステムで AUFS をサポートしているのを確認したら、Docker デーモンに対して AUFS を使う指示が必要です。これには dockerd コマンドを使えます。

$ sudo dockerd --storage-driver=aufs &

あるいは、Docker の設定ファイルを編集し、 DOCKER_OPTS 行に --storage-driver=aufs オプションを追加します。

# DOCKER_OPTS で、デーモン起動時のオプションを編集
DOCKER_OPTS="--storage-driver=aufs"

デーモンを起動したら、 docker info コマンドでストレージドライバを確認します。

$ sudo docker info
Containers: 1
Images: 4
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 6
 Dirperm1 Supported: false
Execution Driver: native-0.2
...出力を省略...

このような出力から、起動中の Docker デーモンが既存の ext4 ファイルシステム上で AUFS ストレージドライバを使っていることが分かります。

ローカルのストレージと AUFS ¶

dockerd を AUFS ドライバで実行したら、ドライバは Docker ホスト上のローカル・ストレージ領域である /var/lib/docker/aufs 内に、イメージとコンテナを保管します。

イメージ ¶

イメージ・レイヤと各コンテナは、 /var/lib/docker/aufs/diff/<イメージID> ディレクトリ以下に保管されます。Docker 1.10 以降では、イメージ・レイヤ ID はディレクトリ名と一致しません。

/var/lib/docker/aufs/layers/ ディレクトリに含まれるのは、どのようにイメージ・レイヤを重ねるかというメタデータです。このディレクトリには、Docker ホスト上のイメージかコンテナごとに１つのファイルがあります（ファイル名はイメージのレイヤ ID と一致しません）。各ファイルの中にはイメージ・レイヤの名前があります。次の図は１つのイメージが４つのレイヤを持つのを示しています。

以下のコマンドは、 /var/lib/docker/aufs/layers/ にあるメタデータ・ファイルを表示しています。ここで表示されるディレクトリの一覧は、ユニオン・マウントに積み重ねられている（スタックしている）ものです。ただし、覚えておかなくてはいけないのは、Docker 1.10 以上ではディレクトリ名とイメージ・レイヤ ID が一致しなくなりました。

$ cat /var/lib/docker/aufs/layers/91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c
d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82
c22013c8472965aa5b62559f2b540cd440716ef149756e7b958a1b2aba421e87
d3a1f33e8a5a513092f01bb7eb1c2abf4d711e5105390a3fe1ae2248cfde1391

イメージのベース・レイヤは下層にイメージ・レイヤを持ちませんので、対象となるファイルの内容は空っぽです。

コンテナ ¶

実行中のコンテナは /var/lib/docker/aufs/mnt/<コンテナ ID> 配下にマウントされます。これが AUFS ユニオン・マウント・ポイントであり、コンテナと下層のイメージ・レイヤが１つに統合されて公開されている場所です。コンテナが実行されていなければ、これらのディレクトリは存在しますが、内容は空っぽです。なぜなら、コンテナが実行する時のみマウントするための場所だからです。Docker 1.10 以上では、コンテナ ID はディレクトリ名 /var/lib/docker/aufs/mnt/<コンテナID> と対応しません。

コンテナのメタデータやコンテナの実行に関する様々な設定ファイルは、 /var/lib/docker/containers/<コンテナ ID> に保管されます。ディレクトリ内に存在するファイルはシステム上の全コンテナに関するものであり、停止されたものも含みます。しかしながら、コンテナを実行したら、コンテナのログファイルもこのディレクトリに保存されます。

コンテナの薄い書き込み可能なレイヤ（thin writable layer）は /var/lib/docker/aufs/diff/<コンテナ ID> に保存されます。Docker 1.10 以上では、コンテナ ID はディレクトリ名と対応しません。しかしながら、コンテナの薄い書き込み可能なレイヤは、まだこの配下に存在し続けています。このディレクトリは AUFS によってコンテナの最上位の書き込みレイヤとして積み重ねられるものであり、コンテナに対する全ての変更が保管されます。コンテナが停止しても、このディレクトリは存在し続けます。つまり、コンテナを再起動しても、その変更内容は失われません。コンテナが削除された時のみ、このディレクトリは削除されます。

AUFS と Docker の性能 ¶

既に言及している性能面について、まとめます。

AUFS ストレージドライバは PaaS とコンテナの密度が重要な類似事例にとって、良い選択肢です。これは複数の実行中のコンテナ間で、 AUFS が効率的にイメージを共有するためです。それにより、コンテナの起動時間を早くし、ディスク使用量を最小化します。

AUFS がイメージ・レイヤとコンテナ間でどのように共有するのか、その根底にある仕組みは、システム・ページ・キャッシュを非常に効率的に使います。

AUFS ストレージドライバはコンテナに対する書き込み性能に対し、著しい待ち時間をもたらし得ます。これはコンテナに何らかのファイルを書き込もうとすると、ファイルをコンテナ最上位の書き込み可能レイヤに対してコピーする必要があるためです。ファイルが多くのイメージ・レイヤに存在する場合や、ファイル自身が大きい場合には、待ち時間が増え、悪化するでしょう。

最後に１つだけ。データ・ボリュームは最高かつ最も予想可能な性能をもたらします。これはデータ・ボリュームがストレージドライバを迂回するためであり、シン・プロビジョニングやコピー・オン・ライトによるオーバヘッドの影響を受けないためです。この理由のため、重い書き込み処理を行いたい場合には、データ・ボリュームの使用が適している場合もあるでしょう。

AUFS ストレージ ドライバの使用¶

AUFS ストレージドライバの使用¶