DockerCon 2015 現地レポート（その2） #docker
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
2015年6月22日から23日まで実施されたDockerCon 2015 の現地レポートpart2です。
ーーー
Solomon Hykes：Founder & CTO
Solomon Hykes氏の登壇
これから2時間たっぷりDockerについて講演をする。
企業のミッション：「壮大なイノベーションをもたらすツールの開発」
湾岸戦争当時、イラクが保有している、と目されていた兵器：Weapons of Mass Destructionをもじったもの
インターネットがDockerの舞台
インターネットは様々なものの集合体によって構成されている、と解釈している。
コンピュータ、自動車、センサー、データバンク、家庭、時計、等、、、
Dockerのゴールは、上記のものによって構成されているインターネットの上でプログラムを開発するプラットホームを提供する事。
現在のインターネットの問題
プログラムが稼働するプラットホームがそれぞれ独立していて、アプリを開発しても、インターネット全体のうちのほんのわずかな部分でしか動かす事ができない。
Dockerの目指すゴール
Dockerの狙いは、この壁を取り除き、開発したアプリを真にインターネット全体で運用する事が出来るようにする事。
「インターネットを一つのプラットホームとしたソフトウエアレイヤー」
ゴールに到達するには？
この壮大なゴールに到達するためには、4つのゴールを設定した。
今回のDockerConは、このゴールを達成させるための発表を盛り込んでいる。
ゴール1：
開発者のツールボックスを根本的に改善する事。
分散アプリ開発
世の中は分散アプリの世界。しかし現存するツールは、分散アプリを開発するためにそもそも作られていない。
開発者主体の考え方
これでは、開発者の負担が無駄に大きいだけ。プログラマーにとって分散アプリを開発するにふさわしいツールの整備が必要である。
段階的な改革
とは言え、壮大な課題なので、順番に問題は解決していく事が重要だ、と考えている。
問題を一つ一つ紐解いていきたい。
問題その1：ランタイム環境
コンテナが稼働するランタイムをとにかく標準化する事。これは、Docker Engineで解決している。
問題その2：コンテナのパッケージングと配布手法
これはDocker Image FormatとDocker Registryの提供で対応している。
問題その3：サービス管理
マイクロアーキテクチャを実践した時に各コンポーネントを統合指定運用するニーズ
Docker Composeで複数コンテナの統合を実現可能としている。
問題その4：マシン管理
インフラは世に溢れているけど、分散アプリに十分対応できるものは無い。
Docker Machineを開発し、どんなマシンでもコンテナに対応できるようにした。
問題その5：クラスタリング
大量のマシンを持つインフラの上で、リソースのスケジューリング等管理が課題になってくる。
これは、Docker Swarmを通して解決している。
段階的改革の現状
以上の問題を、Dockerは過去の2年で解決していて、成果を上げている、と見ている。
今後もこういった、段階的なイノベーションを続けていく戦略。
今後の改革
これからのイノベーションは、Docker Experimental Releaseという名の下で継続していく。
今年の初めの買収
今年の初め、SocketPlaneという小さな会社を買収した
問題その6：ネットワーキング
分散されたコンテナをどのように接続していか、という課題。
プラットホームと同じように、ネットワークも「アプリの一部」になる必要がある。
Docker向けにネットワークスタックを根本的に変える必要がある。
＝＝＞ Docker Networkを発表
Docker Network 機能その1：マルチホストネットワーク機能を標準的にサポート
インストールしてすぐに、最低限の設定をすれば、すぐにネットワーク間でコンテナ上のアプリが接続する事ができる。
Docker Network 機能その2：仮想ネットワークの生成／管理が自由自在
DMZ、ファイアウォール、セキュリティポリシー、等の生成がコンテナ間で非常に簡単にできる。
下層のプラットホームに一切手を入れる必要が無い。
Docker Network 機能その3：標準的にDNSをサポート
異なるプラットホーム間でコンテナのサービスディスカバリができる。
サービスディスカバリの統合＝＞プラットホーム固有のサービスディカバリ機能に縛られない
Docker Networkはコミュニティにも指示
11社からDocker Networkを支援するサービスディスカバリバックエンド技術がすでに存在する。
Docker Networkのデモ
Pythonで開発したアプリをMongoDBのクラスターと接続したアプリケーションをコンテナ化し、Docker Composeの簡単なコマンドを通して、複数のコンテナに展開するデモを実施。
システム構成画面
プラットホームはDigital Oceanのクラウド
Docker Swarmを使い、複数のDocker Engine環境を構築：9個のノードを生成
HAProxyロードバランサを使ってクラスタを管理
各ノードはDocker Networkを使って接続
MongoDBサーバはまずは一つ
アプリサーバをスケールアップ
Docker Composeを使って、コマンド一つで1台のPythonアプリコンテナを50台にスケールアップ
システム構成画面に反映
さらにコンテナが増えていっている。
次は、MongoDBのサーバの増築
MongoDBサーバのスケールアップ
デモでは、9台のMongoDBサーバをスケールアップする予定。
DBAは得てしてネットワークは得意では無いので、Docker Swarmは非常に助かる。
（Alvin Richards氏は元MongoDBのトップエンジニア）
Docker Composeのスケールアップコマンド
不明がエラーが発生！
問題その7：拡張性
自分で開発したツールをどうやってDocker Toolboxに追加できるのか？
Docker Pluginsの提供：これにより、標準的なプラグインアーキテクチャと手法を提供
Dockerでは、4つの拡張方法をまずは提供開始する。
ネットワークプラグイン
ボリュームプラグイン
スケジューラプラグイン
サービスディスカバリプラグイン
Mesosphere社と協業がこのプラグインのコンセプトを確立している。
Mesosphere社と協業して、Mesosをスケジューラ／サービスディスカバリのプラグインとして開発済み
Docker Plugins 機能その1：
プラグインをつなげた時点でシステムのリスタートが必要ない。ダイナミックに導入可能
Docker Plugins 機能その2：マルチテナント機能
開発部門は安いプラグインを使いながら、プロダクションはセキュリティ性の高い高額なプラグインを使うことができる。アプリケーションに全く影響を及ぼさない。
Docker Plugins 機能その2：ロックイン無し
Docker上でアプリケーションをコンテナ化して運用できれば、どんなアプリでも任意のプラグインを使える、という保証
コンテナ上のアプリがプラグインの種類に左右されては絶対にいけない：Dockerの基本的なポリシーに反する
また、プラグインのバージョンアップに伴い、アプリが変更を強要される、という事もあってはいけない
＝＝＞実は一番開発に時間をかけている
Docker Pluginの開発には、下記の4つの会社からの甚大なサポートを受けている。
Weaveworks: コンテナ間のネットワークを統合的に管理するソフトウェア
ClusterHQ: コンテナ上のアプリが利用するストレージをコンテナ同様のポータビリティを提供するソフトウェア
GliderLabs: コンテナ運用上の自動化やデリバリーパイプライン等、PaaS的なサービスを提供
Mesosphere: Apache Mesosを製品化、運用管理ダッシュボードや様々なクラスタ管理機能をDCOSとして開発
エコシステムなくしてプラットホームは存在し得ない
Dockerは今や、ITアプリの開発／管理／運用プラットホームとしての立場を明確に
Dockerと単体で使う人はいない：エコシステムがあって初めてDockerの価値がみえてくる
AWS EC2 Container Service
そのエコシステムの代表として、AWS EC2 Container Serviceの紹介
AWS ECSのユーザは増えており、例として次の3社がいる。
Coursera: 自社の教育コースプラットホームのプログラムテストプラットホームとして採用
Hail-O: タクシー運用サービス：社内のマイクロサービスアーキテク社でECSを本格採用
Remind: 教育マーケット市場でのSaaS事業
AWS ECSの新規エンハンス機能
今回、新たにDocker ComposeをECSでサポートし、複数コンテナの統合運用を可能に
ゴール2：
より優れたPlumbing=運用ツールの提供
インフラ向けの運用ツール
簡単に運用ツールと言っても、かなり範囲は広い。
ネットワーク、ストレージはもちろん、セキュリティ、ログ管理、監視、等多岐にわたる。
また、いずれもかなり開発が必要なものが多い。
今日ももちろん運用ツールはいっぱいあるけど、どれも今日のインターネットアプリを想定した作りになっていない事が問題。
会場にもそれに合意する人が多く、拍手が起きる
Dockerの現状
Dockerも運用ツールをいっぱい使っている。
列挙しただけでもかなりの数になるし、その開発に関係したいエンジニアは数千人に上る
Docker独自開発も多い
Dockerが独自に開発したツールも多く、コミュニティに寄贈している。
実にDockerのソースコードの半分が運用周りのツールで占めている。
これらのツールを分離して、個別に使えるようにしたい、という要望も強い。
Docker Plumbing Projectの発表
その要望に応えるために、Docker Plumbing Projectを発足。
全ての運用ツールをオープンソース化して公開する事に決定。
これは、Docker自体をもっとモジュラーな構造にする事にも寄与している。
運用ツール1つ目：セキュリティ関係の運用ツール
セキュリティに関しては、プラットホーム間のコンテンツの受け渡しを確実に行うための技術
インターネット、という広いプラットホーム間ではまだ十分に解決されていない課題。
Docker Notaryの発表
これを実現するツールとして、Notaryを発表
Docker Toolboxの一つとして統合される
他のツール同様、プラットホームに依存しない、アーキテクチャを持つ
Docker Notaryのデモ
Notaryを通して、コンテナを登録し、Docker Registryにアップロードする一連の作業をデモで実施。
運用ツール1つ目：OSコンテナ
コンテナに直接関わるコードは全体の5％程度しか無い。
他は全てコンテナを運用するPlumbingコード ==> これを全て公開する事に決定
その最初の公開はrunC
OSコンテナ向けのランタイム環境
runC：ランタイム機能
コマンドラインツール
コンテナを動かすための必要最低限のコードだけを抽出してコンポーネント化
他のDockerプラットホームへの依存度は一切なし
Seccompフィルタ, User Name Spaces等、まだDocker Engineにもサポートされてない機能も搭載
Live Migration: 稼働しているrunCをそのまま別のプラットホームへ移動する事も可能
Microsoftの開発により、Windowsもサポートされている。
すでにプロダクション提供済み：https://runc.io
ゴール3：
オープンスタンダードへの取り組み
これは技術論ではなく、精神論である。
目的の異なる企業同士が共通の意識を持つ事がDockerの真の価値
コンテナの価値は、コンテナの中身や外に関する事ではなく、コンテナの形状に全員が合意した、という店にある。
Dockerも同じコンセプトを持っている。
runCがそれを具現化し、業界標準になった、と言える。
これを正式な標準にする事が次の論理的なステップ。
標準化のステップ：
1）正式な標準規格を制定する事
この対応として、OCF(Open Container Format)を規格化：runCそのもの
現在、最終的な規格化の作業を行っている最中
全てのOS/HWをサポート
2）独立したガバナンスの仕組みが必要
Open Container Projectの発足：標準化の実績をもつLinux Foundationとコラボ
Docker, Inc.と別の組織が企画を運用する事が重要
www.opencontainer.org
3）独立したレファレンス実装モデルが必要
runCのソースコードを全て、OCPに寄付
4）賛同し、協賛するベンダーの数が多くないといけない
初期メンバーとして参画した企業リスト。
今後、企業が増加する事を想定
5）新しいアイディアを募る仕組みを提供
APPCプロジェクトのメンバーがOCPに参画することになる
CoreOSとの和解
コンテナ仕様で行われていた「標準化戦争」に終止符を打つ必要があった。
会場で、CoreOSのCEO, Alex Polev氏とSolomon Hykes氏が握手を交わし、双方のコンテナ仕様に関する競争を
次の点で両者は合意：
オープン仕様を共に支援する事
その共通仕様の上で共通のPlumbingツールの開発をする事
Toolboxのアーキテクチャも共同で改善する事
- 分散アプリケーションを使った具体的なソリューション／製品を提供する事
