(cache) 参考訳：Docker 1.10 新しい Compose ファイル、セキュリティ改善、ネットワーク機能等

Docker社のblogで、新しい Docker 1.10 のリリースに関する投稿が掲載されました。内容を日本語でも把握できるよう、意訳も含めた参考訳を作成しました。内容は参考程度にどうぞ。

■ Docker 1.10: 新しい Compose ファイル、セキュリティ改善、ネットワーク機能等たくさん！

Docker 1.10 をお知らせします。皆さんが求めていたものが寿司詰めです。

複雑な分散アプリケーションも Docker Compose を使えば、より簡単に定義・実行できます。Compose は、コンテナをオーケストレーション（組織化）する能力があります。今回はネットワークとボリュームを設定できるようになりました。自分の開発マシン上で、複数のネットワーク層や複雑なストレージ設定をするアプリケーションがセットアップできます。セットアップした環境は、プロダクション（本番運用）にもセットアップして複製可能となるでしょう。あとは、開発環境と同じ設定を用いて、アプリケーションを CI 上で実行するのに使い、ステージング上や、プロダクション環境で適切に実行します。新しい Compose ファイルに関する情報は、こちらのブログ投稿をご覧ください（英語）。

例によって、今回のリリースでも多くのセキュリティに関する更新を行いました。皆さんが求めていた重要な機能が利用可能になります。機能とは、システム・ユーザとユーザの名前空間を分離(isolate)します。seccomp profile はシステム・コールをフィルタリングするので、それが、許可されたプラグイン・システムによる Docker Engine 機能に対するアクセス制限をもたらします。詳細に関する情報は、こちらのブログ投稿をご覧ください。

イメージ ID という、もう１つの大きなセキュリティ拡張があります。これはイメージの内容を表すものであり、Git のコミットがコミット内容を表すのと似た手法です。つまり、単純にイメージ ID を指定するだけで、実行しようとしている中身がどのようなものか、それを確実なものとして保証します。Docker Engine 1.10 にアップグレードする時は、移行プロセスのために多くの時間がかかる可能性があります。停止時間を減らすためには、こちらのドキュメント（英語）をご覧ください。

■ ネットワーク機能が更に良くなりました

Docker Engine の前バージョンから、新しいネットワーク・システムが追加されました。これにより、仮想ネットワークを作成し、コンテナに対して取り付け（attach）られるようになったので、アプリケーションに対してベストなネットワーク・トポロジを作成できました。さらに Docker Compose で扱えるようにするため、要望の多い複数の機能を追加しました。

* ネットワークでリンク機能を使用：従来通り、リンク機能はデフォルトの bridge ネットワークで動作します。しかし、自分でネットワークを作成すると、そこでリンク機能は使えませんでした。そこで特定のコンテナ内において、コンテナとホスト名のエイリアスを関連づける定義が可能になるよう、新しい機能をサポートしました（例：「–link db:production_postgres」）。
* ネットワーク全体のコンテナ・エイリアス：リンク機能は特定のコンテナに対して、エイリアス（別名）を定義できます。それだけでなく、複数のホストをまたがるネットワーク全体においても、その別名でコンテナにアクセスできます。
* 内部ネットワーク（internal network）：「network crate」に「–internal」フラグを付けると、ネットワーク内外のトラフィックを制限します。
* カスタム IP アドレス：コンテナの実行時やネットワークへの追加時、任意の IP アドレスをコンテナに割り当て可能です。
* 名前解決用の DNS サーバ：ホスト名の名前解決は、「/etc/hosts」よりも DNS サーバのほうが高い信頼性と拡張性（scalable）をもたらします。機能の提案とディスカッションをご覧ください。
* マルチホスト・ネットワーキングが、Docker Engine のカーネルがサポートしている全てのバージョンで利用可能に：マルチホスト・オーバレイ・ドライバは古いバージョンのカーネルでも動作します（3.10 以上）。

■ Engine 1.10

新しいセキュリティやネットワーク機能以外にも、Engine に対して沢山の機能を追加しました。

* 内容を示すことができるイメージ ID：イメージ ID はイメージ内に含まれる内容を表します。これは Git コミット時のハッシュ値がコミットの内容を示すのと同様な手法です。つまり、単純にイメージ ID を指定するだけで、実行しようとしている中身がどのようなものか、それを確実なものとして保証します。この機能は、Engine 1.6 で実装したイメージに対するダイジェスト値の機能を改良したものです。既存のイメージを移行するには多くの時間が必要となる場合があります。そのため、停止時間を短くしたい場合は、こちらのドキュメントをご覧ください。
* イベント・ストリームの改良：「docker events」コマンドと events API エンドポイントは改良・整理されました。イベントはリソース・タイプごとに一貫した構造を持ち、リソースに応じた処理を行います。そして、ボリュームとネットワークに関するアクションもイベントに追加します。詳細はドキュメントをご覧ください。
* push/pull 性能と信頼性の向上：レイヤ（訳者注；イメージ層）は並列に push できるようになり、従来の push よりも速くなりました（少なくとも3倍以上）。pull は少し速くなり、信頼性も向上しました。これはストリームライン・プロトコルと、リトライおよびフェイルバック機構の改良によるものです。
* コンテナに対するリソース制限のライブ・アップデート：コンテナが利用可能なリソース（例：メモリ使用量）の上限を設定するために、従来は設定を反映するのにコンテナの再起動が必用でした。新しい「docker update」コマンドを使うことで、リソース制限をオン・ザ・フライで（直ちに）更新できます。
* デーモン用の設定ファイル：デーモンのオプション設定をファイルでも行えるようになりました。また、反映のためにデーモンの再起動は不要になります。例えば、デーモン用のラベル設定や、デバッグ用のログ記録を有効にするなど、再起動を行わずとも可能です。
* 一時ファイルシステム（temporary filesystem）：一時ファイルシステムを使うのが非常に簡単になりました。「docker run」実行時に「–tmpfs」フラグを付けるだけです。これが特に役立つのは、読み込み専用のルート・ファイルシステムを使うコンテナを実行する時です。コンテナ内のソフトウェアが読み込み専用でも、一時的にこのディスク上に書き込むような使い方が期待できます。
* ディスク I/O 制限：ディスク I/O を制限するために、「docker run」実行時のオプションが複数追加されました。オプションは「–device-read-bps」「–device-write-bps」「–device-read-iops」「–device-write-iops」「–blkio-weight-device」です。
* Splunk ロギング・ドライバ：コンテナのログを Splink ロギング・サービスに対して送れます。
* デーモンの再起動時、適切な順番でリンクされたコンテナを起動：非常に小さなことですが、実行時に悩ましい問題がありました。リンクされたコンテナがあるデーモンを再起動時、リンク対象のコンテナが実行されておらず起動に失敗することが時々ありました。現在の Engine は適切な順番でコンテナを起動します。

変更内容の全貌はリリースノートをご覧ください。今回のリリースで複数の機能が廃止されました。また、Fedora 21 と Ubuntu 15.04 のサポートも終了しました。そのため、影響を受けるかどうかリリースノートをご確認ください。ボリューム・プラグインを作成している場合は、注意すべきボリューム・プラグイン API の変更点があります。

今回のリリースにかかわる全ての方、特に Qiang Huang、Denis Gladkikh、Dima Stopel、Liron Levin に大きな感謝を申しあげます。

開発環境で Docker を一番簡単に始める方法は、 Docker Toolbox のインストールです。他のプラットフォームでは、それぞれのインストール用のドキュメントをご確認ください。

■ Swarm 1.1

Docker Swarm は Docker 純正のクラスタリング・ツールです。これは Docker Engine のクラスタを、とても簡単に管理・デプロイするためのツールです。また、Swarm は Docker Universal Control Plane という、Docker アプリケーションとクラスタをデプロイ・管理するためのオンプレミス向けツールのクラスタリングとスケジューリングを行う基盤です。

初のプロダクション対応となった Swarm バージョン 1.0 を公開したのは、去年11月でした。今回のリリースでは多くの改良を施しており、特に皆さんから要望をいただいた以下の機能を追加しています。

* ノードの障害発生（fail）時、コンテナを自動で再スケジュール：ノードで障害が発生すると、Swarm はコンテナを実行し続けるため、正常なノード上にコンテナの再スケジュールを試みます（オプション）。現時点では実験的な機能であり、完全には機能していません。ですが、どうかお試しください！
* ノード管理の改善：Swarm とノードとの通信に障害が起こると、それで通信を諦めるのではなく、再試行します。また、「docker info」で状況とエラーメッセージを表示しますので、デバッグを簡単に行えます。機能提案の詳細は、こちらをご覧ください。

リリースノートの詳細はこちらをご確認ください。始め方はこちらのドキュメントをご覧ください。