Dockerコンテナ技術のアーキテクチャとそのさまざまなモジュールを1つの記事で理解する

  [[278155]]

概要

今日は、Docker の技術アーキテクチャと、それを構成するさまざまなモジュールについて簡単に紹介します。

技術アーキテクチャ

ディストリビューションは、Dockerレジストリとやり取りし、v2レジストリに関連するイメージとソースデータをアップロードする役割を担います。

レジストリは、Docker レジストリ関連の認証、イメージ検索、イメージ検証、およびレジストリ ミラー相互作用の管理を担当します。

Image は、イメージ ソース データの保存と検索、イメージ レイヤーのインデックス作成と検索、イメージ tarball のインポートとエクスポート操作を担当します。

Reference は、すべてのローカル イメージのリポジトリとタグ名を保存し、それらとイメージ ID 間のマッピング関係を維持する役割を担います。

レイヤー モジュールは、イメージ レイヤーとコンテナ レイヤーのソース データの追加、削除、変更、クエリを担当し、イメージ レイヤーの追加、削除、変更、クエリを、イメージ レイヤー ファイルを実際に保存するグラフドライバー モジュールにマッピングする役割を担います。

Graghdriver は、コンテナ イメージに関連するすべての操作を実行します。

1. Dockerクライアント

Docker クライアントは、Docker アーキテクチャ内でユーザーが Docker デーモンとの通信を確立するために使用するクライアントです。ユーザーが使用する実行ファイルはDockerです。 Docker コマンドライン ツールを使用して、コンテナーを管理するためのさまざまなリクエストを開始できます。

docker クライアントがコンテナ管理要求を送信すると、docker デーモンがその要求を受信して​​処理します。 Docker クライアントが返されたリクエスト応答を受信して​​単純に処理すると、Docker クライアントのライフサイクル全体が終了します。コンテナ管理リクエストの送信を継続する必要がある場合、ユーザーは docker 実行可能ファイルを通じて docker クライアントを再度作成する必要があります。

2. Dockerデーモン

Docker デーモンは、Docker アーキテクチャのバックグラウンドに常駐するシステム プロセスです。その機能は、Docker クライアントから送信されたリクエストを受信して​​処理することです。デーモンはバックグラウンドでサーバーを起動し、サーバーの負荷は Docker クライアントから送信された要求を受け入れます。要求を受け入れた後、サーバーはルーティングと配布のスケジュール設定を通じて要求を実行するための対応するハンドラーを見つけます。

docker デーモンを起動するために使用される実行可能ファイルも docker であり、これは docker クライアントを起動するために使用される実行可能ファイル docker と同じです。 docker コマンドを実行すると、渡されるパラメータによって docker デーモンと docker クライアントが区別されます。

3. Dockerサーバー

Docker サーバーは、Docker アーキテクチャ内で Docker クライアントに特にサービスを提供するサーバーです。このサーバーの機能は、Docker クライアントから送信されたリクエストを受け入れてディスパッチすることです。アーキテクチャ図は次のとおりです。

Docker の起動プロセス中に、パッケージ gorilla/mux (golang のライブラリ解析) を通じて mux.Router が作成され、リクエスト ルーティング機能が提供されます。 Golang では、gorilla/mux は強力な URL ルーターおよびディスパッチャーです。多くのルーティング項目が mux.Router に追加されました。各ルーティング項目は、HTTP 要求メソッド (PUT、POST、GET、または DELETE)、URL、およびハンドラーの 3 つの部分で構成されます。

4.エンジン

Engine は、Docker アーキテクチャのランタイム エンジンであり、Docker 操作のコア モジュールでもあります。 Docker コンテナの保管倉庫としての役割を担い、ジョブを実行することでこれらのコンテナを操作・管理します。

エンジン データ構造の設計と実装には、ハンドラー オブジェクトがあります。ハンドラー オブジェクトには、多くの特定のジョブに対するハンドラー処理アクセスが格納されます。たとえば、エンジン ハンドラー オブジェクト内の項目の 1 つが {"create": daemon.ContainerCreate,} である場合、これは "create" という名前のジョブが実行中の場合、daemon.ContainerCreate のハンドラーが実行されることを意味します。

5. 仕事

ジョブは、Docker アーキテクチャのエンジン内で最も基本的な作業実行単位と考えることができます。 Docker が実行できるすべてのタスクは、ジョブとして抽象化できます。たとえば、コンテナ内でプロセスを実行することはジョブです。新しいコンテナを作成するのは仕事です。インターネットから文書をダウンロードするのは仕事です。前述の Docker サーバーのセクションで説明した内容を含め、HTTP API を提供するサーバーを作成することも仕事です。

Job の設計者は、Job を Unix プロセスに似たものに設計しました。たとえば、ジョブには名前、パラメーター、環境変数、標準入力と出力、エラー処理、戻りステータスなどがあります。

6. Dockerレジストリ

Docker Registry はコンテナイメージを保存するためのリポジトリです。コンテナ イメージは、コンテナの作成時にロードされ、コンテナのファイル構造とディレクトリが初期化されます。

Docker の動作中、Docker Daemon は Docker Registry と通信し、イメージの検索、イメージのダウンロード、イメージのアップロードという 3 つの機能を実装します。これら 3 つの機能に対応するジョブ名は、それぞれ「search」、「pull」、「push」です。

その中でも、Docker アーキテクチャでは、Docker はよく知られている Docker Hub であるパブリック Docker レジストリを使用できます。このように、Docker はコンテナ イメージ ファイルを取得するときに、インターネット経由で Docker Hub にアクセスする必要があります。同時に、Docker では、ユーザーがローカルのプライベート Docker レジストリを構築することも可能で、これにより、コンテナ イメージの取得がイントラネット上で完了することが保証されます。

7. グラフ

Graph は、Docker アーキテクチャでダウンロードされたコンテナ イメージの管理者としての役割と、ダウンロードされたコンテナ イメージ間の関係を記録する役割を担います。 Graph は、一方ではバージョン情報を含むローカル ファイル システム イメージを保存し、他方では GraphDB を通じてすべてのファイル システム イメージ間の関係を記録します。 Graph のアーキテクチャは次のとおりです。

その中で、GraphDB は SQLite 上に構築された小さなグラフ データベースであり、ノードの命名とノード間の関係の記録を実現します。これは、ほとんどのグラフ データベースが持つ機能のごく一部だけを実装していますが、ノード間の関係を表すためのシンプルなインターフェイスを提供します。

同時に、Graph のローカル ディレクトリには、各コンテナ イメージに関する特定の情報として、コンテナ イメージのメタデータ、コンテナ イメージのサイズ情報、コンテナ イメージによって表される特定の rootfs が保存されます。

8. ドライバー

ドライバーは、Docker アーキテクチャのドライバー モジュールです。 Docker は Driver を通じて Docker コンテナ実行環境をカスタマイズできます。 Docker のライフサイクル中、すべてのユーザー操作が Docker コンテナの管理のためであるとは限りません。また、Docker の動作情報の取得やグラフの保存・記録などに関する操作もあります。そこで、Docker コンテナの管理と Docker Daemon の内部ビジネスロジックを分離するために、これらの要求をすべて引き受ける Driver 層のドライバーが設計されています。

9. libコンテナ

libcontainer は、Docker アーキテクチャで Go 言語で設計および実装されたライブラリです。設計の本来の目的は、ライブラリが依存関係に依存せずにカーネル内のコンテナ関連 API に直接アクセスできるようにすることです。

libcontainer が存在するからこそ、Docker は libcontainer を直接呼び出して、最終的にコンテナの名前空間、cgroup、apparmor、ネットワーク デバイス、ファイアウォール ルールを操作できるのです。この一連の操作を完了するには、LXC や他のパッケージに依存する必要はありません。 libcontainer のアーキテクチャは次のとおりです。

さらに、libcontainer は、コンテナ管理の上位層の要件を満たすための完全な標準インターフェース セットを提供します。つまり、libcontainer は Docker の上位層によるコンテナの直接管理をブロックします。また、libcontainer はクロスプラットフォーム言語 Go を使用して開発および実装されており、さまざまな上位プログラミング言語からアクセスできるため、将来的に Docker が Linux と密接に結びつくかどうかはわかりません。同時に、Microsoft は有名なクラウド コンピューティング プラットフォーム Azure に Docker のサポートを追加しました。これは、Docker のオープン性と業界での人気を示しています。

10. Dockerコンテナ

Docker コンテナは、Docker アーキテクチャにおけるサービス配信の究極の形式です。

Docker は、ユーザーのニーズと指示に応じて、対応する Docker コンテナをカスタマイズします。

コンテナイメージを指定することにより、ユーザーは Docker コンテナの rootfs やその他のファイルシステムをカスタマイズできます。コンピューティング リソースの割り当てを指定することにより、ユーザーは Docker コンテナに指定されたコンピューティング リソースを使用させることができます。ネットワークとそのセキュリティ ポリシーを構成することにより、ユーザーは Docker コンテナに独立した安全なネットワーク環境を持たせることができます。実行するコマンドを指定することにより、ユーザーは Docker コンテナに指定された作業を実行させることができます。