Cloud Penguins

Flying pengiuns in the cloud.

ここらでひとつCFの昔話をしながら変遷を振り返る(その1)

Cloud Foundry Advent Calendar 2017の5日目〜

先日Facebook開いたら自分の5年前の投稿が。それはこのリンクの紹介でした。

www.ntt.com

懐かしい。前職はこのサービスの開発にがっつり携わっていたのですが、このときにベースにしていたのはCloud Foundryのv1でした。

それともう一つ。先日カサレアルさんが開催されたハンズオンセミナーでお話しさせて頂く機会を頂いたのですが、その際に「Cloud Foundryは2011年のV1から現在のバージョンに至るまで、唯一変わっていないものがある」 といった質問をしてみたんですよ。

答えとしては「cf push(vmc push)だけでアプリケーションのデプロイが出来る」だったのですが、そのときに頂いた答えの中に「コンテナ?」というものがあったんですよね。確かに今PaaSを一から作るなら、間違いなくコンテナの活用を考えるでしょう。

でも、最初のバージョンのCFってコンテナなんて使ってなかったんですよ。「え、じゃあどうやってマルチテナント実現してたの?」って思うかもしれません。

ということで、どのくらい需要があるのか分からないけれど、むかーしむかしのCFを紹介しながら、変遷を振り返ってみようかなと思います。

Cloud Foundryの登場

OSSとしてのCloud Foundryは2011年4月にVMwareから発表されました。

www.publickey1.jp

元々はCloud Foundry社をSpringSource社が買収し、SpringSourceをVMwareが買収したところから始まっています。 その後Pivotalが設立されるまでVMwareが開発を続けていました。

なおこれらCloud Foundry v1のコードはGitHubのcloudfoundry-atticに残っており、今でも全てのコードを確認することが出来ます。

github.com

でもたぶんセットアップしても動かないと思います。たぶん。

CFv1のアーキテクチャ

CFv1のアーキテクチャは非常にシンプル。新野さんのこちらの記事には当時のCloud Foundry輪読会の様子がまとまっています。

www.publickey1.jp

メッセージングバスのNATSがCloud Foundryの要。NATSは現在のCFにもありますが、ずっと広範囲に利用されていました。

Cloud ControllerやHealth Manager、DEA、Routerといったほぼ全てのコンポーネントがNATSに接続し、メッセージのやり取りを行っていました。 自立分散型のアーキテクチャでスケーラブル、にも関わらず現在に比べるとコンポーネント数も少なく、非常に理解しやすいアーキテクチャでした。

これはNATSの開発者であり、当時のCloud Foundryの開発をリードしていたDerek Collison氏(現在はApceraのCEO)の思想がダイレクトに反映されています。

ただ、コンポーネントはスケーラブルだけどNATSがクラスタ非サポートで単一障害点でした :p

認証・認可

全部Cloud Controllerが担ってました。 その後2012年に入り認証をUAA、認可をACMというコンポーネントに分離する考えが示され実装が進められましたが、結局実現したはUAAのみでACMの話はどこかに消え去りました。

labs-vcap-uaa/UAA-CC-ACM-VMC-Interactions.rst at master · mozilla/labs-vcap-uaa · GitHub

マルチテナント

冒頭にも書きましたが、CFv1にはコンテナはありませんでした。 じゃあどうやってマルチテナントを実現していたかというと、アプリケーションごとに異なるuidが設定され、ファイルのパーミッションもそのuidに向けて設定される・・・だけ・・・という、Linuxのユーザー管理に頼る仕組みでした。

f:id:jaco-m:20171205204240p:plain

uid異なるので他のアプリケーションにちょっかい出すことは出来なかったんですが、たとえば他のアプリがCPU食いつぶせばダイレクトに影響を受けます。

アプリからifconfigするとDEAのIP見えるし、ps打つと他にどんなアプリが上がっているか見ることもできてしまいました。

VMwareはcloudfoundry.comというパブリックPaaSもやっていたのですが、そこにifconfigを叩くだけのアプリを立ち上げ、ひたすら上げ下げを繰り返してIPアドレスを収集し、DEAの台数を調べる・・・なんてこともできちゃいましたね。

とはいえこのアイソレーションでは不十分というのは開発側も認識しており、コンテナに対応したDEAの開発も進んでいました。それがDEA_ngです。 DEA_ngでは当初LXCの利用も検討されていましたが、LXCは要求事項に対して機能がリッチすぎ、PaaSの利用用途としては過剰なものでした。そこで、Cloud Foundryチームはwardenとう独自のコンテナランタイムを作成し、DEA_ngに採用しました。

今でこそコンテナは当たり前になりましたが、Dockerが登場したのは2013年、大きく話題になりはじめたのが2014年です。一方この議論は2011年から進んでいます。このことからも、コンテナのムーブメントとは関係なく、それ以前からPaaSの一要素としてコンテナ技術が考えられていたことが分かるでしょう。

なおDEA_ngはCFv1では採用されることなく終わり、実際に使われ始めたのはCFv2になってからです。

www.slideshare.net

buildpack

CFv1にはBuildpackサポートはありませんでした。

ですが当時からRuby, Java, NodeJSなどマルチ言語対応していました。どうしていたかというと、Stagerと呼ばれるコンポーネント内にプラグイン形式で各言語ごとの設定方法が記述されていました。

github.com

なおBuildpackのような言語を自動検出する仕組みはStagerにはなく、クライアント側の判定ロジックで検出し、APIリクエストで言語を指定していました。

なお、2012年末からBuildpack対応のコミットが入り始めましたが、CFv1が収束に向かったため、このvcap-stagingのBuildpack対応は日の目を見ずに終わることになります。

つづく

どう考えても1記事にまとまりそうになかったので、残りは別記事として上げることにします。

  • CLI
  • CFv1のデプロイ方法からBOSHに至るまで
  • Serviceの仕組み
  • 当時の盛り上がりの話

あたりを書いてみようかなと考えています。