[和訳]Docker 1.12: オーケストレーションがビルトインされました！#docker

本稿は DOCKER 1.12: NOW WITH BUILT-IN ORCHESTRATION!(2016/6/20) の和訳記事です。

 

Dockerは3年前、難解なLinux kernelテクノロジーを、コンテナ化により誰でも簡単にアクセス可能にしました。本日、コンテナオーケストレーションをリリースします。

コンテナオーケストレーションは、コンテナをホスト一つに個別に展開することから、複雑なマルチコンテナアプリを複数のマシン上で展開するために必要となるものです。コンテナオーケストレーションにはインフラから独立している分散プラットフォームが必要です。アプリケーションが終了するまでオンラインの状態を保つことができ、ハードウェアの欠陥やソフトウェアのアップデートにも耐えられるものである必要があります。本日リリースするオーケストレーションは、3年前のコンテナ化と同じ段階にあります。選択肢は次の2つです。複雑なアドホックシステムをまとめるため、テクノロジーエキスパート部隊に頼るか、あるいは、多くのエキスパートがいる会社に頼って、ハードウェアやサービス、サポート、ソフトウェアなどすべてをその会社から買う限り、すべての面倒を見てもらうか、です。このような選択をしなければならない状態を、ロックインと呼びます。

 

Dockerユーザは、どちらの選択肢も受け入れられないと言っています。ロックインされてしまうのではなく、誰もが使えるようなオーケストレーションのプラットフォームが必要なのでしょう。コンテナオーケストレーションはプラットフォームに構築されると、より簡単に実行できるようになる他、よりポータブルになり、セキュリティのよりしっかりした、回復力の高い、動作の速いものになります。

 

Docker 1.12の使用を開始するにあたって、Dockerエンジンの核にマルチホストとマルチコンテナのオーケストレーションをより簡単にするための機能をいくつか追加しました。また、ServiceやNodeのような新しいAPIオブジェクトを追加し、このDocker APIを使うことにより、swarmというDockerエンジンのグループ上でアプリを展開し、管理することができるようになります。Docker 1.12を使用してみれば、DockerのオーケストレーションにはDockerを使用するのが最も良いことが分かります。

 

 

Docker 1.12のデザインは4つの規則に基づいています：

 

・シンプルではあるがパワフル：オーケストレーションは、モダン分散アプリケーションの最も重要な部分です； Dockerエンジンの核にシームレスに構築してしまうほど重要です。オーケストレーションへのアプローチの仕方は、次の、コンテナに関する方針に従っています：セットアップ不要、少しのシンプルなコンセプトだけを知れば良い、「ただ単に動く」というユーザ体験、です。

・回復力が高い：マシンは欠陥を起こすものです。モダンシステムはこのような欠陥が定期的に起こることを想定し、ダウンタイムを引き起こすどのアプリケーションとも適合させないことが重要です。これが、欠陥ゼロデザインが必須な理由です。

・セキュリティ：セキュリティはデフォルトである必要があります。強力なセキュリティに対する障害となるもの―PKIの理解が必要な証明書など－は取り除くべきです。しかし、アドバンスユーザにおいては、証明書のサインと発行のすべてのコントロール・監査を可能にしておく事が重要です。

・オプション機能と下位互換性：ユーザが何百万といるので、バックワードでの互換性はDockerエンジンにとって必須です。すべての新機能はオプションですので、使用しないのであれば、メモリやcpuなどの負荷は必要はありません。Dockerエンジンのオーケストレーションは、私たちのプラットフォームの交換可能なバッテリーという手法と協調しているため、、ユーザはDockerエンジンに構築した第三者のオーケストレーターを使用し続けることができます。

 

 

新機能がDocker 1.12でどのように機能するか見てみましょう。

一つの非集中ビルディングブロックを使ってSwarmを作成するには

すべてはswarm ―自己回復できるエンジンのグループ― を作成するところから始まります。そのブートストラップノードは

docker swarm init

ぐらいシンプルです。

これは裏で、一つのノードにRaftコンセンサスグループを作成します。この第一ノードにはマネージャの役割があり、コマンドとスケジュールタスクを受け入れます。Swarmにノードを追加していくにつれ、それらのノードはデフォルトで、マネージャに割り当てられたコンテナを実行するように動作します。オプションでマネージャノードをさらに追加することもできます。それらはRaftコンセンサスグループの一部となります。最適なRaftストアを使用し、そこからメモリを直接読み取ります。このメモリがスケジュール管理のパフォーマンスを速くします。

 

サービスを作成し、スケーリングするには

一つのコンテナをdocker実行で実行するように、dockerサービスを利用して、複製化、分散化、ロードバランスされたプロセスを、エンジンのswarmで始めることができます。

docker service create –name frontend –replicas 5 -p 80:80/tcp nginx:latest

このコマンドのおかげで5つのnginxコンテナのswarmが一つのものとして到達可能となり、swarmのすべてのノードのポート80で、内部でロードバランスされたサービスとなり、理想的な状態が確実となります。我々は内部でこれを、Linux IPVS、Linux kernelに15年以上入り続けているin-kernel Layer 4マルチプロトコルロードバランサーを使って機能させます。Kernelの内部でIPVSルーティングパケットを使うことにより、swarmのルーティングmeshのコンテナを意識したロードバランス機能の素晴らしいパフォーマンスを実現します。

 

サービスを作成する際、オプションで複製かグローバルサービスかを選べます。複製サービスとは、設定した数のコンテナが、利用可能なホストに分散されるということです。グローバルサービスはそれとは対照的に、swarmのどのホストでもコンテナが同じ数になるように一つのインスタンスを設定します。

Dockerがどのように高い回復力を提供しているかに話を移しましょう。Swarmモード認証エンジンには自己回復能力があります。つまり、あなたが設定したアプリケーションを認識し、チェックを続け、何か環境に間違いが起こると、環境の再調整を行います。例えば、nginxインスタンスを実行しているマシンのプラグを抜いたら、別のノードに新しいコンテナが出現します。Swarmのマシンのうち半分の、ネットワークスイッチのプラグを抜いてみてください。もう半分がそれら自身の間でコンテナを再分散し、引き継ぎを行います。アップデートに関しては一度変更を行えば、サービスの再展開には柔軟に対応できるでしょう。Swarmのコンテナのアップデートは、rollingかparallelか設定できます。

100インスタンスにスケールアップしたいですか？とてもシンプルに、

docker service scale frontend=100

とするだけでできます。

 

典型的な2層のアプリケーション(web+db)は、次のように作成できます：


docker network create -d overlay mynet
docker service create –name frontend –replicas 5 -p 80:80/tcp \
–network mynet mywebapp
docker service create –name redis –network mynet redis:latest

次の画像が、このアプリケーションの基本構造を示しています。

セキュリティ

Docker 1.12の核となる原理は、Dockerプラットフォームに、環境設定ゼロ、デフォルトのセキュリティ、既成の体験を提供することです。管理者がアプリケーションを商用環境で展開する際しばしば、それらを安全に実行することが一つのハードルとなります。Docker 1.12により管理者は、安全な商用クラスターの設定を行う際、demoクラスターの設定の時とまったく同じステップを実行するだけです。

セキュリティは、後から付け加えられるものではありません。それゆえ、Docker 1.12には相互認証TLSが必要なのです。これは、swarmに参加しているすべてのノードのコミュニケーションに、認証、認可、暗号化を行います。

初めてManagerを開始する場合、Dockerエンジンは新しい認証局（CA）と初期認証セットを作成します。この初めのステップが終わると、swarmに入っているすべてのノードに、ランダムなIDとその時点でのswarmにおける役割（マネージャかWorker）の付いた認証が自動的に発行されます。

これらの認証はswarmに参加している限りずっと、暗号でセキュリティのかかっているノードアイデンティティとして使用され、また、マネージャはこれらを、タスクやそのほかのアップデートの安全な普及を確実にするために使用します。

TLSを採用する際最も障害となることの一つとして常にあるのが、必要なパブリックキーインフラ（PKI）の作成・環境設定・維持の難しさです。Docker 1.12を使用すると、すべての設定や安全なデフォルトでの環境設定が済んでしまうだけでなく、TLS認証における最も苦痛な作業の一つである認証ローテーションも自動で実行されます。

Swarmに参加しているすべてのノードは、裏で常に認証を更新しています。リークの恐れがあったり、抵抗力の無くなった可能性のある証明書はもはや無効となります。更新の頻度は、ユーザが最低30分毎から設定できます。

自分だけの認証局を使用したい場合、外部CAモードもサポートしています。使い方は、swarmのマネージャが、クラスターに参加させたいノードの認証サインリクエストをリモートURLに対して実行するだけです。

 

バンドル

Docker 1.12は、分散アプリケーションバンドルという新しいファイルフォーマットを導入します（実験構築のみサポート）。バンドルとは、フルスタックアプリケーションに焦点を当てた、トップサービスの新しい抽象概念です。

Dockerバンドルファイルは、次のものを規定する宣言型の仕様です：

・実行する特定のイメージのリビジョン

・作成するネットワーク

・それらのサービスのコンテナを実行するためのネットワーク接続法

 

バンドルファイルは完全にポータブルで、ソフトウェア運用パイプラインで完璧に展開できます。スペックを完璧に備えた、完全版のマルチコンテナDockerアプリケーションをリリースするためです。

バンドルファイルスペックはシンプルでオープンです。好きなようにバンドルを作成できます。始めるに際して、Docker Composeはバンドルファイル作成を実験的にサポートしています。Docker 1.12や有効なswarmモードを使ってバンドルファイルを展開できます。

バンドルはCIを通して開発者のノートpcから商用環境へマルチサービスアプリを移動させるのに有効なメカニズムです。まだ実験段階ですので、コミュニティーからのフィードバックをお待ちしています。

 

Docker 1.12の裏側で

裏側を見てみると、Dockerは他にも数多く興味深い技術を使用しています。gRPCを使用して行うインターノードコミュニケーションによって多重通信とヘッダー圧縮のコネクションなどの HTTP/2の利点を利用できます。私たちのデータ構造はprotobufs(プロトコルバッファー)のおかげで効率よく伝えられます。

以下のDocker1.12上の追加リソースをチェックしてください

 

• 　　MacまたはWindows用のDocker1.12をダウンロード
• 　　お好みのクラウドをネイティブに試してみる：　AWS またはAzure
• 　　チュートリアルをチェックする：　docs.docker.com/engine/swarm/swarm-tutorial/
• 　　swarmsについてもっと詳しく知る：　docs.docker.com/engine/swarm/swarm-tutorial/
• 　　バンドルを試してみる：　github.com/docker/docker/blob/master/experimental/docker-stacks-and-bundles.md

 

Dockerに関してさらに学ぶには

・Docker初心者は、10分のオンラインチュートリアルをご覧ください。
・画像、自動構築などを無料のDocker Hubアカウントでシェアしてみましょう。
・Docker 1.12リリースノートを読んでみましょう。
・Docker Weeklyを購読してみましょう。
・次に予定されているDockerオンラインMeetupに登録してみましょう。
・次に予定されているDocker Meetupに参加してみましょう。
・DockerCon 2016に登録してみましょう。
・DockerCon EU 2015のビデオを見てみましょう。
・Dockerコミュニティへの貢献を始めましょう。