Cloud Foundryの次バージョンでDockerや.NET対応を実現する「Diego」の内部構造は?(後編) 第25回PaaS勉強会

2015年7月1日

オープンソースで開発されているPaaS型クラウド基盤ソフトウェアの「Cloud Foundry」は、その内部にコンテナベースの実行環境である「DEA」(Droplet Execution Agent)を搭載しています。

Cloud Foundryの次バージョンとなるCloud Foundry V3では、このDEAに代わる新しい実行環境の「Diego」が登場します。そしてDiegoの登場は単にDEAがDiegoに置き換わるのではなく、Cloud Foundryのアーキテクチャそのものの変革につながっています。

(本記事は「Cloud Foundryの次バージョンでDockerや.NET対応を実現する「Diego」の内部構造は?(前編) 第25回PaaS勉強会」の続きです。

DiegoのDocker対応

ここからはDiegoのDocker対応や.NET対応について説明して行きたいと思います。

Diegoは、正確に言うとDockerイメージ対応です。コンテナを動かすCellの中身を詳しく見て見ましょう。

fig

repやexectorというコンポーネントがありますが、いちばん重要なのはgardenです。その下にgarden-linuxがあって、その中にコンテナがいっぱい乗っているという形になります。

fig

gardenというのは「インターフェイス定義」のことです。コンテナを作成するとかネットワークを設定するとか、共通で使われるインターフェイスを提供するのがgardenです。

実際にリクエストを受け取って、コンテナを作るといった実装レベルを担うのがGarden Backencというもの。で、Linux向けのGarden Backend実装がgarden-linuxです。

このgarden-linuxがDockerイメージに対応しているんですね。

どういうことかというと、Buildpackで作られたDropletが渡されたら、いままでと同様にDropletを実行。

Dockerイメージのパスが渡されると、Dockerイメージをリポジトリからダウンロードして、すべてのレイヤーをフェッチし、GardenコンテナのRootfsとしてGardenで使うイメージとして設定し、動かします。

つまりDockerコンテナがDockerとして動くのではなく、Gardenコンテナとして動かす。これがgarden-linuxの仕組みです。なのでDockerファイルには対応していませんが、Dockerイメージには対応しています。

ただ将来的には、garden-linuxをDockerの基盤であるlibcontainerに置き換える構想もあるらしいです。

Diegoの.NET対応

Windowsにgardenを実装して.NETを動かす、というのがDiegoにおける.NET対応です。

Century LinkによるCloud FoundryのWindows対応に「IronFoundry」というのがあります。これがいまCloud FoundryのIncubationに採用されて、Gardenの実装が進められています。

fig

仕組みは、単にgarden-windowsがあるだけでなく、Containerizerなどを使っています。ただ、実際にどうやってWindowsでコンテナを実装しているのかまでは追えていません。IISのHostable Coreというマイナーな機能を使っているようなのですが、誰か調べてくれるとうれしいです。

fig

いずれgarden-windowsが登場すれば、詳しいことがわかると思います。

Cloud Foundry V2とV3の共存

最後はCloud FoundryとDiegoの話です。

Cloud FoundryをDiego対応にしても、いまのCloud Foundry V2の仕組みを残せるので、互換性は保てます。こうなります。

fig

左側、青いのがCloud Foundry V2のレイヤ、右の茶がDiegoのレイヤ、真ん中にV2とDiegoの橋渡しのレイヤがあり、下のレイヤは共通しているものと分類しています。上にあるのがルーティングするレイヤですね。

V2へのリクエストはいままでどおりCloud ControllerからDEAにいきます。

fig

Diegoへのリクエストは、Cloud Bridgeを通してReceptorに届きます。

fig

DiegoのAPIはV3 APIが定義されていて、Diegoを呼び出したいときにはこのAPIを使います。

将来的には、橋渡しとなるRoute EmitterやCC Bridgeは廃止され、それぞれRouterやCloud Controllerにマージされる見通しです。

Diegoは現在「Production Beta」ですが、この資料作成の途中でもまだ仕様変更が起きたりしていますので、近いうちに出るのは本当だろうかという気もします。

ただDiegoがリリースされば、どのベンダもDocker対応という文句を使いたいと思うので、こぞって対応サービスが出るのではないかなと思います。

公開されている資料「Cloud FoundryでDockerも.NETも。新しいDiegoの仕組み入門 - SlideShare

関連記事

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

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


次の記事
自動ビルド環境を作り上げることで、開発効率もコードの品質も向上させよう[PR]
前の記事
Cloud Foundryの次バージョンでDockerや.NET対応を実現する「Diego」の内部構造は?(前編) 第25回PaaS勉強会

カテゴリ



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