Cloud Penguins

Flying penguins in the cloud.

Cloud Foundry Container Runtimeでk8s運用

Kubernetes Advent Calendarの6日目〜

既にこのblogでは触れてしまっていますが、Cloud Foundry Container Runtime(以下CFCR)の話。

先日のKubernetes Meetup Tokyo #8でこんな発表をしました。

CFCRって何? PaaSとは違うの?

Cloud Foundryの名はついていますがPaaSではありません。

PaaSのCloud Foundryで培われた技術を応用して、Kubernetesクラスタを効率よく構築・運用できる仕組みです。

Cloud Foundryで培われた技術って何?

BOSHという仕組みがあります。

bosh

このBOSHを利用してk8sを構築運用するのがCFCRです。 BOSHの仕組みについてはこちらの17ページからを参考に。

https://www.slideshare.net/jacopen/cloud-foundry-container-runtimekubernetes#17

また日本Cloud Foundryグループの怪鳥 会長のozz さんが書いた、BOSH 101も参考になります。

speakerdeck.com

CFCRはどこで試せるの?

CFCRのドキュメントはこちら CFCR

現在のところ、AWS, GCP, vSphere, OpenStack向けのマニュアルが公開されています。

試した事例

makingさんのGCP, AWSでの構築事例

Kubo(Kubernetes on BOSH)をAWSにデプロイ - BLOG.IK.AM

Kubo(Kubernetes on BOSH)をGCPにデプロイ - BLOG.IK.AM

この記事が書かれたのは9月です。当時と概念的なものはあまり変わっていませんが、一部手順が異なる可能性はあるため、できれば公式ドキュメントをみながら構築を試みた方がよいでしょう。

ここらでひとつ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の仕組み
  • 当時の盛り上がりの話

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

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だとどうでしょう。

  1. Dockerfileを書く
  2. docker buildする
  3. docker pushする
  4. kubernetes manifest書く
  5. 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 Foundry Advent Calendarやります

ちょう久々にCloud Foundry Advent Calendarやります!

qiita.com

自分自身も記憶が曖昧だったんだけど、Cloud Foundry Advent Calendarやったの2013年が最後なんですよね。2014年とか15年はOpen PaaSと間口を広げて開催したので。

adventar.org

ただ、今年はCloud Foundry Container Runtimeもありーの、BOSH v2もありーのでCloud Foundry特化でも結構ネタが書けるんじゃないかなと思いまして。自分自身も転職により、よりCFに近い立ち位置になりましたので、改めてAdvent Calendarをやってみようと思った次第。

というわけで、CFに関わっている方も、趣味でやっている方も、利用者として使われている方も、気軽に参加していただければと思います。 難しい内容でもライトな内容でも大歓迎です!

第二種電気工事士

先日第二種電気工事士の実技試験を受けてきたんですが、9/1に発表があり無事合格してました。

f:id:jaco-m:20170902211324j:plain

実は去年も受けていて、筆記は簡単に突破したんですが実技はどこかをミスったと考えられ、不合格になっていました。 1年間は学科免除になるとのことなので、今年再挑戦した次第。

勉強や練習に費やした時間は 筆記: 15時間〜20時間 実技: 12時間 (去年4時間、今年8時間)

正直そんなに勉強に時間を使いたくなかったので、直前に詰め込む形で勉強。

筆記対策で購入したのはこのシリーズの2016年版。対策本と過去問。 amzn.to amzn.to

対策本を1周通しで読み、その後はひたすら過去問を解くという形。おそらく8割くらいはとれたんじゃないかな?

実技は工具セットと練習用材料キットを購入

http://amzn.to/2wvNazjamzn.to http://amzn.to/2exJlFcamzn.to

去年は練習用キットで一通り基礎の使い方を学んで、ホーザンのサイトで候補問題をいくつか動画視聴。ただ、正直これではまったくの準備不足でした。最終的には時間が不足し、残り数十秒というところでなんとか完成させたものの、チェックを行う時間すら無いという状況に陥ってしまいました。

電工試験の虎

今年は全ての候補問題の動画視聴&単線図⇒複線図起こしを行い、かつ器具の使い方や加工についても、頭で考えること無く手が動くように前日はひたすら反復練習。

結果として、試験時間5分前に完成させ、欠陥がないかチェックを行う余裕も持てました。

ということで、最終的には実技+筆記で30時間くらい費やしたかなという感じです。 今後チャレンジされる方は、筆記が簡単だからといって、実技で油断しないようにしましょう・・・

Pivotal Container Service(PKS)とその関連技術のはなし

既に各所でニュースになっていますが、アメリカで開催されていたVMworld 2017でPivotal Container Serviceが発表されました

[速報]VMware、vSphere上にコンテナ環境を自動構築する「Pivotal Container Service」発表。Google Container Engineとのポータビリティ実現。VMworld 2017 US

VMwareとPivotalが「Pivotal Container Service」発表-Google Cloudと協業

エンタープライズ向けKubernetesということで、大きく注目されたようです。

PKSの技術要素

PKSは、今年の春に発表されたKubo(Kubernetes-BOSH)を中心に、いくつかのVMwareテクノロジーを組み合わせた構成になっています。

f:id:jaco-m:20170831160429j:plain

Kubo

KuboはCloud Foundryでも使われているBOSHでKubernetesのデプロイと運用をしてしまおうという仕組みです。既に世の中にはいくつかのKubernetesのデプロイツールが存在していますが、これらはあくまでもデプロイをやってくれるだけ。実際に運用を行っていく上で必要なモニタリングやロギングなどの要素は別途作る必要があります。

ただ、Kubernetesのような大規模な仕組みの運用ってかなり大変なんですよね。でも、Cloud Foundryの運用ノウハウが詰まったBOSHを使うことで、そのあたりを一挙に解決できます。

BOSHをもっと知りたい、試したいという方は、makingさんのblogを参考にするのがよいでしょう

また、9/12に開催されるCloud Foundry Tokyo MeetupではBOSH祭りと称して、BOSHの基礎から利用事例まで幅広いセッションが予定されてますので、興味のある方はこちらも是非。

VMware Technology

k8sのオーバーレイネットワーク部分にはCNI準拠のNSX-Tが。 Docker RegistryとしてHarborが使われています。

Open Service Broker

GCPと連携するための仕組みとして、GCP Service Brokerが用意されています。 GCP Service BrokerはOpen Service Brokerに準拠しており、これを経由してGCPの各サービスのプロビジョニングやコンフィグレーションが行われます。

PKSのデモ

VMworldのKeynoteでは、PKSのデモも行われました。このビデオの0:52あたりを参照。 自分もPKSのデモは初めて見たんですが、おおすげぇ!ってなりました。こんなに簡単にk8sクラスタ作れちゃうのすごい。

実物触れるようになる日が楽しみですね。

MasterCloud #4で話しました

先日開催された MasterCloud #4 で、Cloud Foundryについてお話してきました。

発表資料はこちら

Dockerは便利だけど、自分でイメージの管理するとなると結構手間かかったりするんですよね。 自前でコンテナイメージの作成や管理できるのは便利なケースもある一方、手間ばかりかかって開発速度が落ちるというケースもしばしば。じゃあどうすれば?というときに、Cloud Foundryという選択肢も考えてみてはいかがでしょう という発表内容でした。