【クラウドネイティブ】Docker詳細解説(2):Dockerのアーキテクチャと動作原理

Dockerの詳しい解説(2):Dockerのアーキテクチャと動作原理

Docker はDocker エンジン(サーバー デーモン プロセス) と実行時のクライアント ツールに分かれており、私たちは日々さまざまなDocker コマンドを使用していますが、実際にはDocker エンジン対話するためにクライアント ツールを使用しています。
ここに画像の説明を挿入

1. クライアント クライアント

Docker はクライアントサーバー (C/S) アーキテクチャのプログラムです。Docker クライアントは Docker サーバーまたはデーモンにリクエストを行うだけでよく、サーバーまたはデーモンがすべての作業を実行して結果を返します。Docker は、コマンド ライン ツール Docker と RESTful API のセットを提供します。Docker デーモンとクライアントを同じホスト上で実行することも、ローカル Docker クライアントから別のホストで実行されているリモート Docker デーモンに接続することもできます。

2.ホストホスト(Dockerエンジン)

Docker デーモンとコンテナーを実行する物理マシンまたは仮想マシン。

3. 鏡像

Docker イメージとは何ですか? 簡単に言うと、Docker イメージはLinux ファイル システム(Root FileSystem) であり、Linux カーネル上で実行できるプログラムと対応するデータが含まれています。

ミラーを介してコンテナを起動します。ミラーは実行可能パッケージであり、コード、ランタイム、ライブラリ、環境変数、構成ファイルなど、アプリケーションの実行に必要なものがすべて含まれています。

Docker はアプリ ファイルをミラーにパッケージ化し、複数のスナップショットと同様のストレージ テクノロジを使用して、次のことを実現します。

  • 複数のアプリが同じ基礎イメージ (初期オペレーティング システム イメージ) を共有できます。
  • アプリ実行時の IO 操作とイメージ ファイルの分離。
  • さまざまな構成/データ ファイルを含むディレクトリまたはボリュームをマウントすることで、単一のアプリ イメージを使用してさまざまなビジネスの無数のコンテナを実行できます。

4. コンテナコンテナ

イメージ(Image) とコンテナー(Container) の関係は、オブジェクト指向プログラミングにおけるクラスとインスタンスのようなもので、イメージは静的な定義であり、コンテナーはイメージ ランタイムの実体です。コンテナーは作成、開始、停止、削除、一時停止などができます。

5. ミラーレイヤリング

Docker は、既存のイメージを拡張することによる新しいイメージの作成をサポートしています。実際、 Docker Hub の99 % 99\%イメージの99% は、基本イメージに必要なソフトウェアをインストールして構成することによって構築されます。

ここに画像の説明を挿入
上の図からわかるように、新しい画像はベース画像からレイヤーごとに生成されます。ソフトウェアがインストールされるたびに、既存のイメージにレイヤーが追加されます。

ミラー レイヤ化の最大の利点の 1 つは、リソースの共有です。たとえば、複数のイメージが同じベース イメージから構築されている場合、Docker ホストは 1 つのベース イメージをディスクに保存するだけで済み、同時に、すべてのコンテナにサービスを提供するために 1 つのベース イメージをメモリにロードするだけで済みます。また、画像のすべてのレイヤーを共有できます。

複数のコンテナーがベース イメージを共有する場合、コンテナーが以下のファイルなどのベース イメージのコンテンツを変更すると、/etc他のコンテナーは/etc変更されず、変更は 1 つのコンテナーにのみ制限されます。これはコンテナーのコピーオンライト機能です。

6. 書き込み可能なコンテナ層

コンテナが起動すると、新しい書き込み可能なレイヤーが画像の上にロードされます。この層は通常、コンテナ層と呼ばれ、コンテナ層の下にあるものはすべてイメージ層と呼ばれます

ここに画像の説明を挿入
ファイルの追加、削除、変更など、コンテナーに対するすべての変更はコンテナー層でのみ行われます。コンテナー レイヤーのみが書き込み可能でコンテナー レイヤーの下にあるすべてのイメージ レイヤーは読み取り専用です

多くのミラー層が存在する可能性があり、すべてのミラー層が結合されて、統一されたファイル システムが形成されます。たとえば、異なるレイヤーに同じパスを持つファイルがある場合、/a上位レイヤーは/a下位レイヤーを上書きします/a。つまり、ユーザーは上位レイヤーのファイルにのみアクセスできます/aコンテナ層では、ユーザーに見えるのは重ね合わせられたファイル システムです。

ファイル操作 説明する
追加ファイル コンテナ内にファイルが作成されると、新しいファイルがコンテナ レイヤーに追加されます。
ファイルを読み取る コンテナー内のファイルを読み取るとき、Docker は各イメージ レイヤー内のファイルを上から下に検索します。見つかると、すぐにコンテナー層にコピーされ、開かれてメモリに読み込まれます。
ファイルを変更する コンテナー内の既存のファイルを変更する場合、Docker は各イメージ レイヤーでこのファイルを上から下に検索します。見つかったら、それをコンテナー層にコピーして変更します。
ファイルの削除 コンテナ内のファイルを削除するとき、Docker はイメージ レイヤー内のファイルを上から下に検索し、コンテナ レイヤー内の削除操作を見つけて記録します。(削除操作をログに記録するだけです)

データを変更する必要がある場合にのみ、データのコピーをコピーします。この機能は、コピーオンライトと呼ばれます。コンテナー層は画像の変更された部分を保存し、画像自体には何も変更を加えていないことがわかります。

要約すると、コンテナ レイヤーはイメージの変更を記録し、すべてのイメージ レイヤーは読み取り専用でコンテナによって変更されないため、イメージは複数のコンテナで共有できます。

7. データ量 ボリューム

実際、コンテナはオペレーティング システムの簡易版のようなものですが、システムにはプログラムの実行に必要な環境のみがインストールされています。前述したように、コンテナは削除できます。削除された場合、コンテナはどうなるでしょうか。プログラムによって生成されたデータを永続化する必要があるか? コンテナが実行されているときは、コンテナに入って確認できますが、コンテナが削除されると、何もなくなります。

データ ボリュームは、この問題を解決するために使用されます。データ ボリュームは、ホスト上にデータを永続化し、コンテナとデータを共有するために使用されます。簡単に言えば、ホストのディレクトリをコンテナ内のディレクトリにマップすることです。読み取りデータと書き込みデータディレクトリ内のファイルはホストに同期されるため、コンテナによって生成されたデータは永続化されます。たとえば、データベース コンテナはホスト上の実際のディスクにデータを保存できます。

8. 登録センターのレジストリ

Docker はレジストリを使用してユーザーが作成したイメージを保存します。レジストリはパブリックとプライベートに分かれています。Docker 会社は、Docker Hubと呼ばれるパブリック レジストリを運用しています。ユーザーはDocker Hubにアカウントを登録し、独自のイメージを共有、保存できます。

Docker 社は、パブリック ミラー ウェアハウスhttps://hub.docker.com (Docker ではこれをリポジトリと呼びます) を提供し、使用するミラーの膨大なコレクションを提供します。

Docker レジストリには複数のウェアハウス (リポジトリ) を含めることができ、各ウェアハウスには複数のタグ (タグ) を含めることができ、各タグはミラー イメージに対応します。

通常、ウェアハウスには同じソフトウェアの異なるバージョンのイメージが含まれており、タグはソフトウェアの各バージョンに対応しています。<ウェアハウス名>:<ラベル>の形式を使用して、ソフトウェアのどのバージョンがミラー イメージであるかを指定できます。latestラベルが指定されていない場合は、デフォルトのラベルとして使用されます。

9. まとめ

Docker の公式 Web サイトには次の文が書かれています: Build, Ship, and Run Any App, Anywhere、これまで理解した内容と組み合わせると、これは次のように要約できます: build 一度作成すれば、どこでも実行できます

ここに画像の説明を挿入
さらに、Docker はパブリック ミラー ウェアハウスhttps://hub.docker.com (Docker ではリポジトリと呼びます)、GitHub 接続を提供し、ミラーを自動的に構築することで、アプリケーションの配布、展開、およびアップグレードのプロセスを大幅に簡素化します。さらに、Docker はさまざまなカスタム イメージ ファイルを簡単に作成できます。これは、Docker が最も人気のあるコンテナ テクノロジになるための重要な要素です。

上記のテクノロジーを組み合わせることで、最終的な結果は次のようになります。ほとんどのアプリケーションでは、開発者は を介し​​てdocker buildイメージを作成し、 をdocker push介してイメージをアップロードし、ユーザーは をdocker pull介し​​てイメージをダウンロードし、 を使用してdocker runコンテナ アプリケーションを実行できます。ユーザーは、環境のセットアップ方法、インストール方法、および異なるディストリビューションのライブラリの競合の解決方法を気にする必要がなくなり、通常、ハードウェア リソースの消費が増加したり、パフォーマンスが大幅に低下したりすることはありません。

おすすめ

転載: blog.csdn.net/be_racle/article/details/132220490