CFCRとCFARの使い分けの話

Cloud Foundry Advent Calendar1日目！

CF、Kubernetesやるってよ

10月のCloud Foundry Summit EUで、Cloud Foundry Container Runtimeが発表されました。

これは今年の頭から始まったBOSHでKubernetesを構築するプロジェクト "Kubo"がリブランディングされたものになります。 KuboはPivotalとGoogleの共同プロジェクトとして進んでいましたが、今年の6月にCloud Foundry Foundationに寄贈されていました。

KuboがCloud Foundryの名を冠すことになり、これまで単にCloud Foundryと呼ばれていたApplication Platform(PaaS)のほうは、Cloud Foundry Application Rutime(以下CFAR)という名称に変更になります。

おやおやこれはどうしたことでしょう。 Cloud FoundryはついにPaaSを諦めてKubernetesに乗り換えたのか？なんて声も一部から聞こえてきそうです。

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

KubernetesがあるとこれまでのApplication Plaformは要らなくなっちゃうんでしょうか？

Kubernetesにしたところで簡単になるとは限らない

たとえば何らしかのアプリを開発して、世の中に公開することを考えてみましょう。

CFARならこうです。

$ cf push

簡単ですね。

じゃあKuberneteだとどうでしょう。

Dockerfileを書く
docker buildする
docker pushする
kubernetes manifest書く
kubectl createする

この流れの中で、考えなければいけないこと、覚えなくてはいけないこと、結構ありますね。

Dockerfile書くのめんどくさい問題

先日のPivoatl.IO 2018のmakingさんの発表ではこんな話がありました。 f:id:jaco-m:20171201214632p:plain

それな。

自分も正直Dockerfile好きじゃないんですが。この例はめちゃくちゃシンプルなほうで、複雑なDockerfileになると数十行から百何十行になったりします。Dockerの挙動をあらかた理解した上で、さらに自分のアプリが上手く動くように記述していかなくてはいけない。さらにうまくレイヤーが作られるように考慮するテクニックを求められる。結果として、作ったアプリをデプロイしたいだけなのにDockerfileに詳しくならないといけない。

プライベートリポジトリ用意しなきゃいけない問題

パブリックなDockerhubに上げられるならまだしも、表に出したくないイメージの場合何らしかのプライベートリポジトリを用意しないといけない。地味にこれもめんどくさい

k8s manifestツラい問題

これもう、ほんとツラいんですけど、アプリケーション開発者のうちどのくらいの人がこのk8s manifest書きたいと思ってるんだろうというのが気になります。 k8sの練習における定番であるguestbookですら、manifest見るとうへーってなりますね。 https://github.com/kubernetes/kubernetes/tree/master/examples/guestbook

もちろん毎回一から書くのでは無く、既にあるものからのカスタマイズというパターンが多くなると思いますが、やはりアプリケーションそのものに関わる作業ではないので、避けられるのならば避けたい作業の一つです。というか、作ったアプリをデプロイしたいだけなのにKubernetesのリソースに詳しくならないといけない。

アプリごとの最適化を自分で頑張らないといけない問題

これまたmakingさんの発表にもありました。

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

たとえばJavaであれば、ホストのCPUやメモリ量、アプリケーションに応じたパラメータのチューニングが必要なんですが、k8sを利用する場合そのあたりも自分で設定しかなければいけません。というのも、Dockerやk8sはコンテナを動かすための仕組みであって、その上で動くアプリの細かな事情についてはカバー外だからです。

Javaだから悪いというわけでもなく、たとえば　Apache+mod_phpで動かすときにも、ApacheをpreforkにするのかとかMaxClientはどうかとか、そういった細かいチューニングを考慮していかなきゃいけないわけです。

じゃあCFARだとどうかというと、そのあたりは基本自動でやってくれます。なぜならCFARはアプリケーションを動かすために作られた仕組みだからです。Buildpackがうまいことそのあたり設定してくれます。

アプリを開発・運用するならやっぱりCFAR

ということで、もしあなたがアプリケーション開発をしており、それの運用を楽にしたいということでプラットフォームを選ぶのなら、基本CFARのほうが幸せになれます。大体の面で楽ができます。

インフラの柔軟性が必要ならCFCR

じゃあCFCRはどういうときに使うのかというと、身も蓋もない言い方をするとCFARでうまく動かせなかったものを動かす用途になるかなと考えています。たとえばCFARでRedisをキャッシュに使いたいとか、手っ取り早くMySQLのコンテナ立ち上げて繋ぎにいきたいとか。こういったstaticなデータを持つものはCFAR上では動かすことができないため、CFCRで上げるというのは選択肢のうちに入ってくると思います。もっとも、AWSやAzureなどを利用している場合は、そのあたりはマネージドなサービス使った方が良いとは思いますが。

また、Persistent Storageがどうしても必要なアプリケーションの場合も、やはりCFCRを使った方が上手く運用できるかと思います。 Persistent StorageはCFARもNFSに対応していますが、Kubernetesはブロックストレージ含めてさまざまなストレージに対応しているため、そこの点はCFARに比べて明確なメリットがあります。

さいごに

個人的にはこんな感じの使い分けでやっていこうかなと考えています。 CFCRはこの執筆時点での最新バージョンは0.9.0です。おそらくそう遠くないうちに1.0が出ると思いますので、そろそろ本気で活用しても良い時期なのかな、と考えています。

Cloud Penguins

Flying penguins in the cloud.