Dockerコアの概念
鏡像
ミラーリングとは何ですか？素人の用語では、これは読み取り専用のファイルとフォルダーの組み合わせです。これには、コンテナーの実行時に必要なすべての基本ファイルと構成情報が含まれており、コンテナーの起動の基礎となります。したがって、コンテナを起動する場合は、最初にミラーが必要です。
ミラーリングは、Dockerコンテナーを起動するための前提条件です。
ミラーを使用する場合は、次の2つの方法を使用できます。
1.自分でミラーを作成します。
通常、イメージは基本イメージに基づいて作成され、ユーザー定義のコンテンツを基本イメージに追加できます。
たとえば、centosイメージに基づいて独自のビジネスイメージを作成し、最初にnginxサービスをインストールしてからアプリケーションをデプロイし、最後にカスタム構成を行って、独自のビジネスイメージの準備を整えることができます。
2.他の人が作成したミラーイメージを機能ミラーウェアハウスから引き出します。
一般的に使用されるソフトウェアまたはシステムの中には、公式の画像が含まれているものがあります。
例：nginx、ubuntu、centos、mysqlなど。DockerHubにアクセスして、それらを検索してダウンロードできます。
容器
コンテナとは何ですか？
コンテナーは、Dockerのもう1つのコアコンセプトです。素人の言葉で言えば、コンテナはイメージの実行エンティティです。
イメージは静的な読み取り専用ファイルであり、コンテナーには実行時に必要な書き込み可能なファイルレイヤーがあり、コンテナー内のプロセスは実行状態にあります。つまり、コンテナは実際のアプリケーションプロセスを実行しています。
コンテナには、初期作成、実行、停止、一時停止、削除の5つの状態があります。
コンテナーの本質はホスト上で実行されるプロセスですが、コンテナーには独自の独立した名前空間の分離とリソースの制限があります。つまり、コンテナ内では、ホスト上のプロセス、環境変数、ネットワーク、およびその他の情報を確認できません。これは、コンテナとホスト上で直接実行されているプロセスの本質的な違いです。
倉庫
Dockerのミラーウェアハウスはコードウェアハウスに似ており、Dockerイメージの保存と配布に使用されます。ミラーウェアハウスは、パブリックミラーウェアハウスとプライベートミラーウェアハウスに分かれています。
現在、Docker Hub（https://hub.docker.com/）はDockerの公式パブリックミラーリポジトリであり、アプリケーションやオペレーティングシステムの公式ミラーだけでなく、組織や個人によって開発されたミラーも多数あります。無料で保存、ダウンロード、調査、使用します。パブリックミラーリポジトリに加えて、独自のプライベートミラーリポジトリを構築することもできます。
ミラー、コンテナ、およびウェアハウス間の接続を次の図に示します。

上図からわかるように、画像はコンテナの要であり、コンテナは画像によって作成されます。1つのイメージで複数のコンテナーを作成できます。コンテナーは、イメージが実行されるエンティティです。ウェアハウスは、画像の保存と配布に使用されます。
Dockerのコアアーキテクチャ
Dockerのコアアーキテクチャを理解する前に、コンテナ開発の歴史を簡単に紹介しましょう。
Dockerは2013年に瞬く間にヒットし、それ以来ITの世界で興奮を呼び起こし続け、コンテナーテクノロジーの代名詞となっています。しかし現時点では、Dockerコンテナーに加えて、CoreOSのrkt、lxcなど、他の多くのコンテナーテクノロジーが市場に出回っています。
CoreOSチームは、独自のコンテナソフトウェアrktを立ち上げることに加えて、Linuxカーネルに基づいた軽量のオペレーティングシステムも作成しました。オープンソースプロジェクトのDockerと同様に、rktは、コンテナーの作成を可能にするコンテナー実行バージョンです。
非常に多くのコンテナ技術の出現は、必然的にいくつかの問題を引き起こします。たとえば、コンテナ技術の標準は何ですか？誰がコンテナ標準を作成する必要がありますか？
おそらくほとんどの人は、Dockerがコンテナーテクノロジーのベンチマークになっていると言うでしょう。Dockerをコンテナーテクノロジーの標準と見なすのは良いことではありませんか？事実は想像したほど単純ではありません。当時、コンテナの基準をめぐる論争だけでなく、オーケストレーション技術をめぐる激しい論争もあったからです。当時、オーケストレーションテクノロジーには、Docker Swarm、Kubernetes、Mesosの3つの主要な力がありました。
Swarmは間違いなくDockerを唯一のコンテナーランタイムとして使用することをいとわないが、KubernetesとMesosは、スケジューリングの形で単一になりすぎたくないため、同意しません。
この文脈で、コンテナ戦争がついに勃発し、OCIがこの文脈で生まれました。
OCIのフルネームはOpenContainer Initiative（Open Container Initiative）であり、これは軽量でオープンなガバナンス構造です。Linux Foundationの強力なサポートにより、OCI組織は正式に登録され、2015年6月に設立されました。この財団は、工業化されたコンテナのフォーマットとイメージランタイムに関するユーザー向けのオープンコンテナ標準を開発することを目的としています。
現在、主に2つの標準ドキュメントがあります。コンテナランタイム標準（ランタイム仕様）とコンテナイメージ標準（イメージ仕様）です。
Dockerが戦争中にいくつかの技術アーキテクチャを変更しなければならなかったのは、まさにコンテナ戦争のためです。最終的に、次の図に示す技術アーキテクチャが形成されました。

Dockerの全体的なアーキテクチャーは、主にクライアントとサーバーの2つの部分で構成されるC / S（クライアント/サーバー）モデルを採用していることがわかります。
クライアントは操作命令の送信を担当し、サーバーは命令の受信と処理を担当します。同じマシン上のUNIXソケットを介して、またはネットワーク接続を介してリモート通信することにより、クライアントとサーバー間で通信する方法は多数あります。
以下は、クライアントとサーバーの概要です。
Dockerクライアント
Dockerクライアントは実際には一般的な用語です。dockerコマンドは、DockerユーザーがDockerサーバーと対話するための主な方法です。
dockerコマンドの使用に加えて、REST APIにDockerサーバーとの対話を直接要求することもできます。また、さまざまな言語のSDKを使用してDockerサーバーと対話することもできます。現在、コミュニティはGo、Java、Python、PHPなどの数十の言語でSDKを維持しており、これらはすべての人の日常のニーズを満たすのに十分です。
Dockerサーバー
Dockerサーバーは、すべてのDockerバックグラウンドサービスの総称です。その中でも、dockerdは非常に重要なバックグラウンド管理プロセスであり、Dockerクライアントからの要求に応答して処理し、クライアントの要求をDockerの特定の操作に変換します。
例：ミラー、コンテナー、ネットワーク、マウントされたボリュームなどの特定のオブジェクトの操作と管理。
Dockerの誕生以来、サーバーは多くの再構築を受けてきました。最初は、サーバーのコンポーネントはすべてDockerバイナリに統合されていました。ただし、バージョン1.11以降、dockerdは独立したバイナリになりました。現時点では、コンテナーはdockerdによって直接開始されるのではなく、containerdやrunCなどの複数のコンポーネントを統合します。
Dockerのアーキテクチャは常にリファクタリングされていますが、各モジュールの基本的な機能と位置は変更されていません。これは、一般的なC / Sアーキテクチャシステムと同じです。Dockerサーバー側モジュールは、Dockerクライアントと対話し、コンテナー、イメージ、ネットワークなどのDockerのリソースを管理します。
Dockerの重要なコンポーネント
Dockerには、runCとcontainerdという2つの重要なコンポーネントがあります。
runCは、OCIコンテナランタイム標準に従ったDockerの公式実装です。素人の言葉で言えば、runCはコンテナーを実行するために使用される軽量ツールであり、実際にはコンテナーを実行するために使用されます。
Containerdは、Dockerサーバーのコアコンポーネントであり、dockerdから削除されています。その誕生は、OCI標準に完全に準拠しており、コンテナー標準化の成果です。Containerdは、containerd-shimを介してrunCを起動および管理しますが、containerdは実際にコンテナーのライフサイクルを管理していると言えます。
図3からわかるように、dockerdはgRPCを介してcontaineredと通信します。dockerdは実際のコンテナーで実行されているため、runCの中央にcontainerのOCI標準レイヤーがあり、dockerdはインターフェースの下位互換性を確保できます。
gRPCはリモートサービスコールです。詳細については、https：//grpc.io
containerd-shimを参照してください。これは、ワッシャーを意味します。これは、ねじをねじ込むときにねじとナットの間に挟まれたワッシャーに似ています。
containerd-shimの主な機能は、containerd-shimを実際のコンテナープロセスから切り離し、containerd-shimをコンテナープロセスの親プロセスとして使用して、dockerdを再起動しても既に開始されているコンテナープロセスに影響を与えないようにすることです。
dockerd、containerd、runCの関係を理解したら、Dockerコンテナーを起動して、それらのプロセス間の関係を確認できます。
Dockerコンポーネント間の関係
例としてDockerのバージョン18.09.2を取り上げます（次のコマンドを実行しても期待される結果が出力されない場合は、Dockerバージョンに問題がある可能性があります）。
まず、次のコマンドでdocker101tutorialコンテナーを起動します。
$ docker run -d docker101tutorial sleep 5000コンテナーが開始されたら、次のコマンドを使用してdockerdのPIDを確認します。
$ sudo ps aux |grep dockerd
root 4247 0.3 0.2 1447892 83236 ? Ssl Jul09 245:59 /usr/bin/dockerd上記の出力から、dockerdのPIDは4247であることがわかります。上の図のDockerコンポーネント間の呼び出し関係を確認するには、pstreeコマンドを使用してプロセスの親子関係を確認します。
$ sudo pstree -l -a -A 4247
dockerd
|-containerd --config /var/run/docker/containerd/containerd.toml --log-level info
| |-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/d14d20507073e5743e607efd616571c834f1a914f903db6279b8de4b5ba3a45a -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
| | |-sleep 5000実際、dockerdが起動すると、containerdが起動され、dockerdとcontainerdは常に存在します。
docker runコマンド（docker101tutorialイメージを使用してコンテナーを作成および開始）を実行すると、containerdはcontainerd-shimを作成して「shim」プロセスとして機能し、コンテナーの実際のプロセスsleep5000を開始します。このことから、このプロセスはアーキテクチャ図と完全に一致しているように見えます。
上記のコンテンツは、今日共有されているすべてです。Dockerをより適切に使用および使用するには、Dockerアーキテクチャのコア設計概念であるミラーリング、コンテナー、およびウェアハウスの原則を習得する必要があります。
[The Way of Infinite Testing]パブリックアカウントへの注目、[リソースの受信]への返信、
Pythonプログラミング学習リソースの乾物、
Python + AppiumフレームワークAPPUI自動化、
Python + Seleniumフレームワーク
WebUI自動化、Python + UnittestフレームワークAPIへようこそオートメーション、
リソースとコードは無料で送信されます〜
記事の下部に公式アカウントのQRコードがあります。WeChatでスキャンしてフォローするだけです。
備考：私の個人公開アカウントが正式に開設され、ビッグデータテスト、機能テスト、テスト開発、APIインターフェイスの自動化、テストの運用と保守、UI自動化テストなどのテストテクノロジーの共有に専念しています。WeChat検索パブリックアカウント：「WuliangThe Way of Testing」、または以下のQRコードをスキャンしてください。
注意を向けて、一緒に成長しましょう！