Docker Engine をより小さく、より良く、より速く、より強力にするために、私たちは現在のエンジンのコンポーネントを探し、別々のプロジェクトに分割し、その過程で改善することができました。 これらのコンポーネントの 1 つは、コンテナーを管理するための Docker ランタイムです。 runcのようなスタンドアロンランタイムでは、runcをスタックに追加し、何百ものコンテナを管理するためのクリーンな統合ポイントが必要です。
そこで、コンテナ監視をコアDockerエンジンから別のデーモンに移動するために 、containerd プロジェクトを開始しました。 containerdは、OCIバンドルの開始とそのライフサイクルの管理を完全にサポートしています。 これにより、ユーザーはシステム上のruncバイナリを別のランタイムに置き換えて、DockerのAPIを引き続き使用する利点を得ることができます。
では、なぜ別のプロジェクトなのか? 実際の問題を修正するのではなく、リファクタリングに忙しいのはなぜですか? まぁ。。。
containerd は並列コンテナの起動時間を改善するため、複数のコンテナをできるだけ早く起動する必要がある場合は、このリリースで改善が見られるはずです。 私のラップトップでは、1.64秒で100個のコンテナを起動できます。 これは毎秒60コンテナです。 コンテナを起動するとき、ほとんどの時間はシステムコールとシステムレベルの操作に費やされます。 起動時間の大部分は、操作を完了するためにハードウェア/カーネルを待つために主に費やされるため、100個のコンテナすべてを同時に起動することは意味がありません。 containerd はイベントを使用して、コンテナーの開始要求やその他のさまざまな操作をロックフリーでスケジュールします。 同時に開始するコンテナーの数には構成可能な制限があり、既定では 10 ワーカーに設定されています。 これにより、必要な数のAPIリクエストを行うことができ、containerdはシステムを完全に圧倒することなく、コンテナをできるだけ速く起動します。
コンテナのAPIはとてもシンプルです。 パフォーマンスとクライアント ライブラリを簡単に作成できるようにするために、gRPC を使用してビルドすることにしました。 APIを介してコンテナを起動するための基本的なリクエストは、OCIバンドルへのパスとコンテナのIDのみを指定することです。 API をシンプルに保つことで、新しい機能が追加されたときの API の変更を最小限に抑えます。
また、コンテナ化された状態も最小限に抑えられています。 コンテナーが終了すると、Docker は生成されたバンドルを削除し、ランタイム状態は失われます。 これにより、ディスク上のコンテナーのランタイム状態を分離して、コンテナーが実行されている間のみ存続させることができます。
ライブ マイグレーションや実行中のコンテナーに再アタッチする機能など、より多くの機能が表示されるようになり、この統合の結果として Docker の将来のリリースでコンテナーに影響を与えずに Docker をアップグレードできるようになります。
最新の Docker エンジン 1.11 リリースでコンテナーを試してみてください。 ラップトップにインストールするには、 Dockerツールボックスをダウンロードしてください。 その他のプラットフォームについては、 インストール手順を確認してください。
ドッカーについてもっと知る
- ドッカーは初めてですか? 10分間の オンラインチュートリアルをお試しください
- 無料の Docker Hub アカウントでイメージを共有し、ビルドを自動化します
- Docker 1.11 リリースノートを読む
- ドッカーウィークリーを購読する
- 今後の Dockerオンラインミートアップにサインアップする
- 今後の Docker ミートアップに参加する
- DockerCon EU 2015 のビデオを見る
- Docker への貢献を開始する
フィードバック
「Dockerコンテナ統合」に関する0つの考え