View
4.640
Download
4
Category
Preview:
Citation preview
ひしめき合う Open PaaSを徹底解剖! PaaSの今と未来
Kazuto Kusama@jacopen
Cloud Foundryベースの
PaaS開発・運用
しごと
世界を緑色にする仕事
しごと
世界を緑色にする仕事
しごと
個人活動• PaaS勉強会主宰
• 日本Cloud Foundryグループ理事
今日の話
Open PaaS
プロプライエタリPaaS
Open PaaS
Open PaaS
今回伝えたいこと• 是非、Open PaaSに興味をもって欲しい
• 今あるOpen PaaSの紹介
• どうOpen PaaSと付き合っていくべきか
• Open PaaSの未来はどうなるか
Open PaaSを触ってみよう
Cloud Foundry
Cloud Foundry Foundationが開発(Pivotal, IBM, HP, Intel, NTTなどが参加)
2011年にVMwareがOSSとして公開。その後Pivotal Software⇒Cloud Foundry Foundationに移管。
Cloud Foundryを採用したサービス
Public PaaS Private PaaS
Pivotal (Pivotal Web Services) IBM (Bluemix)
NTT Communications (Cloudn PaaS) Fujitsu (K5)
Pivotal (Pivotal CF) HP (Helion Development Platform)
Active State (Stackato)
DEMO
$ ls index.php info.php $cf push jft-‐php Creating app jft-‐php in org cln100021251 / space production as xxxxx... OK
Creating route jft-‐php.paas.jp-‐e1.cloudn-‐service.com... OK
Binding jft-‐php.paas.jp-‐e1.cloudn-‐service.com to jft-‐php... OK
Uploading jft-‐php... Uploading app files from: /Users/jacopen/Project/jacopen/jtf/php Uploading 1.7K, 2 files Done uploading OK (中略) state since cpu memory disk details #0 running 2015-‐07-‐26 02:07:26 PM 0.0% 14.5M of 256M 34.1M of 2G
※デモで話した内容
シンプルなPHPアプリをCloudn PaaSにデプロイ
$ ls index.php info.php $cf push jft-‐php Creating app jft-‐php in org cln100021251 / space production as xxxxx... OK
Creating route jft-‐php.paas.jp-‐e1.cloudn-‐service.com... OK
Binding jft-‐php.paas.jp-‐e1.cloudn-‐service.com to jft-‐php... OK
Uploading jft-‐php... Uploading app files from: /Users/jacopen/Project/jacopen/jtf/php Uploading 1.7K, 2 files Done uploading OK (中略) state since cpu memory disk details #0 running 2015-‐07-‐26 02:07:26 PM 0.0% 14.5M of 256M 34.1M of 2G
※デモで話した内容
動きました。かんたん。
$ cf api https://api.ng.bluemix.net Setting api endpoint to https://api.ng.bluemix.net... OK
API endpoint: https://api.ng.bluemix.net (API version: 2.27.0) Not logged in. Use 'cf login' to log in. $ cf login API endpoint: https://api.ng.bluemix.net
(中略)
$ cf push jtf-‐php Creating app jtf-‐php in org erm / space production as xxxxx... OK
※デモで話した内容
全く同じコマンドで、向き先をBluemixに切り替えてデプロイ
$ cf api https://api.ng.bluemix.net Setting api endpoint to https://api.ng.bluemix.net... OK
API endpoint: https://api.ng.bluemix.net (API version: 2.27.0) Not logged in. Use 'cf login' to log in. $ cf login API endpoint: https://api.ng.bluemix.net
(中略)
$ cf push jtf-‐php Creating app jtf-‐php in org erm / space production as xxxxx... OK
※デモで話した内容
全く同じようにうごきました
$ cf scale jtf-‐php -‐i 3 Scaling app jtf-‐php in org erm / space production as xxxxx... OK
※デモで話した内容
スケールアウトも簡単にできます
Cloud Foundryのメリット• たくさんのベンダーがCFを採用
• Open PaaSの理想「アンチベンダーロックイン」が実現されつつある
• Open PaaSでは古参なので、比較的情報が多い
• Eclipse, IntelliJ, Visual StudioなどのIDEサポートがある。ツールも豊富
Cloud Foundryのデメリット• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフトウェアスタックになりつつある
• NIH症候群の気が・・・
Cloud Foundryのデメリット• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフトウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変
Cloud Foundryのデメリット• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフトウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変
• デプロイが死ぬほど大変
は？
は使えないの？
次期バージョン”Diego”でDocker imageサポート
Docker image互換じゃなくて
Dockerが使えるPaaSが欲しい？
OpenShift
Red Hatが開発
2011年に発表、2012年にOSSとして公開。
2015年、それまでの仕組み(OpenShift v2)を捨て去り、Docker PaaSとして生まれ変わったOpenShift v3を公開。
KubernetesをPaaSにOpenShift v3のコアはKubernetes
Kubernetesの開発にはRed Hatが深く関わっている
Kubernetesの概念(Service, Pod, Replication
Controller)をそのまま取り入れている
OpenShiftの展開
DEMO
DEMOしようと思ったけど
失敗(◔⊖◔)
http://www.slideshare.net/jacopen/openshift-3dockerpaasあたりを参考に・・・
OpenShiftのメリット• コアにKubernetesを据えることで、進化が著しい
• Githubとの連携やwebhookなど、便利な機能が最初から揃っている
• Red Hat + Google + その他沢山のベンダーや開発者によって開発される安心感
OpenShiftのデメリット• Kubernetesの概念が色濃く残っており、PaaSとして使い勝手がいいかどうかは・・・？
• Cloud Foundryほどエコシステムが広がっていない
• アーキテクチャのリセットはこれで最後・・・だよね？
Kubernetesは分かりづらい！
もっとシンプルなDocker PaaSは無いの？
Deis
• Docker + CoreOSをベースとしたPaaS
• 2013年公開。OpDemandが開発。
• 2015年、PaaSベンダーのEngine YardがOpDemandを買収
DEMO
$ deis create Creating application... done, created sanest-‐odometer Git remote deis added
$ git remote show deis origin
$ git push deis master Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (9/9), 1.04 KiB | 0 bytes/s, done. Total 9 (delta 1), reused 0 (delta 0)
(後略)
※デモで話した内容
deis createすると、deisにアプリが作られると同時に gitにremoteリポジトリが追加される
あとは git push deis masterすればデプロイされる、 Herokuライクな使い勝手。
$ deis create Creating application... done, created sanest-‐odometer Git remote deis added
$ git remote show deis origin
$ git push deis master Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (9/9), 1.04 KiB | 0 bytes/s, done. Total 9 (delta 1), reused 0 (delta 0)
(後略)
※デモで話した内容
簡単
$ deis scale web=5 Scaling processes... but first, coffee! done in 12s === unisex-‐newsreel Processes
-‐-‐-‐ web: web.1 up (v2) web.2 up (v2) web.3 up (v2) web.4 up (v2) web.5 up (v2)
※デモで話した内容
deis scaleでスケールアウト可能。 ただ、ちょっと遅い
Deisのメリット• Herokuライクな使い勝手
• Buildpack, Docker image, Dockerfileなど様々な仕組みが利用出来る
Deisデメリット• スケジューリングが遅い
• Productionに投入するにはもう少し・・・
Flynn
Flynn
• Docker PaaS
• 2013年、クラウドファウンディングのスタイルでスタート。現在はPrime Directiveが開発を主導
• シンプルなHerokuクローン Dokkuの作者が開発に関与している
DEMO
$ flynn create Created coyotes-‐rebuff-‐richards
$ git remote show deis flynn origin
$ git push flynn master Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (9/9), 1.04 KiB | 0 bytes/s, done. Total 9 (delta 1), reused 0 (delta 0) -‐-‐-‐-‐-‐> Building coyotes-‐rebuff-‐richards... -‐-‐-‐-‐-‐> PHP app detected
(後略)
※デモで話した内容
flynn createでアプリ作成とリモートリポジトリ追加 git push flynn masterでデプロイ。
deisと驚くほど一緒 (まあ、Herokuのインスパイア)
$ flynn create Created coyotes-‐rebuff-‐richards
$ git remote show deis flynn origin
$ git push flynn master Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (9/9), 1.04 KiB | 0 bytes/s, done. Total 9 (delta 1), reused 0 (delta 0) -‐-‐-‐-‐-‐> Building coyotes-‐rebuff-‐richards... -‐-‐-‐-‐-‐> PHP app detected
(後略)
※デモで話した内容
(n‘∀‘)η
$ flynn scale web=5 scaling web: 3=>5
14:32:04.554 ==> web flynn-‐6e60228c3fa54933acc30401b9a30a4d starting 14:32:04.747 ==> web flynn-‐397fba6e68cf4206bb8c28328a843427 starting 14:32:05.215 ==> web flynn-‐397fba6e68cf4206bb8c28328a843427 up 14:32:06.344 ==> web flynn-‐6e60228c3fa54933acc30401b9a30a4d up
scale completed in 2.252653272s
※デモで話した内容
flynn scaleでスケールアウト可能。 こちらはかなり速い
Flynnのメリット• シンプル、かつモジュラーでカスタマイズしやすいアーキテクチャ
• PaaSに必要な要素がFlynn内でほぼ完結している
Flynnのデメリット• CF, OpenShift, Deisに比べると開発の継続力に一抹の不安
• モジュラーなアーキテクチャは良し、しかしどこまでメンテナンスし続けられるか
アプリのデプロイ方法
cfコマンド git git ocコマンド
webhook
アプリのデプロイ方法
buildpack (docker image)
buildpack docker image
buildpack docker image
dockerfile
STI docker image
前提OS
Ubuntu Ubuntu CoreOS RHEL
CentOS
コンテナ
Warden Docker Docker Docker
By gopher-vector https://github.com/golang-samples/gopher-vector
Ruby + Golang
Golang
Python + Golang
Golang
開発言語
4つのOpen PaaSを比較してみましたが
どれもあまり変わらなくね？
✓ gitやCLIツールからデプロイができて
✓ DockerfileやBuildpackのような複数言語を扱う仕組みが使えて
✓ コマンド一発で起動・停止・スケールアウトが出来て
✓ リクエストルータもあってマルチホストに展開ができる
何故どれも似た感じになるのか
スケールするWebアプリケーションのベストプラクティスがある
• 12 Factor appの考え方は極めてシンプルで優れている
• どのPaaSも、12 Factor appを前提に作り込んでいく
• 結果として、どれも使い勝手としては似たようなものとなる
大規模にスケールする プラットフォームの作り方も、 だいたい確立している
node
node
nodeアプリが動く 複数のノード
node
node
node
Controller Scheduler
ノードにアプリを配置する コントローラ スケジューラ
node
node
node
Controller Scheduler
Helth Monitoring
ヘルスチェックの 仕組み
node
node
node
Controller Scheduler
RequestRouter
Helth Monitoring
アプリへのアクセスをルーティングする リクエストルータ
node
node
node
Controller Scheduler
RequestRouter
MQ or
KVS
Helth Monitoring
各コンポーネントを疎結合に保つためのメッセージキューキーバリューストア
node
node
node
Controller Scheduler
RequestRouter
MQ or
KVS
Log Collector
Metrics Collector
Helth Monitoring
ログ・メトリクスのアグリゲーション
+
⇒結果として似たような感じに
Open PaaSとの付き合い方
Public PaaSの選択肢として
自社サービスの基盤として Private PaaS構築
自社サービスの基盤として Private PaaS構築• えー、大変じゃない？
自社サービスの基盤として Private PaaS構築• えー、大変じゃない？
⇒ はい、死ぬほど大変です。
自社サービスの基盤として Private PaaS構築• えー、大変じゃない？
⇒ はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない？
自社サービスの基盤として Private PaaS構築• えー、大変じゃない？
⇒ はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない？
⇒ はい、あんまり利きません
でもちょっと待って
皆さん Dockerは使っていますか？
構成管理ツールは？
Fluentdも使ってますね？
優れた仕組みを積極的に取り入れていくのは大切
でも、だんだんと継ぎ接ぎになりませんか？
1. サービスを開発する
2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく
3. だんだん規模が大きくなってくる
4. 間に挟まる仕組みも大規模に、複雑になってくる
5. それぞれのアップデートにかかるコストや、引き継ぎにかかるコストが無視出来なくなってくる
ある種のリスクを抱えている状態
『全部入り』のOpen PaaSを選択肢に
• どうやってスケールアウトしよう・・・
• どうやってログ収集しよう・・・
• どうやってリソース監視しよう・・・
• どうやって無停止でアップデートしよう・・・
みんな課題は似たようなもの
node
node
node
Controller Scheduler
RequestRouter
MQ or
KVS
Log Collector
Metrics Collector
Helth Monitoringきっと自前で作っても似たような仕組みに
ダクトテープを投げ捨てよう
仮にOpen PaaSを採用しなかったと しても、アーキテクチャの参考に
デカイ 複雑
コアはk8s
CoreOSの機能 活用しまくり
これ1つで完結
Open PaaSの未来
やぁ
進化し続けるコンテナへの対応
進化し続けるコンテナへの対応
Webアプリケーション以外のサポート
• コンテナで動けば、アプリケーション自体は動く
• HTTP/HTTPS以外でどうアクセスできるようにするか
TCP Routing
openshift-sdn
Networking v2
あらゆるサービスの「ハブ」に
PaaS
IoT mBaaS
DBaaS Bigdata
進化の著しい世界
楽しい!!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
PaaS勉強会
第27回
7/29
PaaS x IoT Node-RED 勉強会 8/26
Questions?
Recommended