Cloud FoundryへのWebアプリケーション配備:第2回
2015年9月24日(木)萱間 真人(CTC クラウドイノベーションセンター 主任)
第1回の『Cloud Foundry見学ツアー」はいかがだったでしょうか。Cloud Foundry上にWebアプリケーションがどのように配備され、そのWebアプリケーションがどのようにリクエストを受け付けレスポンスを返すのかの概要を体感していただきました。今回は、その見学ツアーに登場した主要コンポーネントである「Cloud Controller」を起点に、それと連動する「DEA」および「Warden」について詳しく見ていきましょう。
それでは、第1回の見学ツアー同様に、「Cloud Controller」の部屋へ参りましょう。早速、Cloud Controllerの部屋にきました。Cloud Controllerは、その名前の通り、CloudのControl(制御)を担当しています。Cloudとは、もちろんCloud Foundryのことです。
Cloud Controllerの大事な役割の1つが、各種コマンドやAPI(Application Programming Interface)コールの形で届く“要望”を受け付け、他のコンポーネントに依頼することです。例えば、みなさんがWebアプリケーションを配備したりスケールアウトしたり、その稼働状態を知りたかったり停止させたりしたいとき、それらの要望は、コマンド(「cfコマンド」)やAPIコールという形でCloud Controllerに届けられます。
Webアプリケーションを実行可能な形に変換
Cloud Controllerの部屋の入口を見てください。ちょうど今、Webアプリケーションの配備リクエストが到着しました。誰かが外から「cf pushコマンド」を実行したのです。この配備リクエストを受け取るのはもちろん、Cloud Controllerの役割です。
Webアプリケーションの配備リクエストには、Webアプリケーション本体が合わさっています。node.jsアプリケーションであればJavaScriptファイルを含むソースコード、JavaアプリケーションであればWAR(Web Application Archive)バイナリといった具合です。
第1回の見学ツアーでは、みなさんはWebアプリケーションになって各部屋を回りました。Cloud Foundryの最初の部屋に入った時に、体が重くなったのを憶えていますか?そのことを「Cloud Foundryで実行可能な形式である『Droplet』になるため」と説明しました。それが今、始まろうとしています。
Cloud Controllerは、Webアプリケーションを受け取っても直ぐに実行するわけではありません。まずは、実行できる単位である「Droplet」に変換します。ただし、Cloud Controller自身はWebアプリケーションをDropletには変換できません。Dropletへの変換を担うのは「DEA」という別のコンポーネントです。
そこでCloud Controllerは、Webアプリケーションをいったん保存したら直ぐに、DEAにDropletへの変換を依頼します(図1)。
依頼するのですから、もちろん「依頼書」があります。依頼書には、これがすべてではありませんが、概略として以下のような内容が書かれています。
●Webアプリケーションの識別子
●Webアプリケーションが動作する際の環境変数
●WebアプリケーションをダウンロードするURL
●DropletをアップロードするURL
●Webアプリケーションが使用するリソース量
●Webアプリケーションが使うサービス
●利用可能なビルドパック
質問はありますか?ありますよね。分かっています。「ビルドパックとは何か」でしょう。
ビルドパックは様々な言語に対応するための魔法の関数
Cloud Foundryは様々なプログラム言語で記述されたWebアプリケーションを動作させることができます。その仕組みを支えているのがビルドパックです。ビルドパックは、Webアプリケーションを受け取りDropletを返す関数のようなものです。
ビルドパックはもともと、PaaS(Platform as a Service)事業者のHeroku(2010年に米Salesforce.comが買収)のサービス「Heroku」で使用されていました。Webアプリケーションが、どのようなプログラム言語で記述されているかを自動的に検出し、それを実行するために必要なミドルウェアを含む環境一式のバイナリを生成する仕組みとしてです。
例えば、JavaScriptであれば node.jsランタイムを、Javaであれば仮想マシンのJVMおよびServlet仕様に準拠したWebコンテナを、それぞれ組み込みます。ビルドパックが生成しバイナリをHerokuでは「Slug」と呼んでいます。
ビルドパックの仕様は、オープンに公開されていました。これをCloud Foundryはv2になった段階で取り込み、Dropletを構築する仕組みとして採用しました。これにより、Cloud Foundry上で様々なWebアプリケーションを動かせるようになりました。
このビルドパックをCloud Controllerは、あらかじめ複数保持しています。Dropletの構築を依頼する際にそれをDEAに対し「利用可能なビルドパック」として伝えます。そうすることで、DEAは、伝えられたビルドパックを利用してDropletを構築できるのです。
それでは、WebアプリケーションをDropletに変換する様子を見に、DEAの部屋を訪ねてみましょう。
会員登録(無料)が必要です
- 1
- 2
- 3
- 次へ >
- Cloud Foundryを配備・監視するBOSH【第6回】(2016/01/26)
- Cloud Foundryでログを収集するLoggregatorの動き:第5回(2015/12/22)
- サービスの概念を取り込みWebアプリケーションを拡張する【第4回】(2015/11/24)
- Webアプリケーションのスケールアウトと死活監視の仕組み:第3回(2015/10/27)
- Cloud Foundryのアーキテクチャ─内部見学ツアーへの招待:第1回(2015/08/25)
Cloud Foundry / PaaS / Webアプリケーション / CTC