Dockerイメージ保存メカニズム

[[206062]]

近年、Docker はテクノロジー界で人気が高まっています。多くの実践者は、さまざまな程度でこれを使用しており、Dockerfile を介してイメージをビルドする方法、リモート イメージ リポジトリから必要なイメージをプルする方法、ビルドしたイメージをリモート リポジトリにプッシュする方法、イメージに基づいてコンテナーを実行する方法などを理解しています。このプロセスは非常に簡単です。 docker build、docker pull、docker push、docker run などの操作を実行するだけで済みます。しかし、画像がローカルにどのように保存されるかについて考えたことはありますか?イメージに基づいてコンテナはどのように起動されますか?画像がリモート画像リポジトリにプッシュされると、サーバー上でどのように保存されますか?これについて簡単にお話ししましょう。

Docker イメージのローカル ストレージ メカニズムとコンテナの起動原理

Docker イメージは単一のファイルではなく、複数のレイヤーで構成されます。 docker images を使用してローカル イメージ リストと対応するメタ情報を取得し、docker history <imageId> を使用して特定のイメージの各レイヤーの内容と対応するサイズを表示できます。各レイヤーは Dockerfile 内の命令に対応します。 Docker イメージはデフォルトで /var/lib/docker/<storage-driver> に保存され、docker デーモンの実行時に DOCKER_OPTS または --graph= または -g を介して指定できます。

Docker はストレージ ドライバーを使用して、イメージの各レイヤーと読み取りおよび書き込み可能なコンテナー レイヤーのコンテンツを管理します。ストレージ ドライバーには、DeviceMapper、AUFS、Overlay、Overlay2、Btrfs、ZFS などがあります。ストレージ ドライバーによって実装方法が異なり、イメージの構成形式も若干異なる場合がありますが、いずれもスタック ストレージと Copy-on-Write (CoW) 戦略を使用します。ストレージ ドライブはホットスワップ可能なアーキテクチャを採用しており、動的に調整できます。では、ストレージ ドライバーが多数ある場合、適切なものをどのように選択すればよいのでしょうか?次の点を考慮することができます。

• カーネルが複数のストレージ ドライバーをサポートしていて、明示的な構成が指定されていない場合、Docker は内部の優先順位設定に基づいて 1 つを選択します。優先順位は、AUFS > Btrfs/ZFS > Overlay2 > Overlay > DeviceMapper です。 DeviceMapper を使用する場合は、実稼働環境で direct-lvm を選択する必要があります。 Loopback-lvm のパフォーマンスは非常に低いです。
• 選択は、Docker のバージョン、オペレーティング システム、システムのバージョンなどによって制限されます。たとえば、AUFS は Ubuntu または Debian システムでのみ使用可能であり、Btrfs は SLES (SUSE Linux Enterprise Server、Docker EE でのみサポート) でのみ使用可能です。
• 一部のストレージ ドライバーはバックエンド ファイル システムに依存します。たとえば、Btrfs は Btrfs と呼ばれるバックエンド ファイルシステム上でのみ実行できます。
• ストレージ ドライバーによって、アプリケーション シナリオに応じたパフォーマンスが異なります。たとえば、AUFS、Overlay、Overlay2 はファイル レベルで動作し、メモリの使用が比較的効率的になります。ただし、大きなファイルを読み書きする場合、コンテナ層は非常に大きくなります。 DeviceMapper、Btrfs、ZFS はブロック レベルで動作し、書き込み負荷が高いシナリオに適しています。コンテナ レイヤーが多く、小さなファイルが頻繁に書き込まれる場合は、Overlay の方が Overlay2 よりも効率的です。 Btrfs と ZFS はより多くのメモリを消費します。

Docker コンテナは実際にはイメージの上に読み取り/書き込みレイヤーを追加します。これは一般にコンテナ レイヤーとも呼ばれます。新しいファイルの書き込み、既存のファイルの変更、ファイルの削除など、実行中のコンテナで行われたすべての変更は、実際にはコンテナ レイヤーに書き込まれます。コンテナ層が削除され、最上位の読み取り/書き込み層も削除され、変更内容は当然失われます。これらの変更を永続化するには、 docker commit <containerId> [repository[:tag]] を使用して、現在のコンテナを新しいイメージとして保存する必要があります。データを永続化したり、複数のコンテナ間でデータを共有したりする場合は、データを Docker ボリュームに保存し、そのボリュームを対応するコンテナにマウントする必要があります。

ストレージ ドライバーは、イメージとコンテナーがファイル システムにどのように保存され、整理されるかを決定します。以下は、一般的な AUFS と Overlay の簡単な紹介です。

オーストラリア

AUFSの紹介

AUFS は、Debian (Stretch より前のバージョン。Stretch はデフォルトで Overlay2 を使用します) または Ubuntu システム上の Docker のデフォルトのストレージ ドライバーであり、すべての Docker ストレージ ドライバーの中で最も成熟しています。起動が速く、メモリやストレージを効率的に使用できるという特徴があります。 Linux カーネル バージョン 4.0 以上を使用しており、Docker CE を使用している場合は、Overlay2 (AUFS よりもパフォーマンスが優れています) の使用を検討してください。

AUFS ストレージ ドライバーの設定

①カーネルがAUFSをサポートしているか確認する

$ grep aufs /proc/filesystems  
ノード アウフス

②カーネルがサポートしている場合は、docker起動時にパラメータ--storage-driver=aufsを指定してAUFSを選択できます。

AUFSストレージドライバの仕組み

AUFS ストレージ ドライバーを使用する場合、イメージとコンテナに関するすべてのレイヤー情報は、3 つのサブディレクトリを持つ /var/lib/docker/aufs/ ディレクトリに保存されます。

• /diff: 各ディレクトリには、画像の各レイヤーの実際のコンテンツが保存されます
• /layers: イメージレイヤーの構成に関するメタ情報を格納します。ファイルの内容には、イメージのコンポーネント イメージ リストが格納されます。
• /mnt: マウントポイント情報の保存。コンテナが作成されると、コンテナに対応するレイヤーとコンテナの init レイヤーが mnt ディレクトリの下に表示されます。ディレクトリ名がコンテナ ID と一致しません。実際の読み取り/書き込みレイヤーは /var/lib/docker/aufs/diff に保存され、コンテナが削除されるまでクリアされません。

AUFS を使用した後、コンテナはどのようにファイルを読み書きするのでしょうか?

ファイルの読み取り

• コンテナがファイルを読み取るシナリオは 3 つあります。
• コンテナ レイヤーが存在しません: 読み取るファイルがコンテナ レイヤーに存在しません。ストレージ ドライバーは、イメージ レイヤーから下方向にレイヤーごとに検索します。複数の画像レイヤーに同じ名前のファイルが存在する場合、上位レイヤーにあるファイルが有効になります。
• ファイルはコンテナ層にのみ存在します: コンテナ層ファイルを読み取ります

コンテナレイヤーとイメージレイヤーは同時に存在します。コンテナレイヤーファイルを読み取ります。

ファイルまたはディレクトリを変更する

コンテナ内のファイルを変更するシナリオも 3 つあります。

• ファイルの最初の書き込み: 変更するファイルが特定のイメージ レイヤーにある場合、AUFS は最初に copy_up 操作を実行して、読み取り専用のイメージ レイヤーから読み取りおよび書き込み可能なコンテナー レイヤーにファイルをコピーし、その後ファイルを変更します。ファイルが非常に大きい場合、これは非効率的です。
• ファイルの削除: ファイルを削除するときに、そのファイルがイメージ レイヤーにある場合は、実際にはコンテナー レイヤーに特別な書き出しファイルが作成されます。コンテナ レイヤーはファイルにアクセスできず、ファイルは実際には削除されません。

ディレクトリ名の変更: 現在、AUFS はディレクトリ名の変更をサポートしていません。

オーバーレイFS

OverlayFS の紹介

OverlayFS は、AUFS に似た最新のユニオン ファイル システムですが、実装がよりシンプルでパフォーマンスが優れています。厳密に言えば、OverlayFS は Linux カーネルのファイルシステムです。対応する Docker ストレージ ドライバーは Overlay または Overlay2 です。 Overlay2 には Linux カーネル 4.0 以上が必要であり、Overlay にはカーネル 3.18 以上が必要です。現在、Docker Community Edition のみがこれをサポートしています。条件が許せば、Overlay よりも inode 使用率が高い Overlay2 を使用するようにしてください。

Overlay/Overlay2 を使用してコンテナ内のファイルを読み書きする方法

ファイルの読み取り

ファイルの読み取りには 3 つのシナリオがあります。

• コンテナ レイヤーにファイルが存在しない: コンテナが読み取ろうとしているファイルがコンテナ レイヤーに存在しない場合、コンテナは基になるイメージ レイヤーで検索を続けます。
• ファイルはコンテナ レイヤーにのみ存在します: コンテナによって読み取られるファイルがコンテナ レイヤーにある場合、そのファイルは基になるイメージ レイヤーを検索せずに直接読み取られます。
• ファイルはコンテナ層とイメージ層の両方に存在する: コンテナが読み込むファイルがコンテナ層とイメージ層の両方に存在する場合、コンテナ層から読み込まれます。

ファイルまたはディレクトリを変更する

ファイルの書き込みには 3 つのシナリオがあります。

• ***ファイルの書き込み: 書き込むファイルがイメージ レイヤーにある場合は、copy_up を実行してファイルをイメージ レイヤーからコンテナ レイヤーにコピーし、変更して新しいコピーをコンテナ レイヤーに保存します。ファイルが大きいと効率は低くなります。 OverlayFS はブロック レベルではなくファイル レベルで動作します。つまり、ファイルがわずかに変更され、ファイルが大きい場合でも、変更するにはファイル全体をコンテナー レイヤーにコピーする必要があります。ただし、copy_up 操作は最初にのみ実行されることに注意してください。後で同じファイルを変更する場合は、コンテナ レイヤー ファイルを操作するだけで済みます。
• ファイルまたはディレクトリの削除: コンテナ内のファイルまたはディレクトリを削除すると、実際にはコンテナ内に書き出しファイルが作成されます。ファイルは実際には削除されませんが、ユーザーには見えなくなります。
• ディレクトリ名の変更: rename(2)関数の呼び出しは、ソースパスとターゲットパスの両方がコンテナ層にある場合にのみ成功し、そうでない場合はEXDEVを返します。

リモート イメージ リポジトリはどのようにイメージを保存しますか?

Dockerをよく使う人も多いと思いますが、リモートイメージリポジトリにプッシュされたときにイメージをどのように保存するか考えたことはありますか？ Docker クライアントはリモート イメージ リポジトリとどのように対話しますか?

通常ローカルにインストールする Docker は、実際には Docker クライアントと Docker エンジンの 2 つの部分で構成されています。 Docker クライアントと Docker エンジンは API を介して通信します。 Docker エンジンが提供する API には、一般的に、認証、コンテナ、イメージ、ネットワーク、ボリューム、スウォームなどが含まれます。具体的な呼び出し形式については、Docker エンジン API (https://docs.docker.com/engine/api/v1.27/#) を参照してください。

Docker エンジンとレジストリ (つまり、リモート イメージ リポジトリ) 間の通信にも完全な API セットがあり、認証、承認、イメージの保存、およびイメージのプルとプッシュに関連するその他の関連プロセスを大まかにカバーします。詳細については、レジストリ API (https://github.com/docker/distribution/blob/master/docs/spec/api.md) を参照してください。一般的に使用されているレジストリ バージョンは v2 で、ブレークポイントの再開や複数レイヤーのイメージの同時プルなどの機能があります。複数のレイヤーを同時にプルできる理由は、イメージのメタデータがイメージ レイヤー データとは別に保存されるためです。イメージをプルするときは、まず認証してトークンを取得し、承認に合格してから、イメージ マニフェスト ファイルを取得して署名検証を実行します。検証が完了すると、マニフェスト内のレイヤー情報に従って各レイヤーが同時にプルされます。マニフェストには、リポジトリ名、タグ、イメージ レイヤー ダイジェストなどの情報が含まれます。詳細については、マニフェスト形式のドキュメント (https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-1.md) を参照してください。

各レイヤーがプルダウンされた後、最初にローカルで検証され、検証アルゴリズムでは sha256 が使用されます。プッシュ プロセスでは、まずイメージの各レイヤーがレジストリに同時にプッシュされます。プッシュが完了すると、イメージのマニフェストがレジストリにプッシュされます。実際のところ、レジストリは具体的な保管作業については責任を負いません。具体的な記憶媒体はユーザーが決定します。レジストリは標準のストレージ ドライバー インターフェイスのセットのみを提供し、特定のストレージ ドライバーの実装はユーザーによって実装されます。

現在、公式レジストリによってデフォルトで提供されるストレージ ドライバーには、Microsoft Azure、Google gcs、Amazon s3、OpenStack swift、Alibaba Cloud OSS、ローカル ストレージなどがあります。独自のオブジェクト ストレージ サービスを使用する必要がある場合は、レジストリ ストレージ ドライバーを自分で実装する必要があります。 NetEase Cloud は現在、独自のオブジェクト ストレージ サービス nos にイメージを保存しているため、nos 専用のストレージ ドライバーが実装されています。また、認証サービスもNetEase Cloud認証サービスに接続されており、独自の業務と組み合わせて一連の認証および認可ロジックを実装し、倉庫のクォータを効果的に制限します。

レジストリの動作は実は非常に単純で、大まかに分けると次のようになります。① 構成の読み取り。 ②ハンドラを登録する。 ③ 聞く。本質的に、レジストリは HTTP サービスです。起動後、設定ファイルに設定されたポートをリッスンします。 http リクエストが到着すると、以前に登録されたハンドラーがトリガーされます。ハンドラーには、マニフェスト、タグ、BLOB、BLOB アップロード、BLOB アップロード チャンク、カタログなどの 6 つのカテゴリが含まれます。詳細については、レジストリ ソース コード (/registry/handlers/app.go:92) を参照してください。構成ファイルには、リスニング ポート、認証アドレス、ストレージ ドライバー情報、コールバック通知などが含まれています。