[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
SlideShare a Scribd company logo
Cloud Foundryで学ぶ

PaaSのしくみ講座
日本Cloud Foundryグループ
Kazuto Kusama
@jacopen
日本Cloud Foundryグループ
#cfgrjp
PaaS
1. コードを書く 2. PaaSにデプロイ 3. 動作!
すごく簡単
PaaS
1. コードを書く 2. PaaSにデプロイ 3. 動作!
PaaS
わかる わかる え、どうやったの?
1. コードを書く 2. PaaSにデプロイ 3. 動作!
PaaS
わかる わかる え、どうやったの?
4. スケールアウト
???
PaaSが便利なのは分かる
インフラを知らなくとも使える
でも、ブラックボックスなのは嫌だ
今回の目的
• ブラックボックスに思われがちな、PaaSの中身を理解して貰う
ことで、不安を解いてもらいたい
• Cloud Foundryだけでなく、どのPaaSにも共通して利用できる
知識を身につける
PaaS上の

アプリの動作を
見てみる
PaaS上の
アプリの一生を
追ってみる
PaaSを支える
仕組みを学ぶ
321
教材: Cloud Foundry
• オープンソースのPaaSなので、

誰でも仕組みを追える
• 多くのベンダーが採用

(IBM, HP, NTT Comなど)
• ユーザーが機能を拡張できる、Heroku
互換のBuildpackを採用している
PaaS上の

アプリの動作を
見てみる1
例えば、PHPアプリを構築するとき
• Apache/Nginxをインストール
• PHP(mod_php/php-fpm)をインストール
• 必要に応じてpeclやpearをインストール
例えば、Rubyアプリを構築するとき
• Rubyをインストール
• bundle install
• (Railsなら) rake assets:precompile
• (Railsなら) rake db:migrate
DEMO
※DEMOで話した内容
皆さんが普段Apache+PHPの環境を作りたいと思ったとき
たぶんこんな感じでapt-getでインストールすると思います。
するとほら、こんな感じでApacheのプロセスが起動するわけですね。
※DEMOで話した内容
じゃあRubyのアプリの場合はどうか。
ここにSinatraのアプリを用意しましたので、まずは定番のbundle installですね。
その後に起動します。
※DEMOで話した内容
すると、こんな感じで起動するわけです。
ここまでは、皆さんが見慣れた光景ですよね。
Server
OS
Apache
PHP (mod_php/php-fpm)
Application
Server
OS
Ruby
WEBrick
Application
サーバー
OS
ミドルウェア
アプリケーション
手動で構築したときのソフトウェアスタック
では、PaaSの場合は?
DEMO
※DEMOで話した内容
PaaSの場合、中身はどうなるんでしょう。
今回、自前のCloud Foundry環境を用意したので、まずはSinatraアプリを
デプロイしてみます。
※DEMOで話した内容
デプロイ出来たので、実際にPaaS環境の中に入って、どんな感じにアプリが
上がっているか見てみましょうか。
Rubyのプロセスが上がっているのが分かりますよね。さっきと殆ど同じという
ことが分かるでしょう。
※DEMOで話した内容
次にPHPアプリをデプロイしてみました。
httpd となっていますが、さっき手動で上げたときのapache2のバイナリの
名前が違うだけです。単純にApacheのプロセスが上がっているだけ、
と言うことです。
つまり、皆さんが普段自前で組んでる環境も、PaaSで組まれる環境も、
中身は殆ど同じ、というわけです。
Server
OS
Apache
PHP (mod_php/php-fpm)
Application
Server
OS
Ruby
WEBrick
Application
サーバー
OS
ミドルウェア
アプリケーション
PaaS上のソフトウェアスタック
PaaSであっても

アプリが動く仕組みは一緒
ポイント①
PaaS上の
アプリの一生を
追ってみる2
Server
OS
Apache PHP
/usr/sbin/apache2
/etc/apache2/
…
/usr/bin/php5
/etc/php5/
…
apt-get
yum
source…
手動で構築する時
• aptやyumなどの

パッケージマネージャ
• ソースからコンパイル
• どちらの場合も、

サーバーの特定の場所
にランタイムが配置さ
れる
Server
OS
?
6u45
7u79
8u45
5.4.39
5.5.23
5.6.7
1.9.3-p551
2.1.6
2.2.2
PaaSの場合
• 様々な言語、それも

様々なバージョンに

対応しなければいけない
• どこにどう

インストールされている
のだろう?
DEMO
※DEMOで話した内容
さっき上げたアプリをもう一度見てみましょうか。
/home/vcap/app∼の下に、何かコンフィグがあるようですね。見てみましょうか
あれ、おかしいですね。/home/vcapに居るはずなのに、そもそもappなんて
ディレクトリが存在しないように見えます。
※DEMOで話した内容
Rubyの場合も、/home/vcap/app配下のファイルを読んでいるようですが、
やはりPaaS環境上に、そんなファイルは存在しないように見えます。
どういうことでしょうか。
※DEMOで話した内容
ここで皆さんに覚えておいて欲しいのが、コンテナという仕組みです。
この後説明しますが、アプリはコンテナの中で動いています。実際にアプリの
コンテナの中に入ってみますね。
コンテナの中で、Rubyプロセスが上がっているのが確認出来ます。
ファイルはどうでしょうか。
※DEMOで話した内容
はい、確かにファイルが存在することが確認出来ました。
これはさっきアップロードした、Sinatraアプリですね。
bin/ の中を見てみると、rubyやgemなど、実行に必要なバイナリが既に
設置されていることが分かります。実際にRubyバイナリを実行して、
バージョン情報を見てみましょうか。
※DEMOで話した内容
では、PHPアプリのほうを見てみましょうか。
こちらも/home/vcap/app が存在しますね。ここで重要なのは、さっきのRubyと
同じパスなのにも関わらず、設置してあるファイルは全く別物ということです。
アプリケーションに応じて、必要なものが、適切に設置してあるわけです。
✓ PaaSの実行環境では、アプリごとにコンテナが作られ、

マルチテナントで動いている
✓ コンテナの中には、実行に必要なバイナリが全て含まれている
✓ その他実行に必要な作業も全て実施済(Rubyのbundle installなど)
Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/
Server
OS
Apache
Ruby 2.1.4 Ruby 1.9.3-p551 Java7
php-fpm
Tomcat
app A app B app C app D
それぞれがコンテナ
Application
Application Application
Application
コンテナ技術
• Cloud Foundryの場合、Wardenという
独自のコンテナ機構を使っている
• HerokuはLXCを利用
• 最近はDockerが流行り
いずれもLinuxのcgroupsやnamespaceと
いう機能を活用しており、得られる

メリットは似通っている
Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/
コンテナによるメリット
• 異なる環境をアプリに提供出来る
• JavaならJava、RubyならRuby
• アプリ同士を隔離出来る
• セキュリティの担保、リソースの制限
• 素早く立ち上げることがきる
• VMを使うと数分、コンテナなら数秒
Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/
Application
Application Application
Application
Server
OS
Apache
Ruby 2.1.4 Ruby 1.9.3-p551 Java7
php-fpm
Tomcat
このコンテナイメージは、
誰が、いつ用意したのか?
Buildpack
Buildpack
• Herokuによって作られた、任意の言語
やフレームワークを扱えるようにする
仕組み
• Cloud FoundryもBuildpackを利用可能
Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574
Buildpack
• Ruby
• PHP
• Java
• Python
• Go
• Node
• etc…
Buildpackの3フェーズ
1. Detect
2. Compile
3. Release Buildpackには、必ずこの3スクリプトが

含まれている
1. Detect
2. Compile
3. Release
Buildpackの実行条件に合致するかを
チェックするスクリプト。
合致したら0を、合致しなければ1を返
す。
1. Detect
2. Compile
3. Release
composer.jsonがあるか
(無ければ次へ)
.phpのファイルがあるか
(無ければ次へ)
$WEBDIRがあるか
PHP Buildpackの場合
1. Detect
2. Compile
3. Release
実行環境を構築するスクリプト
1. Detect
2. Compile
3. Release
Ruby Buildpackの場合
1. Gemfileから指定Rubyバージョンを

確認して、バイナリをダウンロード
2. フレームワークを確認(Rails?Sinatra?)
3. bundle install
4. rake assets:precompile(Railsの場合)
1. Detect
2. Compile
3. Release
実行に必要な環境変数などの情報を出力
(今回は説明は割愛)
つまりBuildpackとは
• コードがどういう言語で書かれている
か検出する
• その言語向けの環境を構築する
Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574
ここまでの復習を兼ねて

一連の流れで考えてみよう
1. ユーザーがアプリをプッシュ
2. Cloud Foundryがアプリを受け取る Insi
Ruby buildpack
Java buildpack
PHP buildpack
PH
3. アプリに対し、内蔵のBuildpackのdetect

 スクリプトを順次実行
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
4. detectでマッチしたBuildpackの

 compileスクリプトを実行
Inside PaaS
Java buildpack
PHP buildpack
PHP buildpack
5. ランタイムもアプリも含まれた
 実行環境一式が出来上がる
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
6. Cloud Foundryの実行ノードで
 アプリを起動
 (このとき、コンテナで動く)
aaS
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
Buildpackの適用を中心とした、
アプリの準備作業を「ステージング」と呼ぶ
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
PaaSへの「デプロイ」は「アップロード」

「ステージング」「実行」の3フェーズで構成される
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
これまで手動で行ってきたインストール作業を

コードから自動判別して行っているに過ぎない
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
スケールアウトの仕組み
DEMO
※DEMOで話した内容
Cloud Foundryでは、コマンド一発でアプリケーションのインスタンス数を
増やすことができます。それも一瞬で。実際に試してみましょうか。
一瞬で起動しましたね。手動でサーバーをスケールアウトするのと比べると、
数百倍、数千倍速いですね。これはどういう仕組みなんでしょうか。
←だいたい数秒
スケールアウト
• コマンド一発で、たくさんのインスタ
ンスを展開出来る
• しかも速い
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
・
・
・
buildpackをたくさん実行?
時間がかかるし、負荷も高そう
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
Dropletと言う形で、保存しています
Droplet
Cloud Controller DEA
(Droplet Execution Agent)
Ruby buildpack
Java buildpack
PHP buildpack
PH
アップロードを受け取るのは、CCの仕事
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
CCからDEAに、ステージングの依頼
PHP buildpack
DEAは成果物(Droplet)を返す。CCはそれを保存。
CCはDropletを各DEAに配布して実行を依頼する
スケールアウト時は、ステージングは行わず

Dropletの配布のみで済む
PaaSを支える
仕組みを学ぶ
3
appA appA appAappBappB
Internet
?
アプリは複数台に跨がっ
ているだけでなく、関係
ないアプリと同居してい
るという状態。
目的のアプリにどうやっ
てアクセスすればよいか。
リクエストルーティング
Router
appA appA appAappBappB
appA.example.comは192.168.10.2:52341で上がってます
appB.example.comは192.168.10.2:52313で上がってます
各DEAは、自分の持つ

アプリのポートとIPアドレ
ス、URLをRouterに通知
appA appA appAappBappB
appA.example.comは192.168.10.4:64341で上がってます
appA.example.comは192.168.10.5:23591で上がってます
各DEAは、自分の持つ

アプリのポートとIPアドレ
ス、URLをRouterに通知
appA appA appAappBappB
これで、Routerは
どこのIPのどのPortに、

どのアプリが動いているか
知ることが出来る
appA.example.com 192.168.10.4:64341
192.168.10.5:23591
192.168.10.2:52341
appB.example.com 192.168.10.3:32563
192.168.10.2:52313
appA appA appAappBappB
実際にリクエストが来たら、
リストを元にアクセスを分
配
♪
appA.example.com
✓ Cloud FoundryのRouterは、アプリへのリクエストを解釈して正
しい場所に転送する、L7のリクエストルーター
✓ Routerが利用する情報は、各DEAからもたらされる
✓ 一般的に使われる、L3の「ルーター」とは異なるので注意
Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/
メッセージングバス
appA appA appAappBappB
負荷が高くなっても対応できるよう、Routerは複数台で負荷
分散できるようになっている。
appA appA appAappBappB
ところで、先ほど「DEAはRouterに通知する」と表現した。

つまり、Routerの数が増えると、通知数も増えてしまう?
Router数 x DEA数=通知数・・・
appA appA appAappBappB
もちろん、そうはならない。メッセージのやり取りは、

NATSというPub-Sub型メッセージングバスを通じて行う
NATS
Publish-Subscribeモデル
• メッセージの送信側(Publisher) と受信
側(Subscriber)が存在
• Publisherはトピックを付けてメッセー
ジを送信する。どれだけのSubscriber
が居るかは関知しない。
• Subscriberは、指定しているトピック
のメッセージを自動的に受信する
Publisher Subscriber
Publish-Subscribeモデル
Subscribe ENL
ENL
RES
Subscribe ENL and RES
Subscribe RES
NATS
Publish
Publish
appA appA appAappBappB
Subscribe
router.register
Publish
router.register
{“uris”:[“appA.example.com”],”host”:"192.168.10.2","port":35155}
NATS
appA appA appAappBappB
Subscribe
router.register
Publish
router.register
NATS
Publish
dea.start
Subscribe
staging.start
Subscribe
dea.start
Subscribe
dea.advertise
Publish
dea.advertise
CC-DEA間もNATS
NATS
• NATSを通じて疎結合に構成されている
• どこに何が存在するか、各コンポーネ
ントが把握しておく必要が無い(NATS
のアドレスさえ分かっていればいい)
• そのため、柔軟にコンポーネントの追
加・削除が行える
死活監視
appA appA appAappBappB
運用していると、必ず障害は起こる
ぬるぽ
ソフトウェアのバグで
アプリがクラッシュ
ハードウェア障害で
DEAホストがダウン
Health Manager
appA appB
アプリのクラッシュ時
ぬるぽ
NATS
Σ
appB
DEAがアプリのクラッシュを検出
appA appB
アプリのクラッシュ時
ぬるぽ
NATS
Publish
droplet.exited
Subscribe
droplet.exited
appB
dropletが終了した旨をpublish。

HMはそれをsubscribeしている
appA appB
アプリのクラッシュ時
NATS
Publish
hm9000.start
appB
Subscribe
hm9000.start
HMはCCにクラッシュしたアプリを
再度上げるよう通知
appA appB
アプリのクラッシュ時
NATS
appB
Publish
dea.start
Subscribe
dea.start
CCはDEAにアプリの立ち上げ
メッセージを通知
appA appB
アプリのクラッシュ時
NATS
appB appA
アプリが復旧する
appA appB
ホストのクラッシュ時
NATS
appB
DEAは普段から、heartbeatを定期的にpublishしている
Publish
dea.heartbeat
Running appA, appB
Publish
dea.heartbeat
Running appB
Subscribe
dea.heartbeat
appA appB
ホストのクラッシュ時
NATS
appB
ホストがクラッシュした場合、heartbeatが来なくなるので
HMはクラッシュに気づく
Publish
dea.heartbeat
Running appB
?
appA appB
ホストのクラッシュ時
NATS
appB
足りなくなった分を増やすよう通知
Publish
hm9000.start
Subscribe
hm9000.start
appA appB
ホストのクラッシュ時
NATS
appB
アプリが復旧する
appA
appB
Publish
dea.start
Subscribe
dea.start
まとめ
ユーザーが書いたコードは
PaaS上でよしなに実行される
PaaS
アプリ自体は、ごく一般的な仕組みで動いている
OS
Runtime
Framework
その裏には、多くの人に便利なサービスを

提供できるよう、考え抜かれた仕掛けが存在する
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
Cloud Controllerはユーザーからのリクエストを
受け取り
Buildpackにより実行可能なDropletが作成され
Ruby buildpack
Java buildpack
PHP buildpack
DropletはCCのコントロールにより、

素早くDEA上で実行される
Routerはアプリがどこで動いていても

適切なアクセス手段を提供する
アプリはDEAとHealth Managerにより

監視され、問題が起きてもすぐに復旧される
全てのコンポーネントはNATSにより疎結合に

結ばれており、柔軟に構築ができる
NATS
これがPaaSの仕組み
もちろん、PaaSに必要なものは他にもある
• ユーザーの管理・認証・認可
• ログの管理
• メトリクスの管理
• 課金
• Web GUI
• データベース等のサービス
これらの話は、またの機会に。
おまけ: これからのPaaS
最近のトレンド
OpenShift
DockerベースのPaaSが増えつつあるDeis
Flynn
Cloud Foundryも、

次期アーキテクチャ”Diego”で

Dockerに対応する予定
Diego
Diegoでは、NATSではなく

CoreOSが開発するetcdを利用する

(現在も一部にはetcdを使っている)
今後もPaaSは変わりつづけるけれど
• Buildpack <=> Dockerfile
• Droplet <=> Docker image
• NATS <=> etcd
と置き換えて考えることも出来る(同一ではないけど)

新しい仕組みを取り入れたからといって、

これまでの知識が無駄になるわけではない
日本Cloud Foundryグループ
#cfgrjp
PaaS勉強会
#paasjp http://paas.connpass.com/
参考情報
• はじめてのCF Buildpack http://www.slideshare.net/jacopen/cf-buildpack
• Cloud Foundryは何故動くのか http://www.slideshare.net/jacopen/cloud-foundry-33851040
• Cloud Foundry V2を、もうちょっと深掘りしよう http://www.slideshare.net/jacopen/c-fv2
• 日本Cloud Foundryグループ http://cloudfoundry.gr.jp/
• PaaS勉強会 http://paas.connpass.com/

More Related Content

What's hot (20)

PDF
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
Masaya Tahara
 
PDF
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
 
PDF
今だからこそ知りたい Docker Compose/Swarm 入門
Masahito Zembutsu
 
PDF
Keycloak拡張入門
Hiroyuki Wada
 
PDF
わたくし、やっぱりCDKを使いたいですわ〜CDK import編〜.pdf
ssuser868e2d
 
PDF
RDF Semantic Graph「RDF 超入門」
オラクルエンジニア通信
 
PDF
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
 
PDF
マイクロにしすぎた結果がこれだよ!
mosa siru
 
PPTX
分散トレーシングAWS:X-Rayとの上手い付き合い方
Recruit Lifestyle Co., Ltd.
 
PDF
Linux女子部 systemd徹底入門
Etsuji Nakai
 
PDF
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
Google Cloud Platform - Japan
 
PDF
AWSでDockerを扱うためのベストプラクティス
Amazon Web Services Japan
 
PDF
BuildKitの概要と最近の機能
Kohei Tokunaga
 
PDF
PostgreSQL Query Cache - "pqc"
Uptime Technologies LLC (JP)
 
PDF
Internet Week 2018 知っておくべきIPv6とセキュリティの話
Akira Nakagawa
 
PPTX
initとプロセス再起動
Takashi Takizawa
 
PDF
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
 
PDF
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
PPTX
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
PDF
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
 
OSS+AWSでここまでできるDevSecOps (Security-JAWS第24回)
Masaya Tahara
 
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
 
今だからこそ知りたい Docker Compose/Swarm 入門
Masahito Zembutsu
 
Keycloak拡張入門
Hiroyuki Wada
 
わたくし、やっぱりCDKを使いたいですわ〜CDK import編〜.pdf
ssuser868e2d
 
RDF Semantic Graph「RDF 超入門」
オラクルエンジニア通信
 
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
 
マイクロにしすぎた結果がこれだよ!
mosa siru
 
分散トレーシングAWS:X-Rayとの上手い付き合い方
Recruit Lifestyle Co., Ltd.
 
Linux女子部 systemd徹底入門
Etsuji Nakai
 
GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online
Google Cloud Platform - Japan
 
AWSでDockerを扱うためのベストプラクティス
Amazon Web Services Japan
 
BuildKitの概要と最近の機能
Kohei Tokunaga
 
PostgreSQL Query Cache - "pqc"
Uptime Technologies LLC (JP)
 
Internet Week 2018 知っておくべきIPv6とセキュリティの話
Akira Nakagawa
 
initとプロセス再起動
Takashi Takizawa
 
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
 

Similar to Cloud Foundryで学ぶ、PaaSのしくみ講座 (20)

KEY
CloudFoundryをつかってみよう
Kazuto Kusama
 
PDF
PaaS / Cloud Foundry makes you happy
Katsunori Kawaguchi
 
PDF
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
Kazuto Kusama
 
PPTX
microPCFを使ってみよう
Hiroaki_UKAJI
 
PDF
Cloud Foundry構成概要 111018
Uemura Yuichi
 
PDF
Cloud Foundry V2を、もうちょっと深掘りしよう
Kazuto Kusama
 
PPTX
ラズパイ2で動く Docker PaaS
npsg
 
PPTX
ラズパイ2で動く Docker PaaSを作ってみたよ
npsg
 
PDF
クラウドカンファレンスIn静岡 r cloud
Kazuki Aranami
 
PDF
Cloud Foundry: Open Platform as a Service
Shunsuke Kurumatani
 
PDF
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
Takeshi Morikawa
 
PDF
Cloud Foundry Summit 2017 Recap
Shinya Sasaki
 
PDF
Cloud Foundry boosts NTT clouds - Pivotal Cloud Platform Roadshow: Tokyo
Ken Ojiri
 
PDF
捕鯨!詳解docker
雄哉 吉田
 
PDF
Siriproxy - Talk to Cloudfoundry
Takeshi Morikawa
 
PDF
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo!デベロッパーネットワーク
 
PDF
【VMware】jp developer-summit_2012_final_for_print
VMwareKK
 
PDF
成長を加速する minne の技術基盤戦略
Hiroshi SHIBATA
 
PPTX
120517 cf tour_london
Takayoshi Tanaka
 
PPTX
K8s meetup containerized_cloud_foundry
JUNICHI YOSHISE
 
CloudFoundryをつかってみよう
Kazuto Kusama
 
PaaS / Cloud Foundry makes you happy
Katsunori Kawaguchi
 
ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来
Kazuto Kusama
 
microPCFを使ってみよう
Hiroaki_UKAJI
 
Cloud Foundry構成概要 111018
Uemura Yuichi
 
Cloud Foundry V2を、もうちょっと深掘りしよう
Kazuto Kusama
 
ラズパイ2で動く Docker PaaS
npsg
 
ラズパイ2で動く Docker PaaSを作ってみたよ
npsg
 
クラウドカンファレンスIn静岡 r cloud
Kazuki Aranami
 
Cloud Foundry: Open Platform as a Service
Shunsuke Kurumatani
 
第18回Cloud Foundry輪読会用 Buildpackを使ってアプリを 載せるためのアプローチ
Takeshi Morikawa
 
Cloud Foundry Summit 2017 Recap
Shinya Sasaki
 
Cloud Foundry boosts NTT clouds - Pivotal Cloud Platform Roadshow: Tokyo
Ken Ojiri
 
捕鯨!詳解docker
雄哉 吉田
 
Siriproxy - Talk to Cloudfoundry
Takeshi Morikawa
 
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo!デベロッパーネットワーク
 
【VMware】jp developer-summit_2012_final_for_print
VMwareKK
 
成長を加速する minne の技術基盤戦略
Hiroshi SHIBATA
 
120517 cf tour_london
Takayoshi Tanaka
 
K8s meetup containerized_cloud_foundry
JUNICHI YOSHISE
 
Ad

More from Kazuto Kusama (20)

PDF
Concourseで快適な自動化の旅
Kazuto Kusama
 
PDF
Istio, Kubernetes and Cloud Foundry (修正版)
Kazuto Kusama
 
PDF
Istio, Kubernetes and Cloud Foundry
Kazuto Kusama
 
PDF
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
Kazuto Kusama
 
PDF
k8sだけじゃないIstio - Cloud FoundryのIstioインテグレーションについて
Kazuto Kusama
 
PDF
Cloud Foundry Container Runtimeで快適Kubernetes運用
Kazuto Kusama
 
PDF
コンテナ時代だからこそ要注目! Cloud Foundry
Kazuto Kusama
 
PDF
改めてPaaSについて考えてみる
Kazuto Kusama
 
PDF
Cloud Foundry Container-to-Container Networking
Kazuto Kusama
 
PDF
CFの便利機能を他の環境でも。Open Service Broker
Kazuto Kusama
 
PDF
グループ会社を巻き込んで勉強会をやってみるには
Kazuto Kusama
 
PDF
Docker PaaSとしての OpenShift, Deis, Flynn比較
Kazuto Kusama
 
PDF
クラウドを『作る』ってどういうこと?
Kazuto Kusama
 
PDF
Lattice深掘り話
Kazuto Kusama
 
PDF
OpenShift 3で、DockerのPaaSを作る話
Kazuto Kusama
 
PDF
知って欲しいPaaSの話
Kazuto Kusama
 
PDF
Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門
Kazuto Kusama
 
PDF
KubernetesとOpenShiftの話
Kazuto Kusama
 
PDF
最近のKubernetesとDocker Machine/Swarmの話
Kazuto Kusama
 
PDF
DockerとKubernetesが作る未来
Kazuto Kusama
 
Concourseで快適な自動化の旅
Kazuto Kusama
 
Istio, Kubernetes and Cloud Foundry (修正版)
Kazuto Kusama
 
Istio, Kubernetes and Cloud Foundry
Kazuto Kusama
 
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
Kazuto Kusama
 
k8sだけじゃないIstio - Cloud FoundryのIstioインテグレーションについて
Kazuto Kusama
 
Cloud Foundry Container Runtimeで快適Kubernetes運用
Kazuto Kusama
 
コンテナ時代だからこそ要注目! Cloud Foundry
Kazuto Kusama
 
改めてPaaSについて考えてみる
Kazuto Kusama
 
Cloud Foundry Container-to-Container Networking
Kazuto Kusama
 
CFの便利機能を他の環境でも。Open Service Broker
Kazuto Kusama
 
グループ会社を巻き込んで勉強会をやってみるには
Kazuto Kusama
 
Docker PaaSとしての OpenShift, Deis, Flynn比較
Kazuto Kusama
 
クラウドを『作る』ってどういうこと?
Kazuto Kusama
 
Lattice深掘り話
Kazuto Kusama
 
OpenShift 3で、DockerのPaaSを作る話
Kazuto Kusama
 
知って欲しいPaaSの話
Kazuto Kusama
 
Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門
Kazuto Kusama
 
KubernetesとOpenShiftの話
Kazuto Kusama
 
最近のKubernetesとDocker Machine/Swarmの話
Kazuto Kusama
 
DockerとKubernetesが作る未来
Kazuto Kusama
 
Ad

Recently uploaded (6)

PDF
20250717_Devin×GitHubCopilotで10人分の仕事は出来るのか?.pdf
Masaki Yamakawa
 
PDF
Google Driveハブ型Obsidian同期環境:PC編集とモバイル閲覧を安全・効率的に実現するクロスデバイス構築ガイド
honeshabri
 
PDF
20250711JIMUC総会IBM Automation_Platform最新情報_Connpass公開版.pdf
ChikakoInami1
 
PPTX
Devcontainerのススメ(1)-Devcontainerとはどういう技術?-
iPride Co., Ltd.
 
PDF
20250711JIMUC総会_先進IT運用管理分科会Connpass公開資料.pdf
ChikakoInami1
 
PDF
PostgreSQL18新機能紹介(db tech showcase 2025 発表資料)
NTT DATA Technology & Innovation
 
20250717_Devin×GitHubCopilotで10人分の仕事は出来るのか?.pdf
Masaki Yamakawa
 
Google Driveハブ型Obsidian同期環境:PC編集とモバイル閲覧を安全・効率的に実現するクロスデバイス構築ガイド
honeshabri
 
20250711JIMUC総会IBM Automation_Platform最新情報_Connpass公開版.pdf
ChikakoInami1
 
Devcontainerのススメ(1)-Devcontainerとはどういう技術?-
iPride Co., Ltd.
 
20250711JIMUC総会_先進IT運用管理分科会Connpass公開資料.pdf
ChikakoInami1
 
PostgreSQL18新機能紹介(db tech showcase 2025 発表資料)
NTT DATA Technology & Innovation
 

Cloud Foundryで学ぶ、PaaSのしくみ講座