Dockerイメージストレージoverlayfsの使用

1. 概要

Docker のイメージはレイヤーで設計されています。各レイヤーは「レイヤー」と呼ばれます。これらのレイヤーは /var/lib/docker/<storage-driver>/ ディレクトリに保存されます。ストレージドライバーには、AUFS、OverlayFS、VFS、Brtfs など、さまざまな種類があります。ストレージドライバーは、docker info コマンドで確認できます (著者のシステムは centos7.4 です)。

通常、Ubuntu のようなシステムではデフォルトで AUFS が使用されますが、CentOS 7.1 以降のシリーズでは OverlayFS が使用されます。この記事では、ストレージドライバーとして OverlayFS を使用したイメージ保存の原理とストレージ構造を紹介します。

2. オーバーレイFS導入

OverlayFS は、他のファイルシステム (ext4fs や xfs など) に依存し、それらの上に構築されたスタックファイルシステムです。ディスクスペース構造の分割には直接関与しません。元の基盤となるファイルシステム内のさまざまなディレクトリを「マージ」し、ユーザーに提示するだけです。これがジョイントマウントテクノロジです。AUFS と比較すると、OverlayFS は実装が高速でシンプルです。 Linux カーネルは、Docker 用に overlay と overlay2 という 2 種類の OverlayFS ドライバーを提供します。 Overlay2 は Overlay の改良版であり、inode の使用率の点では Overlay よりも効率的です。ただし、オーバーレイには環境要件があります: Docker バージョン 17.06.02 以上、ホストファイルシステムは ext4 または xfs 形式である必要があります。

複合マウント

Overlayfs は、下位ディレクトリ、上位ディレクトリ、作業ディレクトリの 3 つのディレクトリを通じて実装されます。下位ディレクトリは複数存在する場合があります。作業ディレクトリは基本的な作業ディレクトリです。マウント後にその内容はクリアされ、使用中にユーザーには表示されません。最後に、ジョイントマウントが完了した後にユーザーに表示される統一されたビューは、マージされたディレクトリと呼ばれます。次の mount の使用法では、それがどのように機能するかを説明します。

次の構文で mount コマンドを使用して overlayfs をマウントします。

マウント -t オーバーレイ オーバーレイ -o 下位ディレクトリ=下位1:下位2:下位3、上位ディレクトリ=上位、作業ディレクトリ=作業 マージされたディレクトリ

3 つのディレクトリ A、B、C、およびワーカーディレクトリを作成します。

次に、マウントの組み合わせを使用して /tmp/test にマウントします。

次に、/tmp/test ディレクトリを再度確認すると、ディレクトリ A、B、C が結合され、同じファイル名のファイルが「上書き」されていることがわかります。ここでの上書きは実際の上書きではありませんが、結合中にディレクトリ内の 2 つのファイルの名前が同じである場合、結合されたレイヤーディレクトリには最も近いファイルが表示されます。

同時に、mount コマンドを使用してマウントオプションを表示することもできます。

上記の方法はジョイントマウント技術とも呼ばれます。

Docker のオーバーレイドライバー

オーバーレイドライバーの原理を紹介した後、Docker のオーバーレイストレージドライバーを見てみましょう。以下は、Docker の公式 Web サイトに掲載されているオーバーレイの動作原理の図です。

上の図では、lowerdir、upperdir、merged の 3 つのレイヤー構造が確認できます。Lowerdir は読み取り専用のイメージレイヤーで、実際には rootfs です。上で示したディレクトリ A と B と比較すると、イメージレイヤーは複数のレイヤーに分割できるため、対応する lowerdir には複数のディレクトリが存在する可能性があることがわかります。 upperdir は lowerdir の上の層です。この層は読み取り/書き込み層です。コンテナの起動時に作成されます。例の C と比較すると、コンテナデータへのすべての変更はこの層で発生します。最後に、マージされたディレクトリはコンテナのマウントポイントであり、例の /tmp/test と比較して、ユーザーに公開される統一されたパースペクティブです。これらのディレクトリレイヤーは、/var/lib/docker/overlay2/ または /var/lib/docker/overlay/ (オーバーレイが使用されている場合) に保存されます。

デモ

コンテナを起動する

オーバーレイマウントポイントを確認すると、マウントされたマージされたディレクトリ、lowerdir、upperdir、workdir を見つけることができます。

overlay2 には複数の下位ディレクトリが存在する可能性があり、それらはソフトリンクとしてマウントされます。これについては後で説明します。

仕組み

コンテナ内でデータが変更された場合、overlayfs ストレージドライバーはどのように機能しますか?読み書きのプロセスについては、以下で説明します。

読む：

ファイルがコンテナ層 (upperdir) にある場合は、ファイルを直接読み取ります。
ファイルがコンテナレイヤー (upperdir) にない場合は、イメージレイヤー (lowerdir) から読み取られます。

改訂：

最初の書き込み: upperdir に存在しない場合、overlay と overlay2 は copy_up 操作を実行して、ファイルを lowdir から upperdir にコピーします。overlayfs はファイルレベルであるため (ファイルにわずかな変更しか加えられていない場合でも、copy_up 動作が生成されます)、ここでの同じファイルに対する後続の書き込み操作は、コンテナーにコピーされたファイルのコピーに対して実行されます。これは、コピーオンライトと呼ばれることがよくあります。
ファイルとディレクトリの削除: コンテナ内でファイルが削除されると、コンテナレイヤー (upperdir) にホワイトアウトファイルが作成されます。イメージレイヤー (lowerdir) 内のファイルは読み取り専用であるため削除されませんが、without ファイルによって表示されなくなります。コンテナ内でディレクトリが削除されると、コンテナレイヤー (upperdir) に不透明なディレクトリが作成されます。これは上記のホワイトアウトの原則と同じで、イメージレイヤーがまだ存在する場合でも、ユーザーが引き続きアクセスできないようにします。

予防

copy_up 操作は、ファイルが最初に書き込まれるときにのみ実行され、その後はコピーのみが変更されます。
Overlayfs は 2 レベルのディレクトリにのみ適用され、AUFS よりも検索が高速です。
コンテナレイヤーでのファイルの削除は、ホワイトアウトファイルで隠された単なる「煙幕」です。イメージレイヤーは削除されません。docker commit を使用して保存されたイメージがどんどん大きくなっていくのは、このためです。コンテナレイヤーでデータがどのように削除されても、イメージレイヤーは変更されません。

3. Overlay2画像保存構造

リポジトリから Ubuntu イメージをプルします。結果は、次のように合計 4 層のイメージがプルされたことを示しています。

この時点で、4 つのレイヤーは /var/lib/docker/overlay2/ ディレクトリに保存されます。

すべてのレイヤーのソフトリンクを含む追加の l ディレクトリがあります。短いリンクでは、マウント時にパラメータがページサイズの制限に達するのを避けるために短い名前を使用します (デモでマウントコマンドを表示するときの短いディレクトリ):

最下層の画像ディレクトリには、差分ファイルとリンクファイルが含まれています。差分ディレクトリには現在のレイヤーの画像コンテンツが保存され、リンクファイルは対応する短い名前です。

上の画像には作業ディレクトリと下位ファイルが追加されています。下位ファイルは親レイヤーの短縮名を記録するために使用され、作業ディレクトリは指定された作業ディレクトリを共同マウントするために使用されます。これらのディレクトリと画像はどのように整理されていますか?答えはメタデータの関連付けです。メタデータは、画像メタデータとレイヤーメタデータに分かれています。

画像のメタデータ

イメージのメタデータは、/var/lib/docker/image/<storage_driver>/imagedb/content/sha256/ ディレクトリに保存されます。名前は、イメージ ID にちなんで名付けられたファイルです。イメージ ID は、docker images を通じて確認できます。これらのファイルには、イメージの rootfs 情報、イメージの作成時間、ビルド履歴情報、起動エントリポイントや CMD を含む使用されたコンテナーなどが json 形式で保存されます。たとえば、ubuntu イメージの ID は 47b19964fb50 です。

対応するメタデータ (vim :%!python -m json.tool を使用して json にフォーマット) を表示し、その rootfs の構成をキャプチャします。

上記の diff_id はイメージレイヤーに対応しており、上から下の順に並べられ、イメージレイヤーの最下層から最上層を表します。

diff_id はレイヤーとどのように関係していますか?具体的には、docker は rootfs 内の各 diff_id と履歴情報を使用して、対応するコンテンツアドレス可能インデックス (chainID) を計算し、chaiID をレイヤーレイヤーに関連付け、各イメージレイヤーのイメージファイルに関連付けます。

レイヤーメタデータ

レイヤーはイメージレイヤーの概念に対応します。Docker バージョン 1.10 より前では、イメージはグラフ構造を通じて管理されていました。各イメージレイヤーには、レイヤーのビルド情報と親イメージレイヤー ID を記録したメタデータがありました。最上位のイメージレイヤーには、イメージ全体のメタデータとしてさらに多くの情報が記録されます。グラフは、各イメージレイヤーに記録されたイメージ ID (つまり、最上位のイメージレイヤー ID) と親イメージレイヤー ID に基づいて、ツリー状のイメージレイヤー構造を維持します。

Docker バージョン 1.10 以降、イメージメタデータ管理における最大の変更点の 1 つは、イメージレイヤーのメタデータが簡素化され、特定のイメージレイヤーファイルパッケージのみが含まれるようになったことです。ユーザーが Docker ホストに特定のイメージレイヤーをダウンロードすると、Docker はイメージレイヤーファイルパッケージとイメージメタデータ (差分、親、サイズなど) に基づいて、ホスト上にローカルレイヤーメタデータを構築します。 Docker がホストマシン上で生成された新しいイメージレイヤーをレジストリにアップロードする場合、新しいイメージレイヤーに関連するホストマシン上のメタデータはパッケージ化されず、イメージレイヤーと一緒にアップロードされません。

Docker は、読み取り専用レイヤーと読み取り/書き込みレイヤーの一部の操作をそれぞれ定義するために使用される、Layer と RWLayer という 2 つのインターフェースを定義します。また、上記の 2 つのインターフェースをそれぞれ実装するために、roLayer と mountedLayer も定義します。このうち、roLayer は不変のイメージ層を記述するために使用され、mountedLayer は読み取りおよび書き込み可能なコンテナ層を記述するために使用されます。具体的には、roLayer に格納される内容は、主に、イメージレイヤーをインデックスする chainID、イメージレイヤーの検証コード diffID、親イメージレイヤー parent、現在のイメージレイヤーファイルを格納する storage_driver の cacheID、イメージレイヤーのサイズ、その他の内容が含まれます。これらのメタデータは、/var/lib/docker/image/<storage_driver>/layerdb/sha256/<chainID>/ フォルダーに保存されます。次のように：

各 chainID ディレクトリには、cache-id、diff、zize の 3 つのファイルがあります。

キャッシュIDファイル:

docker によってランダムに生成された uuid には、イメージレイヤーのディレクトリインデックス (/var/lib/docker/overlay2/ 内のディレクトリ) が含まれます。そのため、対応するレイヤーディレクトリは chainID を通じて見つけることができます。チェーンIDに対応するディレクトリはd801a12f6af7beff367268f99607376584d8b2da656dcd8656973b7ad9779ab4で、これは130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5であり、/var/lib/docker/overlay2/130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5に保存されます。

差分ファイル:

イメージメタデータの diff_id が保存されます (メタデータの diff_ids の uuid に対応)

ファイルサイズ:

画像レイヤーのサイズを節約します

レイヤーのすべての属性のうち、diffID は、SHA256 アルゴリズムを使用してイメージレイヤーファイルパッケージの内容に基づいて計算されます。 chainID は、コンテンツストレージに基づくインデックスです。現在のレイヤーとすべての祖先イメージレイヤーの diffID に基づいて計算されます。具体的な計算は次のとおりです。

イメージレイヤーが最下位レイヤー (親イメージレイヤーなし) の場合、このレイヤーの diffID は chainID になります。
このイメージレイヤーの chainID 計算式は、chainID(n)=SHA256(chain(n-1) diffID(n)) です。これは、親イメージレイヤーの chainID にスペースと現在のレイヤーの diffID を追加し、SHA256 チェックサムを計算します。

MountedLayer 情報に格納される読み取り可能な init レイヤーおよびコンテナマウントポイント情報には、コンテナ init レイヤー ID (init-id)、ジョイントマウントに使用される ID (mount-id)、およびコンテナレイヤーの親レイヤーイメージの chainID (parent) が含まれます。関連するファイルは、/var/lib/docker/image/<storage_driver>/layerdb/mounts/<container_id>/ ディレクトリにあります。次のように、ID 3c96960b3127 のコンテナを起動します。

対応する 3 つの mountLayer ファイルを表示します。

initID は、mountID の後に -init が追加された、/var/lib/docker/overlay2/ に保存されているディレクトリの名前であることがわかります。

また、mount コマンドを使用して、対応するマウントの mountID を直接表示することもできます。これは、overlayfs によって提供されるマージされたディレクトリでもある /var/lib/docker/overlay2/ ディレクトリに対応します。

コンテナ内にファイルが作成されます:

この時点で、ホストのマージされたディレクトリ内に対応するファイルを確認できます。

初期化層について

init 層は、uuid+-init で終わる名前で表されます。読み取り専用層と読み書き可能層の間に挟まれており、/etc/hosts や /etc/resolv.conf などの情報を格納するために使用されます。この層が必要なのは、コンテナの起動時に、ホスト名などイメージ層に属するべきファイルやディレクトリをユーザーが変更する必要があるためです。ただし、イメージ層では変更できません。そのため、起動時に別の init 層をマウントし、init 層内のファイルを変更することで、これらのファイルを変更する目的を達成します。これらの変更は多くの場合、現在のコンテナでのみ有効であり、docker commit がイメージとして送信されると、init レイヤーは送信されません。このファイル層が保存されるディレクトリは /var/lib/docker/overlay2/<init_id>/diff です。

まとめ

上記の紹介により、コンテナの完全なレイヤーは、以下に示すように 3 つの部分で構成されるはずです。

イメージ層: rootfs とも呼ばれ、コンテナの起動用のファイルシステムを提供します。
init レイヤー: /etc/hostname、/etc/resolv.conf など、コンテナー内の一部のファイルを変更するために使用されます。
コンテナ層: ジョイントマウントを使用して、ユーザーに統一された読み取りおよび書き込み可能なディレクトリを提供します。

IV. 結論

この記事では、ストレージドライバーとして overlayfs を使用したイメージストレージの原理を紹介します。各レイヤーのイメージデータは /var/lib/docker/overlay2/<uuid>/diff ディレクトリに保存され、init レイヤーデータは /var/lib/docker/overlay2/<init-id>/diff ディレクトリに保存され、統合ビュー (コンテナレイヤー) データは /var/lib/docker/overlay2/<mount_id>/diff ディレクトリに保存されます。Docker は、イメージメタデータとレイヤーメタデータを通じてコンテンツアドレス指定 (chainID) を使用してこれらのディレクトリを整理し、コンテナ上で実行されるファイルシステムを形成します。

参照:

《overlayfs ドライバーを使用する》

《Dockerイメージのストレージ管理》

以上で、Docker イメージ保存における overlayfs の利用についての説明は終了です。Docker イメージ保存における overlayfs についての詳細は、123WORDPRESS.COM の過去の記事や以下の関連記事をご覧ください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: