Docker containerd integration

Docker Engine をより小さく、より良く、より速く、より強力にするために、私たちは現在のエンジンのコンポーネントを探し、別々のプロジェクトに分割し、その過程で改善することができました。 これらのコンポーネントの 1 つは、コンテナーを管理するための Docker ランタイムです。 runcのようなスタンドアロンランタイムでは、runcをスタックに追加し、何百ものコンテナを管理するためのクリーンな統合ポイントが必要です。

そこで、コンテナ監視をコアDockerエンジンから別のデーモンに移動するために 、containerd プロジェクトを開始しました。 containerdは、OCIバンドルの開始とそのライフサイクルの管理を完全にサポートしています。 これにより、ユーザーはシステム上のruncバイナリを別のランタイムに置き換えて、DockerのAPIを引き続き使用する利点を得ることができます。

では、なぜ別のプロジェクトなのか? 実際の問題を修正するのではなく、リファクタリングに忙しいのはなぜですか? まぁ。。。

containerd は並列コンテナの起動時間を改善するため、複数のコンテナをできるだけ早く起動する必要がある場合は、このリリースで改善が見られるはずです。 私のラップトップでは、1.64秒で100個のコンテナを起動できます。 これは毎秒60コンテナです。 コンテナを起動するとき、ほとんどの時間はシステムコールとシステムレベルの操作に費やされます。 起動時間の大部分は、操作を完了するためにハードウェア/カーネルを待つために主に費やされるため、100個のコンテナすべてを同時に起動することは意味がありません。 containerd はイベントを使用して、コンテナーの開始要求やその他のさまざまな操作をロックフリーでスケジュールします。 同時に開始するコンテナーの数には構成可能な制限があり、既定では 10 ワーカーに設定されています。 これにより、必要な数のAPIリクエストを行うことができ、containerdはシステムを完全に圧倒することなく、コンテナをできるだけ速く起動します。

コンテナ
containerd統合ではruncも組み込まれるため、OCIランタイム仕様をサポートするために、コンテナを起動するためのモデルが少し変更されました。 Docker Engineにリクエストを行うと、すべてのイメージ管理が通常どおり実行されますが、その後はまずコンテナのOCIバンドルを生成します。 これには、プルしたイメージからの情報と、API を介して指定したランタイム情報が含まれます。 構成が生成されると、Docker はコンテナーのルート ファイルシステムをバンドル内にマウントしてから、コンテナーを呼び出してコンテナーを起動します。

コンテナのAPIはとてもシンプルです。 パフォーマンスとクライアント ライブラリを簡単に作成できるようにするために、gRPC を使用してビルドすることにしました。 APIを介してコンテナを起動するための基本的なリクエストは、OCIバンドルへのパスとコンテナのIDのみを指定することです。 API をシンプルに保つことで、新しい機能が追加されたときの API の変更を最小限に抑えます。

また、コンテナ化された状態も最小限に抑えられています。 コンテナーが終了すると、Docker は生成されたバンドルを削除し、ランタイム状態は失われます。 これにより、ディスク上のコンテナーのランタイム状態を分離して、コンテナーが実行されている間のみ存続させることができます。

ライブ マイグレーションや実行中のコンテナーに再アタッチする機能など、より多くの機能が表示されるようになり、この統合の結果として Docker の将来のリリースでコンテナーに影響を与えずに Docker をアップグレードできるようになります。

最新の Docker エンジン 1.11 リリースでコンテナーを試してみてください。 ラップトップにインストールするには、 Dockerツールボックスをダウンロードしてください。 その他のプラットフォームについては、 インストール手順を確認してください。


ドッカーについてもっと知る