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の中身を詳しく見て見ましょう。

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

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の実装が進められています。

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