fbpx

DockerCon 2015 現地レポート(その2) #docker

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

2015年6月22日から23日まで実施されたDockerCon 2015 の現地レポートpart2です。

DockerCon 2015 現地レポート(その1)

ーーー

Solomon Hykes:Founder & CTO

Dockercon2015015

Solomon Hykes氏の登壇
これから2時間たっぷりDockerについて講演をする。

Dockercon2015016

企業のミッション:「壮大なイノベーションをもたらすツールの開発」
湾岸戦争当時、イラクが保有している、と目されていた兵器:Weapons of Mass Destructionをもじったもの

Dockercon2015017

インターネットがDockerの舞台
インターネットは様々なものの集合体によって構成されている、と解釈している。
コンピュータ、自動車、センサー、データバンク、家庭、時計、等、、、
Dockerのゴールは、上記のものによって構成されているインターネットの上でプログラムを開発するプラットホームを提供する事。

Dockercon2015018

現在のインターネットの問題
プログラムが稼働するプラットホームがそれぞれ独立していて、アプリを開発しても、インターネット全体のうちのほんのわずかな部分でしか動かす事ができない。

Dockercon2015019

Dockerの目指すゴール
Dockerの狙いは、この壁を取り除き、開発したアプリを真にインターネット全体で運用する事が出来るようにする事。
「インターネットを一つのプラットホームとしたソフトウエアレイヤー」

Dockercon2015020

ゴールに到達するには?
この壮大なゴールに到達するためには、4つのゴールを設定した。
今回のDockerConは、このゴールを達成させるための発表を盛り込んでいる。

Dockercon2015021

ゴール1:
開発者のツールボックスを根本的に改善する事。

Dockercon2015022

分散アプリ開発
世の中は分散アプリの世界。しかし現存するツールは、分散アプリを開発するためにそもそも作られていない。

Dockercon2015023

開発者主体の考え方
これでは、開発者の負担が無駄に大きいだけ。プログラマーにとって分散アプリを開発するにふさわしいツールの整備が必要である。

Dockercon2015024

段階的な改革
とは言え、壮大な課題なので、順番に問題は解決していく事が重要だ、と考えている。
問題を一つ一つ紐解いていきたい。

Dockercon2015025

問題その1:ランタイム環境
コンテナが稼働するランタイムをとにかく標準化する事。これは、Docker Engineで解決している。

Dockercon2015026

問題その2:コンテナのパッケージングと配布手法
これはDocker Image FormatとDocker Registryの提供で対応している。

Dockercon2015027

問題その3:サービス管理
マイクロアーキテクチャを実践した時に各コンポーネントを統合指定運用するニーズ
Docker Composeで複数コンテナの統合を実現可能としている。

Dockercon2015028
問題その4:マシン管理
インフラは世に溢れているけど、分散アプリに十分対応できるものは無い。
Docker Machineを開発し、どんなマシンでもコンテナに対応できるようにした。

Dockercon2015029

問題その5:クラスタリング
大量のマシンを持つインフラの上で、リソースのスケジューリング等管理が課題になってくる。
これは、Docker Swarmを通して解決している。

Dockercon2015030

段階的改革の現状
以上の問題を、Dockerは過去の2年で解決していて、成果を上げている、と見ている。
今後もこういった、段階的なイノベーションを続けていく戦略。

Dockercon2015031
今後の改革
これからのイノベーションは、Docker Experimental Releaseという名の下で継続していく。

Dockercon2015032

今年の初めの買収
今年の初め、SocketPlaneという小さな会社を買収した

Dockercon2015033

問題その6:ネットワーキング
分散されたコンテナをどのように接続していか、という課題。
プラットホームと同じように、ネットワークも「アプリの一部」になる必要がある。
Docker向けにネットワークスタックを根本的に変える必要がある。
==> Docker Networkを発表

Dockercon2015034

Docker Network 機能その1:マルチホストネットワーク機能を標準的にサポート
インストールしてすぐに、最低限の設定をすれば、すぐにネットワーク間でコンテナ上のアプリが接続する事ができる。

Dockercon2015035

Docker Network 機能その2:仮想ネットワークの生成/管理が自由自在
DMZ、ファイアウォール、セキュリティポリシー、等の生成がコンテナ間で非常に簡単にできる。
下層のプラットホームに一切手を入れる必要が無い。

Dockercon2015036

Docker Network 機能その3:標準的にDNSをサポート
異なるプラットホーム間でコンテナのサービスディスカバリができる。
サービスディスカバリの統合=>プラットホーム固有のサービスディカバリ機能に縛られない

Dockercon2015037
Docker Networkはコミュニティにも指示
11社からDocker Networkを支援するサービスディスカバリバックエンド技術がすでに存在する。

Dockercon2015038

Docker Networkのデモ
Pythonで開発したアプリをMongoDBのクラスターと接続したアプリケーションをコンテナ化し、Docker Composeの簡単なコマンドを通して、複数のコンテナに展開するデモを実施。

Dockercon2015039
システム構成画面
プラットホームはDigital Oceanのクラウド
Docker Swarmを使い、複数のDocker Engine環境を構築:9個のノードを生成
HAProxyロードバランサを使ってクラスタを管理
各ノードはDocker Networkを使って接続
MongoDBサーバはまずは一つ

Dockercon2015040

アプリサーバをスケールアップ
Docker Composeを使って、コマンド一つで1台のPythonアプリコンテナを50台にスケールアップ

Dockercon2015041

システム構成画面に反映
さらにコンテナが増えていっている。
次は、MongoDBのサーバの増築

Dockercon2015042

MongoDBサーバのスケールアップ
デモでは、9台のMongoDBサーバをスケールアップする予定。
DBAは得てしてネットワークは得意では無いので、Docker Swarmは非常に助かる。
(Alvin Richards氏は元MongoDBのトップエンジニア)

Dockercon2015043

Docker Composeのスケールアップコマンド
不明がエラーが発生!

Dockercon2015044

問題その7:拡張性
自分で開発したツールをどうやってDocker Toolboxに追加できるのか?
Docker Pluginsの提供:これにより、標準的なプラグインアーキテクチャと手法を提供

Dockercon2015045

Dockerでは、4つの拡張方法をまずは提供開始する。
ネットワークプラグイン
ボリュームプラグイン
スケジューラプラグイン
サービスディスカバリプラグイン
Mesosphere社と協業がこのプラグインのコンセプトを確立している。
Mesosphere社と協業して、Mesosをスケジューラ/サービスディスカバリのプラグインとして開発済み

Dockercon2015046

Docker Plugins 機能その1:
プラグインをつなげた時点でシステムのリスタートが必要ない。ダイナミックに導入可能

Dockercon2015047

Docker Plugins 機能その2:マルチテナント機能
開発部門は安いプラグインを使いながら、プロダクションはセキュリティ性の高い高額なプラグインを使うことができる。アプリケーションに全く影響を及ぼさない。

Dockercon2015048

Docker Plugins 機能その2:ロックイン無し
Docker上でアプリケーションをコンテナ化して運用できれば、どんなアプリでも任意のプラグインを使える、という保証
コンテナ上のアプリがプラグインの種類に左右されては絶対にいけない:Dockerの基本的なポリシーに反する
また、プラグインのバージョンアップに伴い、アプリが変更を強要される、という事もあってはいけない
==>実は一番開発に時間をかけている

Dockercon2015049

Docker Pluginの開発には、下記の4つの会社からの甚大なサポートを受けている。
Weaveworks: コンテナ間のネットワークを統合的に管理するソフトウェア
ClusterHQ: コンテナ上のアプリが利用するストレージをコンテナ同様のポータビリティを提供するソフトウェア
GliderLabs: コンテナ運用上の自動化やデリバリーパイプライン等、PaaS的なサービスを提供
Mesosphere: Apache Mesosを製品化、運用管理ダッシュボードや様々なクラスタ管理機能をDCOSとして開発

Dockercon2015050

エコシステムなくしてプラットホームは存在し得ない
Dockerは今や、ITアプリの開発/管理/運用プラットホームとしての立場を明確に
Dockerと単体で使う人はいない:エコシステムがあって初めてDockerの価値がみえてくる

Dockercon2015051

AWS EC2 Container Service
そのエコシステムの代表として、AWS EC2 Container Serviceの紹介

Dockercon2015052

AWS ECSのユーザは増えており、例として次の3社がいる。
Coursera: 自社の教育コースプラットホームのプログラムテストプラットホームとして採用
Hail-O: タクシー運用サービス:社内のマイクロサービスアーキテク社でECSを本格採用
Remind: 教育マーケット市場でのSaaS事業

Dockercon2015053

AWS ECSの新規エンハンス機能
今回、新たにDocker ComposeをECSでサポートし、複数コンテナの統合運用を可能に

Dockercon2015054

ゴール2:
より優れたPlumbing=運用ツールの提供

Dockercon2015055

インフラ向けの運用ツール
簡単に運用ツールと言っても、かなり範囲は広い。
ネットワーク、ストレージはもちろん、セキュリティ、ログ管理、監視、等多岐にわたる。
また、いずれもかなり開発が必要なものが多い。
今日ももちろん運用ツールはいっぱいあるけど、どれも今日のインターネットアプリを想定した作りになっていない事が問題。
会場にもそれに合意する人が多く、拍手が起きる

Dockercon2015056

Dockerの現状
Dockerも運用ツールをいっぱい使っている。
列挙しただけでもかなりの数になるし、その開発に関係したいエンジニアは数千人に上る

Dockercon2015057

Docker独自開発も多い
Dockerが独自に開発したツールも多く、コミュニティに寄贈している。
実にDockerのソースコードの半分が運用周りのツールで占めている。
これらのツールを分離して、個別に使えるようにしたい、という要望も強い。

Dockercon2015058
Docker Plumbing Projectの発表
その要望に応えるために、Docker Plumbing Projectを発足。
全ての運用ツールをオープンソース化して公開する事に決定。
これは、Docker自体をもっとモジュラーな構造にする事にも寄与している。

Dockercon2015059

運用ツール1つ目:セキュリティ関係の運用ツール
セキュリティに関しては、プラットホーム間のコンテンツの受け渡しを確実に行うための技術
インターネット、という広いプラットホーム間ではまだ十分に解決されていない課題。

Dockercon2015060

Docker Notaryの発表
これを実現するツールとして、Notaryを発表
Docker Toolboxの一つとして統合される
他のツール同様、プラットホームに依存しない、アーキテクチャを持つ

Dockercon2015061

Docker Notaryのデモ
Notaryを通して、コンテナを登録し、Docker Registryにアップロードする一連の作業をデモで実施。

Dockercon2015062

運用ツール1つ目:OSコンテナ
コンテナに直接関わるコードは全体の5%程度しか無い。
他は全てコンテナを運用するPlumbingコード ==> これを全て公開する事に決定

Dockercon2015064

その最初の公開はrunC
OSコンテナ向けのランタイム環境

Dockercon2015065

runC:ランタイム機能
コマンドラインツール
コンテナを動かすための必要最低限のコードだけを抽出してコンポーネント化
他のDockerプラットホームへの依存度は一切なし
Seccompフィルタ, User Name Spaces等、まだDocker Engineにもサポートされてない機能も搭載
Live Migration: 稼働しているrunCをそのまま別のプラットホームへ移動する事も可能
Microsoftの開発により、Windowsもサポートされている。
すでにプロダクション提供済み:https://runc.io

Dockercon2015066

ゴール3:
オープンスタンダードへの取り組み
これは技術論ではなく、精神論である。
目的の異なる企業同士が共通の意識を持つ事がDockerの真の価値
コンテナの価値は、コンテナの中身や外に関する事ではなく、コンテナの形状に全員が合意した、という店にある。
Dockerも同じコンセプトを持っている。
runCがそれを具現化し、業界標準になった、と言える。
これを正式な標準にする事が次の論理的なステップ。

Dockercon20150067

標準化のステップ:
1)正式な標準規格を制定する事
この対応として、OCF(Open Container Format)を規格化:runCそのもの
現在、最終的な規格化の作業を行っている最中
全てのOS/HWをサポートDockercon2015068

2)独立したガバナンスの仕組みが必要
Open Container Projectの発足:標準化の実績をもつLinux Foundationとコラボ
Docker, Inc.と別の組織が企画を運用する事が重要
www.opencontainer.org

Dockercon2015069

3)独立したレファレンス実装モデルが必要
runCのソースコードを全て、OCPに寄付

Dockercon2015070

4)賛同し、協賛するベンダーの数が多くないといけない
初期メンバーとして参画した企業リスト。
今後、企業が増加する事を想定

Dockercon2015071

5)新しいアイディアを募る仕組みを提供
APPCプロジェクトのメンバーがOCPに参画することになる

Dockercon2015072

CoreOSとの和解
コンテナ仕様で行われていた「標準化戦争」に終止符を打つ必要があった。
会場で、CoreOSのCEO, Alex Polev氏とSolomon Hykes氏が握手を交わし、双方のコンテナ仕様に関する競争を
次の点で両者は合意:
オープン仕様を共に支援する事
その共通仕様の上で共通のPlumbingツールの開発をする事
Toolboxのアーキテクチャも共同で改善する事
- 分散アプリケーションを使った具体的なソリューション/製品を提供する事

Dockercon2015073

新規CTA