Docker イメージの原理: 共同ファイル システムと階層化された理解 (詳細な例)

この記事では、共同ファイル システム、階層構造、階層化プラクティスに関連する問題など、共同ファイル システムと、Docker イメージの原則の階層化された理解に関する関連知識を提供します。

Docker—ユニオン ファイル システムとミラーリング原理の階層的理解

1. ユニオン ファイル システム

UnionFS( Unionファイル システム)

UnionFS (Union File System): Union File System (UnionFS) は、1 つのサブミッションを適用できるレイヤーとしてファイル システムへの変更をサポートする、階層型で軽量かつ高性能のファイル システムです。レイヤーごとに、異なるディレクトリを同じ仮想ファイル システムにマウントできます (複数のディレクトリを 1 つの仮想ファイル システムに結合します)。 Union ファイル システムは Docker イメージの基礎です。階層化によるイメージの継承が可能で、ベースイメージ（親イメージなし）をベースに、さまざまな具体的なアプリケーションイメージを生成できます。

さらに、異なる Docker コンテナはいくつかの基本的なファイル システム レイヤーを共有し、同時に独自の変更レイヤーを追加できるため、ストレージ効率が大幅に向上します。

Docker で使用される AUFS (AnotherUnionFS) は、ユニオン ファイル システムです。 AUFS は、各メンバー ディレクトリの読み取り専用、読み取り書き込み、およびホワイトアウト可能なアクセス許可の設定をサポートしています (Git ブランチと同様)。同時に、AUFS には階層に似た概念があります。読み取り専用アクセス許可の場合、アクセス許可ブランチは論理的に段階的に変更できます (読み取り専用部分には影響を与えません)。

Docker は現在、AUFS、btrfs、vfs、DeviceMapper などのジョイント ファイル システム タイプをサポートしています。

機能: 複数のファイル システムを同時にロードしますが、外部からは 1 つのファイル システムしか見えません。共同ロードではファイル システムの各層が重ね合わされるため、最終的なファイル システムには基礎となるすべてのファイル システムが含まれます。ファイル、ファイルとディレクトリ。

ベース ミラー

ベース ミラーは、他のミラーに依存しないことを意味します。完全に最初から構築され、他のミラーはその上に構築されます。これは、建物の基礎や Docker ミラーリングの起源にたとえることができます。

ベースイメージには 2 つの意味があります: (1) 他のイメージに依存せず、最初から構築される、(2) それをベースに他のイメージを拡張できる。

つまり、基本イメージと呼ばれるものは、通常、Ubuntu、Debian、CentOS などのさまざまな Linux ディストリビューションの Docker イメージです。

Docker イメージの読み込み原理

Docker のイメージは実際にはレイヤーごとのファイル システムで構成されており、このファイル システムのレイヤーは UnionFS です。

一般的な Linux では、起動して実行するには 2 つの FS が必要です。bootfs rootfs:

bootfs (ブート ファイル システム) には主に bpotloader とカーネルが含まれ、bootloader には主に Bootカーネルをロードすると、Linux は最初の起動時に bootfs ファイル システムをロードします。Docker イメージの最下層は bootfs です。この層は、ブート ローダー ブートローダーやカーネル カーネルなど、一般的な Linux/Unix システムと同じです。ブートのロードが完了すると、カーネル全体がメモリ内に存在します。この時点で、メモリの使用権は bootfs からカーネルに転送されます。このとき、システムは bootfs もアンインストールします。

rootfs (ルート ファイル システム)、bootfs の上にあります。一般的な Linux システムの /dev、/proc、/bin、/etc などの標準ディレクトリとファイルが含まれます。ルートは、Ubuntu、Centos などのさまざまなオペレーティング システム ディストリビューションです。

Docker イメージにカーネルがないのはなぜですか?

イメージ サイズに関して言えば、比較的小さなイメージは 1 KB をわずかに超えるか、数 MB です。一方、カーネル ファイルには数 10 MB が必要なので、イメージにはカーネルはありません。コンテナとして開始された後、イメージはホストのカーネルを直接使用し、イメージ自体は対応する rootfs (ユーザー空間ファイル) のみを提供します。 /dev/、/proc、/bin、/etc およびその他のディレクトリなど、システムの通常の動作に必要なシステムが存在するため、コンテナ内には基本的に /boot ディレクトリは存在せず、/boot にはシステムに関連するファイルとディレクトリが格納されます。カーネル。

コンテナはホストのカーネルを使用して直接起動および実行され、物理ハードウェアを直接呼び出さないため、ハードウェア ドライバーが関与せず、カーネルとドライバーは使用されません。仮想マシン テクノロジの場合、各仮想マシンは独自の独立したカーネルを持ちます。

2. 階層構造

Docker イメージは階層構造になっており、各層はその上の他の層の上に構築され、機能を実現します。コンテンツを段階的に追加すると、Docker イメージもレイヤーでダウンロードされます。例として Redis イメージのダウンロードを考えてみましょう:

可能な限り新しいイメージはベースイメージからレイヤーごとに生成されます。ソフトウェアをインストールするたびに、既存のイメージにレイヤーを追加します。

Docker イメージはなぜこの階層構造を採用しているのでしょうか?

最大のメリットはリソースの共有です。たとえば、複数のイメージが同じベース イメージから構築されている場合、ホストはディスク上に 1 つのベース イメージを保持するだけでよく、メモリにロードする必要があるのは 1 つのベース イメージだけであるため、すべてのコンテナにサービスを提供できます。画像の各レイヤーを共有することができます。

書き込み可能なコンテナ レイヤー

Docker イメージは読み取り専用です。コンテナが起動すると、新しい書き込み可能なレイヤーがミラー トップに読み込まれます。

この新しいレイヤーは書き込み可能なコンテナーレイヤーであり、コンテナーの下にあるものはすべてミラーレイヤーと呼ばれます。

Docker は、コピーオンライト戦略を使用して、基本イメージのセキュリティを確保し、パフォーマンスとスペース使用率を向上させます。

• コンテナがファイルを読み取る必要がある場合

最上位の画像レイヤーから開始して下方向に検索し、見つかったらメモリに読み込みます。すでに存在する場合は、それをメモリに読み込みます。メモリ内の 、 を直接使用できます。つまり、同じマシン上で実行されている Docker コンテナは、実行時に同じファイルを共有します。

• コンテナがファイルを変更する必要がある場合

上から下に検索し、見つかったらそれをコンテナ層にコピーします。はコンテナ レイヤーです。このファイルの場合、イメージ レイヤーのファイルを確認して、コンテナ レイヤーのファイルを直接変更することはできません。

• コンテナでファイルを削除する必要がある場合

上から下に検索し、見つかったらコンテナに削除を記録します。これは実際の削除ではありません。 、しかしソフトな削除。これにより、画像サイズは増加するだけで、減少しません。

• コンテナがファイルを追加する必要がある場合

イメージ レイヤーに影響を与えずに、ファイルをコンテナの最上位の書き込み可能なレイヤーに直接追加します。

ファイルの追加、削除、変更など、コンテナーに対するすべての変更はコンテナー層でのみ行われます。コンテナー レイヤーのみが書き込み可能で、コンテナー レイヤーの下にあるすべてのイメージ レイヤーは読み取り専用であるため、イメージは複数のコンテナーで共有できます。

3. レイヤー化の練習 - イメージの送信をコミットする

イメージを通じてコン​​テナーを作成し、コンテナー レイヤーを操作し、イメージ レイヤーを変更しないで、コンテナー レイヤーとイメージ レイヤーをパッケージ化します。操作後は新規画像として送信してください。

docker commit: コンテナーを使用して新しいイメージを作成します。

構文:

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

OPTIONS 説明:

• **-a*ミラー作成者が送信;
• **-c *Dockerfile 命令を使用してイメージを作成します;
• **-m *送信時の説明テキスト;
• **-p *コミット時にコンテナを一時停止します。

使用例: イメージを通じてコン​​テナを作成し、コンテナ レイヤーを操作して、操作したコンテナ レイヤーとイメージ レイヤーを新しいイメージにパッケージ化して送信します。

1. まず Tomcat イメージをダウンロードします

2. Tomcat イメージを使用して Tomcat コンテナを作成して実行します:

docker run -d --name="tomcat01" tomcat

3. 実行中の Tomcat コンテナに入ります:

docker exec -it tomcat01 /bin/bash

4. Tomcat コンテナの webapps.dist ディレクトリ内のファイルを webapps ディレクトリにコピーします:

cp -r webapps.dist/* webapps

5. Docker commit commit image

コンテナ dc904437d987 を新しいイメージ、送信者情報と説明情報を追加します。送信されたイメージの名前は tomcatplus で、バージョンは 1.0 です:

docker commit -a="wanli" -m="add webapps files" dc904437d987 tomcatplus:1.0

新しい Tomcat イメージのサイズが変更されたことがわかります。 commit は元のイメージよりも大きくなりますが、ファイルをコンテナー層にコピーするため、Tomcat イメージは少し大きくなります。

推奨学習: 「docker ビデオ チュートリアル 」

以上がDocker イメージの原理: 共同ファイル システムと階層化された理解 (詳細な例)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。