この投稿は、Open PaaS Advent Calendar 2015の第15日目の記事です。
先月11/26に開かれた第29回PaaS勉強会にて、『BOSH 101』という、超大作のプレゼンを行いました。
いやあ、大変でした。
BOSHという、Cloud Foundryを真の意味で使いこなす上で超えなければならない難関を、勉強会参加の皆さんにどうやったら分かったつもりになっていただくか。 ということを考えていたらなかなか発表原稿に手がつかず、結局ギリギリになってようやく完成したのがあのプレゼンです。
勉強会の席上では結構テンパっていたため、うまく説明しきれていない内容があったかもしれません。
そこでこの記事では、改めてあのプレゼンのポイントや補足情報などを書いてみたいと思います。
結局、この一枚のスライドに尽きます。
ここで出てくる「stemcell」「release」「deployment manifest」という言葉の意味を押さえれば、BOSHに対する理解を格段に深めることができるはずです。
さて、のっけから早速難しい文章が書き連ねられていて、くじけそうですね。
とはいえ、BOSHを普通に使うだけならば、自分でstemcellを作ろうとすることはほとんど無いと思います。（もし作らなければならないとしたら、Cloud FoundryコミュニティにおいてサポートされていないIaaSを使わざるを得なかったり、特別なサービス要件を与えられていたり、といった悲惨な状況かと思います。お察しいたします・・・）
ですので、「BOSHの本体の言うことを何でも聞けるようにするためのagent等と、いざソースパッケージをコンパイルしろなどと言われた時のためのビルド用ツールやライブラリ等が予め仕込まれたVMイメージ」、とだけ憶えておけばOKです。
なお、IaaSの種類ごとにstemcellを用意、とありますが、これはagentに与える比較的大きめの設定ファイルがIaaSごとに異なることや、VMイメージデータの形式が異なることなどに起因しています。
stemcellは上記のように、〜〜〜とだけ憶えておけば、とか言えるのでいいのですが、このreleaseというのはそうもいかないシロモノです。
Puppetで言うところのmanifest、Chefで言うところのcookbook、Ansibleで言うところのplaybook、にそのまま相当する、というわけでは必ずしもないのがこのreleaseですが、いかなる構成においても再利用可能な形式である（べき）ことや、複数を組み合わせてデプロイできる（べき）ことなど、共通点は非常に多いと言えます。
本稿は「BOSH 101.5」であり、releaseの作り方まで触れることは101のレベルを大きく超えますので割愛しますが、がんばれる方は https://github.com/cloudfoundry/bosh-sample-release のあたりでその一端に触れてみてもよいかもしれません。
なお、releaseのjobsディレクトリ配下は、次節で触れるdeployment manifestを正しく書くために参照しまくらないといけないので、その点だけは憶えておくとよいですよ。
で、どういうYAMLファイルかというと、具体的には https://gist.github.com/ozzozz/4d6c899f6b93aa7b9cc9#file-cf-4vm-yml 例えばこういうやつです。
うんざりした貴方。安心してください。貴方の感覚は正しいですよ。
しかし、考えてもみて下さい。分散システムのデプロイを家づくりにたとえるならば、BOSHは工務店、stemcellやreleaseは建材に当たると考えられます。 としたら、 deployment manifest は家の設計図に当たりますので、とっても重要であるはずです。 家を平屋にするのか三階建てにするのか、和風か洋風か、キッチンやトイレの位置はどこか、などなど決めなくてはならないことがたくさんあります。そういうのが1枚のYAMLに書き込まれたのがdeployment manifestなのです。
よく、「鉄板のdeployment manifest下さい」とか言われるのですが、そんなものはありません。 もし誰もが満足して使えるmanifestがあったとしたら、それはreleaseとして再利用可能な形でデフォルト値として実装されるべきです。
deployment manifestは、その時々の要件や環境に合わせて少しづついじくり回しながら、手塩にかけて大事に育てていく盆栽のようなものです。 うまく動作するまで、構成に納得がいくまで、いじっては bosh deploy 、いじっては bosh deploy するのです。 いつしか、そのチーム固有のノウハウの塊になるのです。
さらに言えば、deployment manifestは、パスワードだの秘密鍵だの、よそさまには見せたくない秘密の情報の宝庫なのです。 だから、CFコミュニティのメーリングリストでmanifestクレクレ君が騒いでも、みんなシラッとスルーするのです。
deployment manifestについて、最後はなんだか説教臭くなりましたね。
BOSHを使うにあたり、deployment manifestをうまく書くことが8割を占める、ということを別の回のPaaS勉強会で言ったことがあります。
もし貴方がBOSHと付き合うことになったならば、その点を心に留めておいていただけるとよろしいかと思います。
使い込んでゆくたびに泥沼にハマっていきがちなPuppet/Chef/Ansibleとは違い、使い慣れていけばいくほどラクチンできる（はずの）BOSHを、心ゆくまでお楽しみ下さい。
おしまい。