PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは?(中編)

2014年6月9日

オープンソースで開発されているPaaS基盤ソフトウェア「Cloud Foundry」では、HerokuのBuildpackやコンテナ技術のWardenなどが内部で使われ、柔軟なPaaSの機能を実現しています。

以前の記事「PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている?」の続編として、さらに詳しいCloud Foundryの仕組みを、5月23日に開催された「第19回 PaaS 勉強会(旧称:Cloud Foundry 輪読会)」のNTTコミュニケーションズ 草間一人氏のセッションを基に紹介します。

本記事は前編中編後編に分かれています。いまお読みの記事は中編です。

Buildpackを使ったStagingについて

Dropletを作る作業を「Staging」と呼びます。前回、Dropletのことをゴールデンパッケージと呼んだりしましたが、それはv1の頃の名前で、今はDropletと呼んでいます。DropletとはCloud Foundryで実行可能になったアプリケーションです。

Cloud FoundryにおけるStagingとは、ユーザーがデプロイしたアプリケーションをBuildpackの記述に従って処理し、Dropletを作るまでの流れを指します。

fig

これは前回使った図ですが、ユーザーが「cf push」コマンドでアプリケーションをデプロイするため、Cloud Controllerにアプリケーションをアップロードします。それを受け取ったCloud ControllerがDEAに「staging.start」メッセージを送り、Staging作業を依頼します。DEAがStagingを行ってできあがったファイルが、Cloud Controllerに返されます。

fig

ここで、「staging.start」の内容をもう少し詳しく見ていきましょう。これがstaging.startの実物のメッセージですが、細かくて見えませんね(笑)。

fig

メッセージの内容には、アプリケーションの情報として「\"app_id\":65bf0610-fb24-4756-......」といったidや、必要なリソースとして「\"memory\": 256, \"disk\": 1024,...」といったメモリやディスクの情報、そしてユーザーからCloud Controllerが受け取ったアプリケーションのファイルがあるURL、できあがったDropletの保存先のURLなどが含まれています。

fig

前回の説明で、Cloud ControllerとDEAのあいだはNATSを通してメッセージをやりとりしていると説明しましたが、大きなファイルなどはURLをやりとりしてHTTP経由で転送しています。

標準で用意されるadmin buildpack

Cloud Foundryに最初からインストールされているBuildpackのことを、admin buildpackといいます。

最初の方で、「cf push」コマンドの-bオプションでBuildpackを指定していましたが、-bオプションで明示的にBuildpackを指定しない場合、admin buildpackの中から一致するものが選ばれて実行されるようになっています。

そしてこのadmin builpackは管理者が追加できます。

これは何を意味するかというと、Cloud Foundryを使ってサービスを提供する事業者などは、admini buildpackの仕組みを用いることで、標準で対応する言語を選ぶことができるということです。Node.jsには対応しないのならば、admin buildpackから外す。PHPに対応するのならば、PHPのBuildpackをadmin buildpackに追加する、といったことで対応言語環境を操作できます。

fig

DEAがStagingでDropletを作るまで

次はDEAの話です。DEAがCloud Controllerから「staging.start」メッセージを受け取ってからどんなことをするのか。

まず、Cloud Controllerから指定されたURLでアプリケーションをダウンロードします。

fig

続いてadmin buildpackのdetectスクリプトを順に実行し、適用するBuildpackを特定します。

fig

特定されたBuildpackのcompileスクリプトを実行します。ここではRubyの言語環境のバイナリをダウンロードして設置し、bundle installを実行するなどです。

fig

最後にreleaseスクリプトには起動コマンドなども書かれているため、そうしたものをまとめてyamlファイルを作成します。

fig

最終的にできあがったDropletのツリーを見てみると、/binの下にはrubyとか実行に必要なものがあって、次にアップロードされたファイルやbundle installによって入れられたファイルがあり、一番下にyamlファイルによるstart commandなどの記述があります。

fig

このDropletにはアプリケーションの実行に必要なものが全部含まれているため、どこに持って行っても実行できます。Cloud Foundryでなくとも、tarで固めて自宅のLinuxサーバに持って行って動かすこともできます。

≫後編に続きます。後編では、なぜCloud FoundryでWardenコンテナが使われているのかという理由について。

Cloud Foundry V2のアーキテクチャ

このエントリーをはてなブックマークに追加
follow us in feedly

カテゴリ クラウド
タグ  Cloud Foundry , PaaS


次の記事
PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは?(後編)

前の記事
PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは?(前編)

カテゴリ



Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



新着記事 10本


PR - Books


fig

fig

fig