ドッカー1.11: コンテナ化され、OCIテクノロジーに基づいて構築された最初のランタイム

Docker Engine 1.11 は、 Docker Engine 1.11 という最初のリリースです。 ランC ™ そして ™ コンテナ . このリリースでは、DockerはOCIテクノロジーに基づくランタイムを初めて出荷し、2015年6月にLinux Foundationの下で業界標準のコンテナ形式とランタイムを寄付して以来、チームが達成した進歩を示しています。

昨年、DockerはOCIの作業を進め、より多くのユーザーがより簡単に利用できるようにしました。 それは、runCを制御するデーモンであるcontainerd ™を導入した2015年12月に始まりました。 これは、Dockerを再利用可能な小さなコンポーネントに分割するための取り組みの一環でした。 このリリースでは、Docker Engineがコンテナ上に構築されるようになったため、Dockerを使用しているすべてのユーザーがOCIを使用するようになりました。 コンテナ・テクノロジーを標準化する作業を継続するために、40 +メンバーとともにOCIで進歩したことを誇りに思っています。

パーティーで友達を感動させると確信しているこの驚異的な技術的な雑学クイズに加えて、それはあなたにどのような違いをもたらしますか?まあ、簡単な答えは:何も...尚! それにもかかわらず、これはまだあなたが興奮すべきものであることをあなたに納得させてください。

これはエンジンが経験した最大の技術的リファクタリングの1つであり、1.11の優先事項は、コマンドラインインターフェイスやAPIを変更せずに、統合を正しく行うことでした。 ただし、これは、ユーザー向けの大幅な改善のための技術的な基礎を築きます。

ドッカーエンジン1 11ランク1

安定性とパフォーマンス

コンテナ化された統合により、Dockerコードベースの印象的なクリーンアップが行われ、多くの過去のバグが修正されます。 一般に、Dockerを焦点を絞った独立したツールに分割することは、より焦点を絞ったメンテナ、そして最終的にはより高品質のソフトウェアを意味します。

パフォーマンス面では、余分なプロセス間通信にもかかわらず、1.11が遅くならないように細心の注意を払っていました。 嬉しいことに、前モデルよりもコンテナの同時作成が高速であり、最初に正確性を優先するという意図的な選択をしましたが、将来的にはさらにパフォーマンスの向上が期待できます。

 

コンテナ実行バックエンドのエコシステムの作成

runC は、 Open Containers Runtime 仕様 の最初の実装であり、Docker Engine にバンドルされているデフォルトのエグゼキュータです。 オープン仕様のおかげで、Engineの将来のバージョンでは、さまざまなエグゼキューターを指定できるようになるため、Docker自体を変更することなく、代替実行バックエンドのエコシステムが可能になります。 この部分を分離することで、エコシステムパートナーは仕様に準拠した独自のエグゼキュータを構築し、エンジンのリリーススケジュールに依存したり、レビューされてコードベースにマージされるのを待ったりすることなく、いつでもユーザーコミュニティが利用できるようにすることができます。

これはあなたにとってどういう意味ですか? これにより、 ランタイムがプラグ可能になりました。 バッテリーは含まれているが交換可能であるというDockerの原則に従って、Docker Engineはデフォルトで利用可能なrunCとともに出荷され、特定のプラットフォーム用または異なるセキュリティおよびパフォーマンス機能を備えたさまざまなコンテナエグゼキューターから選択できます。 コンテナを実行するものをエンジンから分離することで、新しい可能性が開かれます。 たとえば、1.11は、コンテナを再起動せずにエンジンの再起動/アップグレードを可能にし、コンテナの可用性を向上させるための大きな一歩です。 これはおそらく、Dockerユーザーから最も要求された機能の1つです。 実際、この新しいアーキテクチャでは、containerdを再起動することもでき、コンテナは実行され続けます。


 

しかし、待ってください、もっとあります!

この大きなアーキテクチャの変更に加えて、いつものように、エンジン、作成、スウォーム、マシン、レジストリに多数の機能を追加しました。

 

エンジン 1.11

  • DNS ラウンド ロビン負荷分散: Docker のネットワークを使用してコンテナー間の負荷分散が可能になりました。 複数のコンテナーに同じエイリアスを指定すると、Docker のサービス検出によって、ラウンドロビン DNS のすべてのコンテナーのアドレスが返されます。
  • VLAN のサポート (実験的): 実験的なチャネルの Docker ネットワークに VLAN サポートが追加されたため、既存のネットワーク インフラストラクチャとの統合が向上します。
  • IPv6 サービス検出: エンジンの DNS ベースのサービス検出システムが AAAA レコードを返すことができるようになりました。
  • Yubikeyハードウェアイメージ署名: 数か月前、Dockerの実験的なチャネルにハードウェアYubikeysを使用してイメージに署名する機能を追加しました。 これは安定版リリースで利用可能になりました。 それがどのように機能するかについてもっと読む このブログ投稿.
  • ネットワークとボリュームのラベル: コンテナーとイメージの場合と同じ方法で、任意のキー/値データをネットワークとボリュームにアタッチできるようになりました。
  • デバイスマッパーストレージによる低ディスク容量の処理の改善: dm.min_free_space ディスク領域が不足したときにデバイスマッパーをより正常に失敗させるオプションが追加されました。
  • の一貫したステータスフィールド docker inspect: これは小さなことですが、Docker APIを使用する場合は非常に便利です。 docker inspect Status コンテナの状態を定義するための単一の一貫した値(running、、stoppedrestartingなど)を持つようになりました。詳細については、プルリクエストを参照してください。

詳細については、リリースノートを参照してください。

 

作曲1.7

  • --build docker-compose upオプション : これは、実行 docker-compose build の一般的なパターンの省略形であり、その後 docker-compose up. ビルドが遅い場合、Composeはデフォルトですべての実行でビルドされるわけではありませんが、クイックビルドがある場合は、これを毎回実行することで、環境が常に最新の状態になります。
  • docker-compose exec コマンド: コマンドを docker exec ミラーリングします。

詳細については、リリースノートを参照してください。

 

スウォーム1.2

  • コンテナーの再スケジュールは実験的ではなくなりました: 以前のバージョンの Swarm では、ノードが停止したときにコンテナーを再スケジュールするサポートが追加されました。 これは現在安定していると見なされているため、本番環境で安全に使用できます。

 
  • コンテナーをスケジュールできない場合のエラーの改善: たとえば、制約が失敗した場合、制約が出力されるため、何が悪かったかを簡単に確認できます。

詳細については、リリースノートを参照してください。

 

マシン0.7

このバージョンのマシンでは、Microsoft Azure ドライバーが新しい Azure API を使用するようになり、認証が容易になりました。 詳細については、Azure のブログ投稿を参照してください。 このリリースには他にもたくさんの改善があります - 詳細については完全なリリースノートを見てください

 

レジストリ2.4

  • ガベージコレクション: システム管理者がユーザーによって削除された画像からデータをクリーンアップできるツールが追加されました。 詳細については、 ガベージ コレクターのドキュメントを参照してください
  • より高速で安定した S3 ドライバー: S3 ストレージドライバーは、パフォーマンスと安定性に優れた公式の Amazon S3 SDK の上に実装されるようになりました。

詳細については、リリースノートを参照してください。

 

Docker 1.11をダウンロードしてお試しください

開発でこれらすべてを試す最も簡単な方法は、 Docker Toolboxをダウンロードすることです。 その他のプラットフォームについては、 インストール手順を確認してください。

これらはすべて、現在プライベートベータ版である開発中のDockerを使用する新しい方法であるMacおよびWindows用のDockerでも利用できます。 サインアップして、早めに試してみるチャンスを手に入れましょう。


 

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

フィードバック

「ドッカー0」に関する1.11の考え: コンテナ化され、OCIテクノロジーに基づいて構築された最初のランタイム」