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) を参照してください。構成ファイルには、リスニングポート、認証アドレス、ストレージドライバー情報、コールバック通知などが含まれています。

<<: 分散ストレージシステムの機能に関する簡単な説明

>>: プライベートクラウドとハイブリッドクラウドを成功させる4つの鍵