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を作るまでの流れを指します。

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

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

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

前回の説明で、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に追加する、といったことで対応言語環境を操作できます。