containerdの仕組み
containerdはDockerの以前の部分であり、 containersを実行するための実行可能環境を実装するスタンドアロンソリューションになりました 。 開発者によると、作成時に、彼らはシンプルさ、信頼性、移植性を求めて努力しました。
「物理的に」は、コンテナのライフサイクル全体を管理するホストシステム上のデーモンです。イメージの受信と保存から、コンテナの起動（ runCを介して-詳細は以下を参照）とその操作の制御まで。 ローカルUNIXソケットを介して低レベルgRPC APIを使用してcontainerdデーモンと対話できます。また、コンソールユーティリティctrは実験およびデバッグにも使用できます（gRPC APIも使用します） 。 ソースコードはGoで記述され、Apache License 2.0の下でGitHubで入手できます。
containerdが動作する基本的なプリミティブは、 バンドルとコンテナーです。 実行中のコンテナーはrunCで、これはlibcontainerを使用するGoで作成されたユーティリティで、2015年のDockerとは別のものです。 OCIランタイム仕様に従って動作し、コンテナをその子プロセスとして実行します。 開始するには、ルートファイルシステムと構成のみが必要です（他のすべて：イメージの取得、アンパックなど-そのために「舞台裏」のままです） 。
バンドルには、構成、メタデータ、およびルートファイルシステムデータが含まれます。 これらは、実行中のコンテナ（最も単純な場合、これはFSの通常のディレクトリ）のディスク表現であり、他のシステムに転送、パッケージ化、および配布できます。 基本的に、コンテナ化されたデバイス全体がバンドルの作成と起動を調整します。
アーキテクチャの詳細
コンテナ化されたコンポーネントは、次のサブシステムを形成します。
- 配布-コンテナーイメージを提供するサービス。
- バンドルは、ディスクイメージからバンドルを抽出（およびパッケージ化）できるサービスです。
- ランタイム-バンドルを実行するサービス（runCを呼び出して、渡されたパラメーターでコンテナーを起動します）。
各サブシステムには、その動作を実装する1つ以上のコンポーネントがあります。 コンテナ化されたユーザーがgRPC APIを介してアクセスするのは、サブシステムによって提供されるサービスです。
異なるサブシステムと同時に動作するコンテナ化されたコンポーネントはモジュールと呼ばれ、次のように表されます。
- コンテナの直接起動を実装するエグゼキューター。
- コンテナのステータスを制御および反映するスーパーバイザー。
- メタデータ。メタデータをグラフデータベースに保存します。
- アドレス可能なコンテンツリポジトリ（永続データ）へのアクセスを提供するコンテンツ。
- スナップショット、コンテナイメージのファイルシステムスナップショットの管理。 今日のDockerにおけるgraphdriverの類似物。 レイヤーはスナップショットで解凍されます。
- イベントの動作と監査機能を実装するイベント。
- メトリックス。さまざまなコンポーネントのメトリックスの（APIによる）可用性を提供します。
合わせて、次のようになります。
仕組み
図とその説明は、 containted / design / architectureドキュメントから取得されています。
- 配布サブシステムのコントローラーに要求が送られ、目的のイメージが取得されます。 イメージのコンテンツをContentストアに配置し、イメージ名とルートマニフェストへのポインターがメタデータストアに登録されます。
- イメージを受信すると、ユーザーは（バンドルコントローラーを介して）イメージをバンドルで解凍できます。 このイメージのレイヤー（Content Storeから取得）は、スナップショットモジュールに解凍されます。
- コンテナルートシステムのスナップショットの準備ができると、マニフェストとイメージの構成を使用して、バンドルコントローラーが起動の構成を形成します（特に、スナップショットモジュールから取得したマウントのリストが準備されます）。
- 準備されたバンドルは、ランタイムサブシステムに渡されて実行されます。 彼女は、完成した構成を読み取り、作業コンテナーを作成します。
Dockerでの役割、他のコンポーネントとの通信
containerdの別のプロジェクトへの導入は約1年前に始まり 、Docker開発者が「 Docker Engineをよりコンパクトに、より良く、より速く、より強く 」しようと試み、その動作を次のように説明しました：スタック全体にruncを追加し、数百のコンテナを管理します。」
containerdがDocker（1.12）から分離された時点で、プロジェクト開発計画には、「Docker Engineコードベースをリファクタリングして、単一ホスト上のホスティングロジック、ネットワーク操作、ストレージのほとんどをDockerで使用できる再利用可能なコンポーネントに転送する」というものが含まれていました他のコンテナオーケストレーションプロジェクトとコンテナ配置サービスを使用します。」
containerdに課金された関数のセットは次のとおりです。
- Dockerレジストリに画像を配置します。
- コンテナ名のネットワーク空間を管理するためのシステムインターフェイスとAPIを作成するためのネットワークサポート。
- イメージおよびコンテナファイルシステムのストレージ（ホストレベル）。
- gRPC API（これは、Docker Engine自体がcontainerdと通信する場所です）;
- 内部およびコンテナレベルで使用されるPrometheusメトリック用の新しいAPI
- OCI（Open Container Initiative）イメージ仕様およびrunCリファレンス実装の完全サポート。
そのため、Dockerでは、Docker Engine内で将来のcontainerd 1.0（そのリリースは2017年6月に予定されています）の使用を見ています。
要約すると、著者は 、containedが「コンテナ指向のプラットフォームが必要とする」機能だけに焦点を合わせていると主張しています。 実際、これはかなり低レベルのソリューションであり、エンド開発者やユーザーではなく、Kubernetes（Kubelet内）やMesosなどの大規模システム、およびAmazon ECSやGoogle Container Engineなどのサービスと対話することが提案されています。 製品への埋め込みはすべて同じgRPC APIを介して提供されます（ctrユーティリティはデバッグと実験のみを目的としています）。
PS先週、Cloud Native Computing Foundationは、プロジェクト間でcontainerd の採用を正式に確認しました。 また、同じ日に、CoreOSの同様のコンテナー化された問題を解決するrktプロジェクトは、そのような運命をたどりました。これは、オープン仕様のコンテナーアプリ（appc）の実装であり、イメージにACI形式（アプリケーションコンテナーイメージ）を使用します。 CNCFは両方のプロジェクトの開発をサポートします。