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コミュニケーションズ 草間一人氏のセッションを基に紹介します。

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

アプリを動かすコンテナ、Wardenの仕組み

ユーザーのアプリケーション、DropletはWarden(ウォードン)コンテナの中で実行されます。アプリケーションが終了するとコンテナごと捨てられます。

Wardenはもともとアプリケーションの実行用に作られたのですが、現在ではStaging処理にも使われています。

なぜWardenコンテナをアプリケーションの実行に使うのかというと、マルチテナントを実現する際に、ほかのアプリケーションからの影響を受けないように、などの理由があります。

fig

DEAの中身は2つのプロセスに分かれています。Cloud Controllerと会話をするdeanextというプロセスと、Warden serverです。deanextが「このアプリをWardenコンテナで動かしてよ」とwarden serverに依頼すると、warden serverがそれを自分の子プロセスとして立ち上げるわけです。

fig

Wardenというのは、warden serverとwarden clientとwarden protocolというプロトコル、そしてwshdと呼ばれるコンテナに必要なC言語で書かれたプログラムから構成されています。

Wardenが利用する技術は、Namespacesによる空間の分離、CPUやメモリの制限のためのcgroupsなどです。

fig

つまりWardenは、LXCだったりDockerなどとだいたい同じものなのです。

fig

なぜWardenなのか。LXCやDockerではないのか?

で、このあたりの話をするとよく聞かれるのが、なぜWardenなのか、と。なぜLXCじゃないのか、Dockerじゃないのか、ということです。これから説明するのはCloud Foundryチームの言い分です。

実は初期のCloud FoundryはLXCを使って実装されていましたが、LXCはもともとLinuxを前提に作られています。Cloud Foundryは将来的にWindowsなどもサポートしていきたいという考えがあって、マルチプラットフォームに対応できる仕組みにしたかったから、という理由が1つ。

もう1つは、LXCがCloud Foundryuの要求に対して過剰性能だったというもの。Cloud Foundryでやりかったのはアプリケーションをくるんで動かしたかっただけなので、リッチな機能はいらず、C言語で1000行以下で見通しのいいシンプルな仕組みが欲しかったため、Wardenを作ったと。

fig

Dockerに対しては、Dockerが1コンテナ1プロセスが前提のため、Cloud Foundryの仕組みに合わないこと、Dockerのコンテナを作成後に制限を動的にコントロールできないのが理由だと言われています。

fig

まあCloud Foundry v2を作るときにはまだDockerがなかったので、いまDockerを使っていないのは仕方がないという気もします。

一方で、僕のつっこみとしては、Dockerの1コンテナ1プロセスの前提はSupervisorを使えば手間はかかるけどできるよね、とか、動的に制限がコントロールできないというのは、そもそもCloud Foundryにそんな機能ないよとか、とも思います。

HerokuはBuildpackで記述してLXCで稼働しています。Cloud FoundryはBuildpackで記述してWardenで稼働します。最近はやりのDockerでやろうとするとDockerfileで記述してDockerで稼働です。

fig

個人的な意見では、最終的に実現されるものは一緒ですよと。Dockerはいま流行しているし、WardenよりDockerのほうがよいのではという意見もありますが、実現されるのが同じなら単純に置き換えるのにそれほど意味がないのでは、とも思います。

ただ、DockerfileよりもBuildpackのほうがいろいろできて書きやすいかなという気もしますが、Dockerイメージを突くってイメージ丸ごとアップロードする方法もあるので、そういうのをやってみたいなという気もします。

fig

公開されているスライド「Cloud Foundry V2を、もうちょっと深掘りしよう

Cloud Foundry V2のアーキテクチャ

このエントリーをはてなブックマークに追加
Bookmark this on Delicious

タグ : Cloud Foundry , PaaS , クラウド

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

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


新サイト「Publickey Topics」始めました!


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





アクセスランキング - 過去7日間

  1. VMwareユーザーをAmazonクラウドへ引き込む「AWS Management Portal for vCenter」、vCenterでEC2もEBSも管理可能に。Amazonクラウドがリリース
  2. アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(前編)。QCon Tokyo 2014
  3. アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで(後編)。QCon Tokyo 2014
  4. MySQLのシャーディングを実現する「MySQL Fabric」をリリース、米オラクル
  5. IBM、PaaS型クラウド「BlueMix」を6月末に正式公開へ。IBM Innovate 2014
  6. Salesforce.com用ビジュアル開発ツール「SkyVisualEditor」、Salesforce1対応でiOS/Androidアプリで稼働へ、テラスカイ
  7. 今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2
  8. すでにGoogleは全部のソフトウェアをコンテナに乗せており、毎週20億個ものコンテナを起動している
  9. Gitクライアントの「SourceTree for Windows」、日本語化された最新版が無償公開、アトラシアン
  10. エンタープライズ向けの継続的デリバリツール「CA LISA Release Automation」販売開始。仮想化、クラウド、ミドルウェア、ERPなど複雑な環境でのデプロイを容易に
  11. 最近よく目にする「フルスタックエンジニア」とは何だろうか?
  12. PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは?(前編)
  13. Publickey Smar
  14. DockerがCloud Foundry Foundationへ参加表明。来月にもCloud FoundryがDocker正式サポート発表か
  15. VMwareがパブリッククラウド市場に本格参入。「vCloud Hybrid Service」はオンプレミスのVMware環境との互換性が特長

Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus