収録時間: 1:02:13 | Download MP3 (36.0MB)
伊藤直也さん, 宮下剛輔さんをゲストに迎えて、Docker, chef, serverspec, Travis CI, Vagrant, サーバプロビジョニング、テスト などについて話しました。
Starring
0:00
miyagawa: 今日もゲストが二人いまして、一人目はおなじみの、直也さんです。
naoya: こんにちは。若干食傷気味だと思うんですが……。
miyagawa: いや（笑）。そんなことないと思います。
naoya: これ4回目でしたっけ。
miyagawa: そうですね。もう一人は昨日Twitterで声をかけて、ブッキングするっていう。ラクな時代になった感じなんですけど、serverspecとかの作者でもあるmizzyさんこと宮下剛輔さんです。
mizzy: こんにちは。よろしくお願いします。
miyagawa: 土曜日にすいません。
mizzy: いえいえ。
miyagawa: 最近、naoyaさんのブログとか、ぼくもちょっと趣味でいろいろ遊んでいたりして盛り上がってるのが、バーチャルマシンとかそういう環境をいろいろ作って、プライベートなPlatform as a Serviceを作ってみたり、テスト環境を作ってみたり、みたいな。そういうのがけっこう盛り上がっているので、その辺の話を小一時間ほど出来たらなと思っています。
まず、きっかけということでもないんですけど、ここ一ヶ月ぐらい、個人的に盛り上がっていて、先週ぐらいから遊んでいるのが、Dockerというソフトウェアなんですけども、これを作っているのは、ぼくが昔いた、dotCloudという会社がオープンソースで出していて。ぼくが説明してもいいんですけど、直也さんがすごく詳しいブログを書いてくれたので。
naoya: （笑）
miyagawa: それを読んで、というのでもいいんですけど、簡単に、かいつまんで話してもらってもいいですかね。
naoya: そうですね。まあユースケースから先に言った方がわかりやすいんですけど、VMを簡単に作ることができる、ミドルウェアというかプラットフォームですね。
それだと、Vagrantって、ChefとかPuppetとかと一緒に使うので、よく紹介されるやつがあって、それと変わらないように思えるんですけど、VagrantはVMをただ立ち上げるところに特化していて、一方でDockerは、VMを立ち上げるっていう後の部分も含めて全部やる、と。その時に「後の部分」っていうのは、たとえばTravisとかだとPerlとか、node.jsとか、あるいはObjectiveCがビルドできるみたいな環境を用意して、それでテストできるようにしてくれたりするんですけど、そういうものを作る。つまり、Dockerの中にPerlが動くやつとか、Rubyが動くVMとか、そういうのを用意しておいて、docker runってやると、そのVMをそっくりそのままコピーして、動かせるっていう感じですね。
miyagawa: 技術的な話で言うと、Dockerは、Linux Container、LXCっていうのと、あとはAnother Union FSでいいのかな、AUFSっていうファイルシステムをベースに作られていて、たぶんVMっていう風に、大ざっぱな概念で言うとバーチャルな環境を作るんですけど、実際にハードウェアとかをエミュレートするのではなくて、LinuxのホストOSの中に、元々chrootみたいな感じで、隔離された環境を作っていく、というのがDockerの特徴なんですよね。
naoya: そうですね。単に内部的にはプロセスをForkしてるだけなので、Vagrantとか、ああいうVM起動系のやつは、ファイルシステムを用意したり、OSを初期化したりするところで、時間をけっこう何分かは待たなきゃいけないんですけど、Dockerの場合は docker run ってした瞬間から、その新しい環境が動くので、本当に0コンマ何秒で、それが始められるっていうので。だからテストとかで使うときにはものすごく便利なんですよね。
miyagawa: バーチャルマシンでも使えるので、Docker自体のインストール方法も、もちろんEC2とかの上にインストールすることもできるし、Macの上で動かそうと思ったら、Vagrantのファイル持ってきて、Virtual Boxをインストールして、その上でDockerを動かすこともできるし、もしこのDockerみたいな仕組みが、普通にVMだとしたら、VMの上でまたVMのハードウェアを立ち上げるのは難しいので。たとえばEC2の上でも動かせる、Linodeでも動かせるっていうところが、実際の使い勝手的にも、いいかなっていう感じですよね。
naoya: そうですね。
miyagawa: 宮下さんが作ってるSqaleっていう、これもPaaSだと思うんですけど、そこでもLXCとか使っていたので、似たような感じですよね、技術的には。
mizzy: そうですね、技術的にはすごく似てますね。元々、Sqaleを作るときに、HerokuさんだったりとかdotCloudさんとかすごく中身を研究して、悪い言い方するとパクったっていうことになるんですけど、かなり真似をさせてもらっているので、技術的には同じようなものを使わせてもらっていますね。
miyagawa: Herokuも今はCedarっていう名前のスタックになっていて、第3代目の技術的な変更があったんですけど、昔はもうちょっとローテクな感じのchrootとかを使っていたのが、Linux Containerを使うようになったのがCedarからで。いろんな、いっぱい今、PaaSって雨後の筍みたいに、まあ最近ちょっと落ち着いてきてはいるんですけど、去年とかけっこう出てて。それの先駆けになったのが、dotCloudがLXCを使ってやったのがたぶん最初で。やっぱりLXC時代の開発とか、あとはAUFS自体にもけっこうコミットしているので、それをオープンソースで出したっていうのはけっこう勇気があるなあって思ったんですけど。
ぼくが所属していたときでも、こういうのをオープンソースで出したいっていう話はけっこうずっとしていて。でも、ぼくがやめてから1年以上経っていますけど、タイミングとしてはけっこう面白いかなと思っていて。こういう技術がけっこうコモディティ化している部分もけっこうあるので、そういう環境が作れます、っていうだけでは差別化にならないので、そういうのをオープンソースで、強みとして出していくっていうのはけっこうアリかなあと思っているんですけどね。
naoya: 実際これ使って、dokkuっていう、自分の手元でPaaSみたいなのを作った人もいますね。
miyagawa: そうなんですよね。Docker自体は、レイヤーとしてはけっこう、VMが走る環境があって、その上にコンテナを作って、そのコンテナがどこまでやるかっていうと、よくあるのはnginxを入れるとか、MySQLを入れるとか、Redisを入れるとか、そういうサラのOSの状態からスタートして、そこに何かソフトウェアをインストールして。
設定が済んだ状態で、じゃあ今度はPaaSみたいに使いたい、何かアプリをデプロイしたいって言ったら、たとえばRubyのアプリを動かしたいとか、nodeを動かしたいとか、Python動かしたいとか出てくると思うんですけど、それをいちいち書いているとつらいんですね。何かいい方法ないかなって目をつけたのが、HerokuがBuildpackっていう仕組みを公開していて、もちろんHeroku自体がサポートしている言語のJava、Ruby、Python、nodeとかいろいろあって。ぼくがPerl用のを書いているんですけど、また後でその話もしたいんですけど、一応全部GitHubでほとんどのものがソースは公開されていて、基本はシェルスクリプトで書けるんですね。
なので、Dockerで動かす環境を作ったら、HerokuのBuildpackを持ってきて、Gitでプッシュされたコードをビルドしてデプロイするっていう、そういう仕組みを作った人がいて、これがdokkuっていうやつなんですけど。mini Herokuみたいなみたいなものを100行のbashで作りました、みたいな感じで、それがすごい、小さいハックでこれができるっていうのはけっこう面白いなと思って。
naoya: 使ってはいないんですけど、だいたいスクリプトは読んで、ああこういうふうにやるのか、みたいなね。だからGitで、だいたいPaaSってGitでpushすると、そこからいろんなものが連携して動いていくじゃないですか。Dockerにはそういう、Gitにpushしたとか、そういうインターフェイスみたいなものが全然用意されていなくて。その辺をどういうふうにハンドルしてるのかなっていうのを見てて。それがシェルスクリプトで全部書かれていたっていうね。けっこう面白かったですけど。
miyagawa: ぼくもdotCloudで、そういうビルダーとかを実装したことはあるので、中を見ると、ほとんどやっていることは同じなんですけど、どういうアプリをどの言語でどうデプロイするかっていうのも、ほとんどノウハウっていうのもね、ほとんどなくて。Rubyだったらbundle installして、サーバー立ち上げて、とか。Perlだったらcpanmで、とかCartonでインストールして、とか決まっているので、その辺の仕組みが標準化されてきているのは、開発者にとってはラクでいいですよね。
naoya: そうですね。しかもあれですよね。Dockerの、VMというか、作ったコンテナをCPANみたいに公開できる機能があって、第三者がそれを引っ張ってきて使えるので、Railsが動くコンテナみたいなものをわざわざ自分で作らなくても、Dockerのひな形を持ってきちゃえばそれを使えたりもするっていうのが、そういう標準化をしていることの恩恵みたいなものもありますしね。
miyagawa: そうなんですよね。Dockerファイルっていう仕組み自体は最近始まったみたいで、まだちょっといろいろ仕様が変わったりしているんですけど、要はベースのイメージがあって、UbuntuとかCentOSとか。それに対して、nginxを入れようとかApacheを入れようとか、PHPをインストールするとか。そういう、Chefで言うとことのレシピみたいなものを、ああCookbook？ って言うのかな。まあ、それを重ねあわせて環境を作っていこうみたいな。アイデアとしてはそんな感じですよね。
naoya: そうですね。
miyagawa: ただ、ちょっと細かい話なんですけど、Dockerファイルってけっこう、ベースイメージの名前とかがハードコードされていて、Ubuntuの何とかのヴァージョンにApacheを入れて、とかいう環境があって、「Apache-Ubuntu」とかなっているので、なんか……OSごとに違うの全部入れるのかな、みたいな感じで。
naoya: そうなんですよ。結局だから、あの中でyumコマンド打ったりとか、あとはOSによってはパスが違うじゃないですか、etcファイルの中とか。だからそういうのを書かなきゃいけないので、だからChefとかPuppetとかをしばらく使っていたので、なんか久しぶりにこういう生OSコマンドみたいのを使うとだいぶ拒否反応出る、みたいな。（笑）
miyagawa: ただ、Dockerがいいと思ったのは、Dockerファイルにたとえば10行とか、yum install、apt-get なんとか、とかいろいろ書いていくと、GitみたいにSHA1のハッシュみたいのが付いて、変えない限りは何回でも、同じものが使えるんですよね。
naoya: そうそう。早いんですよ。
miyagawa: たとえば普通にビルドすると2時間ぐらいかかるようなやつでも、最後のステップだけ変えたいと思ったら、変えれば、最後のステップの途中までは全部一瞬でできて。そのコンテナのキャッシュがあればですけど。それが、速くていいなと思ったんですよね。
naoya: あれっていわゆるAUFSがキーになってるんですよね。
miyagawa: そうなんですよ。たぶんコンテナ自体は、実際にファイルとして保存されていて、そこがLXCとかAUFSのいいところだと思うんですけど。実際に、dotCloudで、たとえばぼくが入った日に、Perl対応のイメージ……イメージって呼んでいたんですけど、コンテナを作ろうって言ったら、まずnginxが入ってるイメージをforkして、forkというのはブランチを作って、Mercurialを使っていたので、実際にブランチを作って、そこにPerlblewを入れてPerlのバージョンを幾つか入れて。それを一個一個のコマンド・ステップごとにMercurialでコミットして、それをデプロイして、ビルドサーバーに全部コピーして、そのハッシュ、マーキュリアルのコミット・ハッシュを指定して、ダウンロードして、デプロイするっていう感じだったんですよ。Docker自体は、中ではバージョン・コントロール・ツールを自分で書いているみたいな感じなんですけど、まあ本当にGitみたいな感じなんですよね。
naoya: そう、だからたぶんGitって、コミットの、差分の数珠つなぎで内部的には持っていて、それを先頭から再生していくと任意の時点まで再生できる、みたいな感じじゃないですか。それとけっこう似ていて。OSの状態を、特定のそのコマンドを発行したところまで戻して、そこから分岐させる、とかいうのがDockerはできてて。けっこうあれは面白いですよね。
miyagawa: そうそう。レジストリとかいうのがあって、そこにGitHubみたいな感じでプッシュできるんですけど、あれがもうちょっとたぶん良くなって、GitHubみたいにいろんなフォークができて、そのグラフがちゃんと見れて、このイメージの上に誰それの何とかをマージする、みたいな感じにできるともっとカッコいいんですけど。今はたぶんそういうのはちょっとできない。
naoya: マージはまだできないんですよね、さすがに。
miyagawa: 一応でも、取ってきてビルドすることはできるから、AっていうDockerfileとBっていうのとCっていうのがあったら、順番にビルド、ビルド、ビルド……ってやれば、たぶんそれが再現された状態はできると思うんですけどね。
naoya: ビルドの途中に他の変更を差し込んで、マージして、みたいなのはさすがに難しいか。
miyagawa: 今の仕様だと、どこから枝分かれするかっていうのがDockerfileに書かれちゃってるから、難しそうな感じがします。
naoya: まあでもね、その辺が発展していくと、かなり未来感がありますね。
miyagawa: そうなんですよ。ぼくは、一応初日というか、2日ぐらいに遊んで作ったのは、Perlのメジャー・バージョンの安定版を初期状態でインストールして、plenvっていうスクリプトで起動できる状態のスナップショットを作るためのビルドファイルっていうのを作って。これけっこう、ちゃんとビルドすると1時間ぐらいかかっちゃうんだけど。本当は(Dockerレポジトリに)プッシュしようかなと思ったんですけど、イメージが1GBぐらいあるんですよ。だから、1GBプッシュしてもいいのかなと思って、聞いたらいいよって言ってたんだけど、ちょっと回線的にもあれだし、失敗したときにまたプッシュし直すのもめんどくさいなと思って、レシピファイルだけ、Dockerfileだけ公開しておけばいいやと思って(やらなかった)。
これをやると何がいいかと言うと、ぼくはCPANのモジュールとかいっぱい書いていて、なんとかのバージョンだけエラーが出るとかいったら、だいたいPerlbrewとかplenvとかを使って、このバージョンではこう動くっていうのができるんですけど、素の状態のPerlを作るってけっこう難しくて。だいたいPerlbrew入れて、plenv入れて……って、なんか使うモジュール全部入れちゃうじゃないですか。
naoya: うん、うん。
miyagawa: で、TravisCIっていう、CIツールをホストしてくれているサービスもあるんですけど、これも、素のPerlじゃなくてけっこういろんなモジュールが入ってるんですよね。ビルドを早くするために。だから、素の状態じゃないと再現しないバグっていうのがけっこうあって。依存が足りないとか。それを再現するのが難しいなって思ってたときに、Dockerでそれができる。
もうスクリプト一発で、たとえばPerl5.8.7のインストール状態からPlackをインストールしたらどういうふうになるか、っていうのが全部できて。今までもたぶん、Perlbrewとか使って、素のPerlをダウンロードしてきてビルドし直して、とかやればできたんですけど、すごい時間かかるし。そういうのがね、スナップショットがバッとできて、一瞬で立ち上がるのはすごいいいなと思ったんですよね。
naoya: そうなんですよ。だから、Vagrantでテストしてた時は、というかまだしてるんですけど、Sinatraの環境をとりあえず動かすまでを毎回再生しなきゃいけなくて。そうするとね、そこまで時間かかるんですよね。とくに、最近だとrbenv使っているから、Rubyを毎回ビルドしてて、みたいな。そこでDockerを使うと、Rubyのビルドは終わってて、Sinatraも入ってて、あとは自分のアプリだけをデプロイすればテストできるっていう状態から再生できるから、テストがオンタイムになるじゃないですか。そうするとね、今までだと、JenkinsでCIでしかそういうインテグレーション・テストを回してなかったのを、ガードとかで保存した瞬間に、そのテストも一緒に流しちゃって、結果をすぐ見るみたいな、そういうインテグレーション・テストの仕方が出来るから、ユニット・テストしか手元で実行してなかったのが、インテグレーション・テストも含めて実行できるようになるかもしれないですね。
miyagawa: でもVagrantでも、たとえばRubyとかrbenvをインストールした状態のスナップショットをとることは、技術的にはできますよね。
naoya: できますよ。vagrant packageっていうのでできるけど……どうなんだろうな。そこまでカジュアルじゃないので。
miyagawa: けっこう面倒くさい？
naoya: 面倒くさくはないけど、結局Vagrantの起動の時間も時間に入っちゃうので、そうするとオンタイムにはどうしてもならなくて、少しバッチ処理みたいな、待ってなきゃ、みたいな感じになっちゃうから、そこも含めてカット出来ているのがDockerのいいところと、あとはそういうその、Dockerfileで、ひな形というかコンテナを調整しまくれる、というのがけっこう大きくて。Vagrantだと、スナップショットを毎回とって、それを自分で名前つけて管理して、とか。全部手動でやらなきゃいけないので。
miyagawa: Vagrantfileでパッケージをとることまで自動化はできないですかね。
naoya: たぶん、ちょっとぼくはそこまでやってないからわからないんですけど、vagrant packageっていうコマンドを打つと、スナップショット・ファイルがどこかに吐かれて、ぐらいの。だから、AWSでEC2のスナップショットをとるとか、そういう感じなんですよ。Dockerの場合はそうじゃなくて、全部そこの管理システムも含めて提供されてるじゃないですか。コマンド体系として。そこがけっこう、レイヤーが少し、Dockerの方が上ですね。
18:30
naoya: その起動が早くて、テストで、という文脈でmizzyさんに聞きたいなと思ってたんですけど。mizzyさんはserverspec… serverspecっていうのはmizzyさんが作ってる、サーバのテストをするフレームワークなんですけど、それでLXCでテストをしてるって資料に書いてあったじゃないですか。
mizzy: はい、してますね。
naoya: あの場合っていうのは、Dockerとかじゃなくて、やっぱりLXCなんで、やっぱりテストは、そうやってすぐ起動してテストしてる感じだったんですか。
mizzy: 基本的にはまだ、テストのたびに作り直すっていうことはやってなくて。
naoya: ああ、そうなんですね。
mizzy: まだそこまではやれていないですね。AUFSとか使えばその辺もできるかな、とは思ってはいたんですけど、なにせペパボで使ってるメインのホストOSがCentOSだったりするので。で、CentOSって、5系はAUFSのパッケージは用意されているんですけど、6系はないんですよね。なので、AUFSを使うのがすごく大変だっていうところもあって、まだそこまでやれてないなっていうところなんですけど、まあDockerの使い勝手とか、まだ、じつは昨日ポッドキャストに誘われて、昨日夜に帰ってきてから触り始めたところなんですけど、ここまでそれが簡単にできるとなると、ホストOSの慣れてないものの違いを超えても使う価値はあるかなあ、と思って触り始めたところですね。
naoya: 逆にぼくはLSXは生で、ちゃんと自分で設定して、とかやったことないんですけど、けっこう面倒くさいんですか。
mizzy: そうですねえ……いや、面倒くさくもないかなあ……まあ、たぶん慣れの問題なので、ぼくも慣れちゃってるので今はめんどくさく感じなくなっているのかもしれないですけど、やっぱりイメージのファイルを用意して、そこをマウントするように設定して、とか。あとはネットワークがらみもちょっと特殊な感じというか、こっちの事情に合わせた感じにしているので、ブリッジ作ってそこに繋げる、みたいなことをやっていたりとか。やっぱりある程度知識がないと難しいかなっていうのはありますね。
naoya: なるほど。その辺って全部プログラマブルになっているんですか。
mizzy: 作るところは、Puppetのマニフェストは作りました。
naoya: あ、でもそういう感じなんですね。他のツールで、自動化する、と。
mizzy: なので最初のイメージを作るところは、yumの、インストールでルートを指定して全部コアパッケージを入れて、とか。で、そこをマウントして、みたいなのとか。で、ブリッジ作ってそこを繋げて、みたいなところを……で、LXC立ち上げて、それをMonitで設定入れておいて、ちゃんと上がっているか見ておく、みたいなのを全部Puppetで作った、みたいな感じですね。
naoya: なるほど、なるほど。
mizzy: で、まあDockerはそれを洗練してやれるようにしたものなんだろうな、というイメージを持っています。
naoya: そういう感じだと思いますね。そこにさっきのその、AUFSの差分管理の仕組みが入って、全体として一個の形になっているという。
mizzy: はい。なので、すごいカッコいいな、という感じですね。こっちから言うと。
miyagawa: でもDockerはさっき新しいリリースが出ていて、一応リリース・アナウンスメントには、XFSとかBTRFSとかにも対応した、的なことがちょろっと書いてありましたけどね。
mizzy: ほう、ほう。
miyagawa: まあ一応、AUFS専門として、公式にサポートしているのはUbuntuの12とか13とかで、AUFSってなるんでしょうけど、一応コミュニティでは、AUFS以外にも対応するっていう感じでやってるみたいですね。
21:55
miyagawa: Serverspecの話が出たので、ちょっと戻るんですけど、Serverspec自体っていうのは、mizzyさんが開発するきっかけっていうのは、監視フレームワークとか、テスト、監視、ChefとかPuppetとかのマニフェストとかをテストする仕組みっていろいろあったと思うんですけど、それじゃ足りない感じがあったんですかね。
mizzy: 足りないというよりも、既存のものは逆に機能が多すぎるなっていうのがあったんですよね。もっとシンプルなものが欲しかったなっていうのがあったりとか。あとは既存の今の、ChefとかPuppetまわりの関連のテストツールって、それに依存したものがほとんどなので、それに依存していないものが欲しかったっていうのがありますね。
naoya: そうそう。結局やってるのが、やりたいことはインテグレーションテストというか、プロビジョニングが終わった後の、サーバが実際に正しいかどうかっていうのをテストしたいのに、それがChefとかPuppetに依存したテストツールになっちゃってると、テストするためにChefとかPuppetが動かなきゃいけないみたいな、よくわからない状況になったりとか。あるいはその、Chefをやめて、他のプロビジョニングツールに移動したいっていうときに、書いたテストが流用できないじゃないですか。serverspecはその辺の問題を解決してくれる、っていう感じですよね。
mizzy: そうですね。あとは既存ツールはわりと、VagrantとかEC2API叩いたりとかして、テスト用のVM作るとか、そういうところもやってくれて、それもすごい便利っちゃ便利なんですけど、ぼくのニーズだとそこまでは要らないというか。すでにあるものに対してやりたかった、というのもあるので。なるべく余分な機能を削ぎ落した物を作りたかった、というところですね。
miyagawa: まあ、Chefとかで書いたレシピを、Chef用のテストツールでテストしてもあまり意味が無いというのもありますよね。
naoya: そうそう、そうなんですよ（笑）。
mizzy: あります、あります。
miyagawa: そのライブラリのテストをしているようなものですからね。
naoya: あとはなんかね、人によってはそもそもChefとかPuppetっていうのがテストみたいなものなので、レシピっていうのが。暗黙知を形式的にコードで書いているから。だから、サーバーのテストって本当に必要なのか？ っていう人たちもいるんですけど、実際には、ChefとかPuppetって動かすと、その後、絶対みんなsshして、ちゃんと動いているかなって、自分で目視で確認してるじゃないですか。
mizzy: はい、やりますね。
naoya: そこのプロセスの部分が、じつはぽっかり空いてたんですよね。結局だから、Chefとか使ってるのに、全部終わった後に目で確認してる、みたいなフェーズがあって。で、serverspecはその辺だけをやってくれるから。ちょうどその隙間の部分だけをやってくれていると。他のテストツールは余計な部分まで全部やってくれちゃって、本当にやりたいのは、最後のその目視で確認しているところだけを自動化できればいいのに、っていう感じだったんですよね。
mizzy: そうですね、まさにシェルコマンドを裏で叩いているので、本当に手でシェルコマンドを叩いて目視で確認していたところを、RSpec記法で書いて走らせられるようにしたっていう、言ってみればそれだけのツールですね。
miyagawa: まあでも、そういうツールとして、RSpecの上に乗っていることによって、いろんな他のRSpecのモジュールと組み合わせられたりとか、Jenkinsから使えたりとか、そういう、繋げやすくなるっていうのはありますよね。
mizzy: その辺もとくに、最初から意識していたわけでもないんですけど、RSpec使ってたのは、元々、先ほどから話が出ているスケールの、LXCのコンテナの部分をテストするために、直也さんの弟さんがそこを担当してくれていて。（笑）
そこのテストはRSpecで書いていたんですね。で、それがすごくカッコいいなって思って、真似させてもらったっていうところですね。そのテスト自体はローカルで実行するので、たとえばファイルが存在するかどうか、っていうのはRubyのファイル・オブジェクト、ファイルクラスを使ったりしてテストしていたんですけども、serverspecはそこをもっと汎用的にするために、シェルコマンドを叩くようにしたりとか、といった汎用化っていうのをちょっと加えてgemにした、っていうのがserverspec。という経緯があったりします。
miyagawa: ぼくはserverspecを使ったことはないんですが、じゃあRubyで書いたものを実行すると、対象となるサーバに合ったかたちでシェルスクリプトがわーって吐かれて、それをsshで入って実行するっていう感じですか。
mizzy: はい、まさにそんな感じですね。
miyagawa: 仕組みとしてはCapistranoに似ているというか、そういう感じですかね。
mizzy: そうですね、はい。
naoya: だからserverspecの実装がフレームワークになっていて、OSごとに共通している部分のコードと、その差分のコードってあるじゃないですか、これはUbuntuに特化しているとか。そういうのが、ちゃんとディレクトリで切り分けられていて、差分だけ書けばいいよっていう風になってて。けっこうGentooとかは、ええと、なにさんでしたっけ……。
mizzy: matsuuさんですね。
naoya: そうそう、Gentoo厨の（笑）。そういう人が書いてくれたりして。そういう得意な人にちゃんと任せるような構成に内部がなっているのがけっこういいですよね。
miyagawa: あんまりOSに特化した処理がガンガン入ってくると、そこを、そもそもテストしなきゃいけなくなって、けっこう本末転倒になりそうですけどね。
mizzy: そうですね。そこは悩ましくなりそうなんですけど、ただOS得意なところは、そのOS使ってる人に任せちゃおうっていうスタンスでやっていて。serverspecの方では、裏側で吐くコマンドがちゃんと出来ているかどうか、とか。それぐらいしかテストしていない感じですね。で、実際にはRSpecの記法で、コマンドを生で書くわけではないので、たとえばサービスが動いているかどうかであれば、サービスが「should be running」とか書いてて、それに合ったそれぞれのOSのコマンドを裏で吐いてるみたいな、そういう形になっています。
miyagawa: 使い方はいろいろあると思うんですけど、最近直也さんがブログとかでよく書いてるのは、Chefとか、Puppetとかでもいいんですけど、そういうので、プロビジョニングの自分の設定を書く前に、まあ後でもいいんですけど、serverspecでテストを書いて、TDDみたいなかたちで、自分が書いていたレシピがちゃんと動いているかどうかを、実際にサーバを立ち上げた瞬間にもうすでにそれがわかるっていう、そういう使い方ですよね。
naoya: そうですね。それをさらにJenkinsとかで流して、つねに自分のレシピが正しく動いていることを保証したい、っていう感じですね。
miyagawa: あとはでも、元の考え方がそうなのかもしれないですけど、普通にモニタリングツールとして使うっていう使い方もあるんですよね。
mizzy: そうですね。元々想定して作ったわけではないんですけど、そういう使い方もできるし、やろうとしている人もいますし、実際にもうやっている人もいるかもしれないですね。
miyagawa: ただその場合はたぶん、Monitとか、Nagiosとか、そういうのと組み合わせる方が本当はいいんですかね？
mizzy: たしかに通知まわりとか、そういうのが全然ないので、実際のモニタリングとなると、通知とかそういうのも大事になってくると思うので、そこをどうするかっていうのも、まあ課題ですかね。あとは並列実行するようにはなっていないので、何百台、何千台とかサーバがあるところではちょっと使えないので、そこは今後の一番大きな課題かなっていうふうには思っています。
miyagawa: でも、それもRSpecを使っているから、RSpecをたとえば並列実行するものと組み合わせたりとか、Rspecの結果を通知するための、たとえばJenkinsを使っているならJenkinsで通知するプラグインなんて山ほどあるわけだし、あまりserverspec側でそこまでやる必要もないような気もしますけどね。
mizzy: そうですね、その辺をうまく使えればいいなとは思ってるんですけど、sshまわりでその辺がうまくハンドリングされるのかがちょっと不安なところで、まだ実際に試してみないとっていうところもあるんですけど、sshがnet-ssh使ってるんですけど、あれがイベント・ドリブンになっているみたいなので、その辺りが並列すると混ざったりするのかな、っていう不安はちょっとあったりはしますね。ただ、そこは実際にやってみて、というところですね。
naoya: まあでも、疎結合というか、たんにsshして、出力を端末に返してるだけ、というのがたぶん筋が良くて。そこはあまり、変な拡張をすると、逆に既存のツールと連携しづらくなっちゃうので。serverspecの良さは残しておいたままになっているとユーザーとしては嬉しいですけどね。
mizzy: そうですね。なるべくシンプルで簡潔にするっていうのが一番気にかけているところなので、そこは今後は絶対損なわないようにしたいですね。
naoya: 最近、あれですよね。海外でも話題になり始めて……いる？
mizzy: そうですね。Food Fight Showっていう、まあChefとかそれ関連のポッドキャストで取り上げられていたりとか。
naoya: Food Fight Show（笑）。すごいですね。
mizzy: あとは『Test-Driven Infrastructure with Chef』っていう本の、第2版がまだ発売していないんですけど、そのbetaみたいなのがもう買えるようになっていて、見てみたら、serverspecのこともけっこうページ数を割いて書いてくれていたりしましたね。
naoya: その『Test-Driven Infrastructure with Chef』の話なんですけど、ぼくがそのChefのテストまわりを調べた感じだと、他のやつはほとんどまともに実行できなかったんですよね、ぶっちゃけ。ちゃんと動かないとか、使い方がよくわからない、みたいな。マニュアルどおりにやっているんだけど。serverspecは、インストールしたらすぐ簡単に動くので。意外とまだみんな、テストとかちゃんとできてないんじゃないかなって感じがするんですよね。そこに、そういうものが出てきて、で、だんだん最近はだからそうやって、海外の人にも広がり始めてる感じなので。
mizzy: そうですね。Twitterとかでもちょいちょい、言及してくれたりする方もいらっしゃったりで。
miyagawa: GitHubでプルリクエストとか来たりするんですかね？
mizzy: はい、来てますね。日本人の方が多いですけど、海外の方もちらほらと、プルリクエストしてくれますね。
naoya: 前にHacker Newsに投稿したけど、まったくポイントがつかなくて（笑）。もう一回やったら付くのかな。
miyagawa: タイミングが重要ですよね。Hacker Newsは。煽りが重要だから。
naoya: あと乗っかってくれる人がいないとね。
miyagawa: さっき話に出たTravisCIっていう、テストするVMを動かすサービスがあるんですけど、そこは全部……全部ではないかもしれないけど、作り方自体は全部GitHubで公開していて、テストするイメージ自体はChefで作れるようになっていて。ぼくはそれに、あんまり自分では動かさないでパッチとか送ってるんですね。
たとえばPerlの新しいバージョンが出たから、ってそのバージョンを入れるパッチとかを送るんですけど、実際に今週の月曜日の夜中ぐらいに、あの人たちはヨーロッパなので、なんか今日デプロイするよって言って。デプロイしたら、5.10と5.8のビルドでコケたって言われて。で、いろいろ調べてたら、Module::BuildっていうPerlのライブラリが古いとcpanmがコケるっていう問題があって。速攻で直したんですけど、そのときにそのIRCチャンネルにいたもう一人の人が、Test-KitchenっていうChefの仕組みを使っていて。これを使うとデプロイする前にちゃんと動くかどうか確認できるぜーとか言ってました。一応、さっきも言ってましたけど、ツールに特化したかたちではそういうのをできるものもあって。
naoya: そうですよね。Test-KitchenはChefの統合テストフレームワークみたいなやつなんですけど、ただTest-Kitchen自体は、中にChefのテストを走らせる仕組みを持っているわけではなくて、なんかminitestとか、他のテストフレームワークでChefをテストするんですよ。だからserverspecと組み合わせて使うこともたぶん、やろうと思えばできるんですけど。
mizzy: ああ、そうですね、先ほどの『Test-Driven Infrastructure with Chef』はまさにその話でしたね。Test-Kitchen＋serverspecっていうかたちで書いてましたね。
naoya: でもたぶん、今のTravisの人が、デプロイする前って言ってるので、使ってるのはChefスペックっていう、それこそChefを動かして、オフラインで、レシピが正しいかどうかをチェックするっていうテストをたぶんしてるんじゃないかな、と想像するけど。
miyagawa: でももうひとつは、Perlのイメージを作るCookbookが、Perl5.19から18, 16, 14, 12, 10, 8っていうふうに、順番に作っているんですね。で、Perlのビルドってけっこう時間かかるじゃないですか。だから、5.12までは上手くいくんだけど、10でコケるっていう状態だったから、それをじゃあ、ぼくがパッチ、直したよって送るときに、もう一回走らせてみて、10でコケたら面倒くさいじゃないですか、手戻りが発生するので。
その人はTest Kitchenで5.10だけビルドするっていうスペックを作って、やったら5分ぐらいで終わって、通ったかどうか確認できるから、こういう風にしたらいいんじゃない？ みたいなのが、TravisCI側のissueに上がっていて。
naoya: へえ、なるほど。
miyagawa: そういうこともやっていましたね。
naoya: だいぶね、最近はそういうサーバ構成というかプロビジョニングもテストするようになってきて。けっこう遠くまで来たなって気もしますね。（笑）
だって昔話するとね、昔はそれこそぼくって100台とか、1000台とかサーバ管理してたじゃないですか。時々あるのが、Webサーバが、全部そのマックスクライアントの値を上げたい、みたいなことがあったときに、だいたいssh100回して、書き換えとかやらなきゃいけなくて。それを5人ぐらいで手分けして、一人20台とか。で、Excelとかでマル付けてチェックして、とか。やっていたこと本当にありましたからね（笑）。10年前とか。それが今や、コマンド1発でそういうの書き換えて。しかもそれをちゃんとテストして、みたいなことができるようになって。そうそう、よくその100台とかやると、何台か設定漏れみたいなのがあって。放っておくとそういうのが原因で障害になったりするんですよ。だからそういうのが、全部自動化によってなくなっていくっていうのは、本当にラクになったなと思いますね。
36:10
miyagawa: 全然関係ない話なんですけど、Chefまわりの用語が、KitchenとかknifeとかFood Studioとか、さっき言ってたポッドキャストとか、若干ググライビリティが悪いですよね。
naoya: そうですね。あと、そもそも第三者から見て何言ってるのかさっぱりわからん、っていう。
miyagawa: 独自の用語のエコシステムが形成されていて。これはKitchenでKnifeがどうのこうの、とか言ってるからちょっとわかりづらいですよね。
naoya: 自分でやっててもわからなくなるときありますからね。あれ、これknifeだったっけ、kinfe soloだったっけ、Chefそのままだったっけな……とか。プロビジョニング・フレームワーク界隈はけっこう最近、まだ盛り上がっていて。Chefがけっこうデファクトスタンダードにはなりつつあるんですけど、Ansibleっていう、Pythonで書かれたもっとシンプルなのがあって、そっちとかも今盛り上がってますよね。
けっこうやっぱり、Puppetの不満みたいなものがあって、それをChefで解消した部分もあるんだけど、Chef自体も、ディレクトリがけっこうてんこ盛りだったりとか、そういう専門用語があったりとか、いろんなツールを組み合わせたりしなきゃいけないっていうので若干とっつきにくいじゃないですか。だからもっとシンプルでもいいっていう人たちがいて、でもシンプルだけど、ちゃんと冪等（べきとう）性がどうだとか、並列実行とか、そういうところはきっちりサポートしたい、みたいな人たちがいて。で、今そういうyet anotherな実装とかがまた出てきているので、わりと群雄割拠みたいな感じになってきてはいるんですよね。
miyagawa: ひとつのツールが人気出てくると、それがだんだんフィーチャー・クリープになっていって、どんどんプルリクエストとか、そういう仕様がどんどん複雑化していくので、それに対するアンチテーゼで、もっともっとシンプルなものが出てくるっていうのは、だいたい歴史がくり返しますよね。
naoya: そうそう。今、そういう流れがすでに見えてきて。Ansibleのサイトに行くと、まさにその、具体的にChefとは書いてないんですけど、これChefのことだよなあっていう、すごいディスってるんですよ。トップページで。あれとかこういう設定とかは要らない、とか書いてあって。
miyagawa: ぼくもこの間、まだデプロイしてないんですけど、Linodeに、cpanmのバックエンドになってるcpanmetadbっていうサイトがあって、これ用のデプロイするスクリプトをChefで書いていたんですけど。naoyaさんの本があるので、一応、こうやればいいんだよっていうのはだいたいわかるんですけど、たとえばユーザ名とかはハードコートすべきなのか、Vagrant用にJSONファイルを作って、nodeをアトリビュートに入れるのか、とかいろいろやり方があって悩ましいので、もっとシンプルになってほしいなって。だいたい、人のクックブックを見て、ああこうやるのかって、やるんですけど。そういう、選択肢が多い部分と、決めてほしいなっていう部分と、いろいろありますよね。
naoya: そうですね。結局だから、大規模な環境でも使えるっていうことが前提になっちゃってるんで、Roleとか、いろんな拡張の仕組みが乗ってるじゃないですか、Chefって。それが、かえって小規模な環境で、もう決め打ちでいいやっていうときに選択肢を広げることになっちゃって。だからこういう場合はどうしたらいいんだろうなっていうのがわからなくなる原因になっている気がしますね。
だからRailsみたいに、Convention over Configurationじゃないですけど、普通にやるときはこうやればいいんだよっていう前提があって、みたいなポリシーにまではないってない、ということが大きいのかなって思いますけどね。
miyagawa: まあ、プログラマーとかとはちょっと違って、Opsの人ってなると、いろいろ好みがさらに激しそうですからね。
naoya: たしかにね（笑）
miyagawa: こうすればいいんだって言ってみんながフォローするっていう感じでもない気がするんですよね。
naoya: あとはけっこう、レガシーなものとかたくさん抱えているので、決め打ちにしちゃうと、古いものに対応できない、みたいな問題もたぶんあるとは思うんですけど。
miyagawa: 一応宣伝というか、この番組にはよく出てくれている、エジケン(江島健太郎)が作っているsunjiというのがたぶん、それもChefに対するアンチテーゼというか、ユーザーは全部root決め打ちとか、ファイルとかも全部、デフォルトの設定ファイルに対するdiffを記述するとか、そういう感じになってて。ChefとかPuppetとかで嫌になったらこれを使え、みたいな感じのものをエジケンが作ってますね。
naoya: まあ、そういうのはたぶん今後もいろいろ出てくるでしょうね。
40:50
miyagawa: mizzyさんが良い声でずっと聴いていたいっていう(ツィートが）（笑）
mizzy: じゃあ、録音したのをくり返して聴いてくださいって感じですね（笑）
naoya: なんか、あれですよね。宮川さんいい声とか、mizzyさんいい声ってよく見ますけど。
miyagawa: 出た出た（笑） 承認欲求が。
naoya: 子供の頃はね、よく友達のお母さんから電話かかってくると、いい声してるって言われたんだけど（笑）
mizzy: 主婦受けする声なんですね。まあ、Twitterしてるのは、ほとんどエンジニアばかりなので。主婦層がいなさそうですけどね。
miyagawa: あ、naoyaさんいい声っていうツイートがきてます。
naoya: ようやく（笑）。ありがとうございます。
miyagawa: まあでも、作ってて、ツイートしたときも最初に思ったんですけど、Dockerのことを聞いたとき。けっこうVagrantとChefっていうのと、Dockerって……さっきからこの話ばかりしていますけど、けっこうかぶってきているところが多くて。とくに、Vagrantが、1.1でしたっけ、1.2でしたっけ。
naoya: 1.2ですね。
miyagawa: VirtualBoxとかだけじゃなくて、たとえばEC2とかLinodeとかの環境を作るにも使えるので、住み分け的な部分が、だんだんかぶってきてる部分が多いなあっていう感じもするんですけどね。
naoya: 今のところはVagrantは、あくまでVMの立ち上げをマネージメントするもので、Dockerはもうちょっと、だからIaaSとPaaSみたいな、レイヤーの違いがあると思うんですけど、たぶんVagrantは今後、そういうよりレイヤーの高いところまでサポートするように開発が進んでいくし、Dockerは逆に、AUFSに縛られたところを汎用的にするとかいう方向に行くから、どっかでかぶるでしょうね、その辺がね。
miyagawa: Vagrant自体にはvagrant provisionっていうコマンドがありますよね。
naoya: ありますね。あれはだから、そのChefとかPuppetとか、外部で用意したプロビジョニングツールをVagrantの中で動的に動かすというものですけどね。だからそれを使うと、Dockerfileみたいなことはできるので。だからたとえば、VagrantがそういうDockerみたいなものを下地にしたVMをサポートしたら、たぶんDockerと同じようなことができるようになるはず。
miyagawa: まあ、Dockerをテストとかの環境でサクッと動かす、という風に使うのは良い使い方だと思うんですけど、やっぱりあとは、dokkuみたいなもので、プライベートな、オレオレPaaSを作ってみたりとか、あとはJenkinsのプラグインがちょっとあるみたいで、まだあまりよく見ていないんですけど、Jenkinsのテスト環境を作るときに、ローカルでテストするところを、テストの、ファイルシステムの状態とかが、リピータブルじゃないというか。何回かやったら動くようになるとか、そういうのがけっこうあって。
Jenkins、コケたらとりあえずリスタートしておけば、もう一回やれば通るかもしれない、みたいな。そういうのがちゃんと、同じ状態から再現するためにVMを作ったりすると思うんですけど、それがすごく速く動くっていう意味でも、Docker、もしかしたら使えるかもしれないですよね。
naoya: もうちょっと、テストとかCIだけじゃなくて、実用面っていうんですかね。エンドユーザーに実際の価値を提供するみたいな部分に、なんか上手く使えないかなって思っているんですけどね、Dockerを。
miyagawa: LXC自体が、HerokuとかdotCloudとかSqaleとかでも使われている技術なので、Dockerによって、その開発とかがさらに加速するとか、オープンソースの実装がポチポチ出てくるとか、dokkuみたいに。そういう意味では、できそうですけどね。
mizzy: そうですね。スケールでもちょっとこれからDockerの中身を見て、良さそうなところはまたパクらせてもらおうかなあ、と。パクるだけじゃなくて、フィードバックとかもできればいいなと思ってますね。
miyagawa: Herokuのエンジニアの人と話したときも、まあHerokuにはDynoっていう名前のやつがあって、これはLXCのやつに名前を付けただけなんですけど、Dockerの実装は面白いっていう話をしていて。参考にできる部分もあるかもしれないって話をしていたので、そういうものはどんどん出てきそうですよね。
naoya: そうですね。昔、はてなにいたときに、今クックパッドにいるセカンドライフさんが、けっこうはてなのエンジニアは、ちょっと今までと違う文脈でWebアプリを作りたいみたいなのを、毎回Apacheのホストを設定して、Perlのサーバを用意して、とか手作業でやってたんですよ。それをシェルスクリプトかなんかでポチッとやると、内部向けのプライベートなURLを切って、Apacheの設定を書き換えてわーっとやって、アプリケーション開発者は、そのスクリプトを動かせば、自分用のサンドボックスみたいのが手に入る、みたいなのを作ってたんですよ。たぶんその、Herokuとかみたいのを社内の内部におけるようになると、そういう社内向けに作りたいサンドボックスみたいのをボコボコ立ち上げて作る、みたいのができるじゃないですか。そういうのにも、Dockerみたいのが使えるんじゃないかなとは思ってるんですけどね。
miyagawa: 対抗するのは、VMWareがやってるCloudFoundryっていうのが、オープンソースで、いろんなPaaSを作るためのフレームワークみたいなものなんですかね。でもやっぱりVMWareなので、けっこうバーチャルマシンに特化した部分もあって。一応OpenStackとかのインテグレーションもあるんですけど、ちょっとコンテナ、LXCみたいなのとは若干方向性が違ってはいるんですけどね。
mizzy: 先ほどの、その社内とか、開発環境とかでっていうのは、まさに社内Sqaleをやろう、みたいな話は上がっていて。それはぜひやりたいなっていう感じですね。
miyagawa: dankogaiさんがホストしてるLLEvalとか。あと何だろうな、コードをペーストすると結果が出るサイトとかあるじゃないですか。そういうのも、より安全な環境で提供しようと思ったときに、今までだとchroot頑張って、とか。まさにLXCを自分で設定して、とかけっこう面倒くさかったのが、EC2立ち上げてDockerインストールして、なんかゴニョゴニョってやったら、比較的安全に動かせるっていうのもあるので。
まだそこから先は、そこにリソース管理とか、プロセスを何秒idleだったらkillするとか、ネットワークは何MBまでしか使えないとか、そういう制限はたぶんその上のレイヤーになってくるので、Dockerだけでは解決しないんですけど、こういうふうにオープンソースで出てきたから、そういうのをその上に作っていくの、わりと作りやすくなったというか、ターゲットをしやすくなったと思うんですよね。
naoya: ですね。まあその、制限のところは、それこそmizzyさんがさんざん業務でやっているでしょうから。
mizzy: そうですね。そのあたりは、LXCの中で使われてる技術って、実際には、Linuxのcgroupsとnamespaceという機能が使われているんですけど、cgroupsで制限をかける機能とかもあるので、その辺りでかけたりはしていますね。
miyagawa: たぶんDockerもそういう機能も、今は公開されていないんですけど、そういう機能をどんどん出していくのか、出さないで抽象化するのかっていうのが、プロダクト・デザインとしては大事ですね。
ぼくは、競合としてdotCloudにいたときに、Herokuがすごくいいなと思ったのは、そういうファイルシステムとかOSのローレベルなものをあんまりユーザに見せないようにしていて、たとえばプロセス管理とかもprocファイルとかで抽象化したりとか、その辺の抽象化がすごくうまいなと思っていて。dotCloudはユーザーにわりと生々しいものを提供していて。sshしたければ、コンテナにsshして自分でコマンドを動かせるし。
その辺がたぶん、Dockerを出すにあたっては、想像ですけど、わりとその辺のデザインを変えて、DockerというソフトウェアのコマンドとかAPIっていうものを先に決めて、そこに対してシステム内部のものを出していく、出していかない、抽象化するしないっていうことの、選択を今やってるんじゃないかな、という気はします。
naoya: このあいだ、AWSサミットに行ったときに、HerokuとEngineYardとAmazon Beanstalkって、PaaSの比較パネルディスカッションみたいのがあったんですけど、まさに今、宮川さんが言ってたところで、けっこうパーズベンダによって、抽象化のレイヤーをどこまでやるか、とか、どこまでユーザフレンドリーにするかっていう、ポリシーが違うんですよね。
でまあ、当然そのユーザーフレンドリーにすればするほど、抽象レイヤーは高くなってるから、ちょっと低レイヤーの操作をしたいって思ったときに、よくわからない、みたいな問題が発生しますけど、一方でHerokuは本当に、ただプッシュするだけで動く、みたいな感じで。AWSの方は、AWSを使ってるので、裏側はわかるけど、Herokuほど有機的には動かない、みたいな感じになってて。まあ、用途によって、どっちがいいっていうのは適材適所ですけど、多くの場合はHeroku式ので、ほとんどの用途は済むみたいなところはあるので。PaaSごとの差はあるんだな、と思って。面白かったですけどね。
miyagawa: たぶんdotCloudが、元々Dockerを出した一番の理由は、無料のサンドボックス環境っていうのが、けっこうビジネス的にきついってところがあって。じゃあやめるとしたら、有料だけにするのか、それとも無料の環境をユーザーが作れるようにするのか、ということを考えたときに、じゃあコアのものをオープンソースで出しちゃえっていう判断がひとつあったみたいなんですよね。
naoya: なるほど。
miyagawa: だけどこれを出すことによって、たとえば、これが起こる話かはわからないけど、Herokuが、そのDockerの技術を取り入れて、Dockerfileとかのコンパチブルな環境を出したら、そういう部分で強みを出していけるっていうのはあると思うんですよね。たとえば、HerokuのBuildpackにしてもそうだし、Procfileとかも、けっこういろんな言語とかで使われだしたりしているので、そういう標準を出していくと、将来的にリードしやすくなるとか、強みとして出していけるっていうところがあって、そういうのをやっていきたくて、Dockerをオープンソースで出したと。
たぶん、リスクもけっこうあると思うんですよね。そういう、dotCloudのために作った実装とかあると思うので。そういうのも全部入ってはいると思うので。そこが、リスクはあると思うんだけど出したっていうのは、応援したいなと思いますけどね。
mizzy: dotCloudって、それ以前からも元々、全部オープンにするようなスタイルというか、そういう文化なのかなっていうのはあって。実際にSqaleで参考にさせてもらうときにも、GitHubのdotCloudさんのリポジトリを見ると、だいたい使ってる技術がわかるような状態だったので、けっこう以前からそういう感じだったのかなというイメージはありますね。
miyagawa: そう、2011年とか2012年ぐらいまでは、けっこういろんなものを、BitbucketとかGitHubで公開していたんですけど、だんだんシステムがでかくなってきて、公開……できないというよりは、しても再利用できないので、してなかった部分もけっこうあって。
mizzy: なるほど、なるほど。
miyagawa: Docker自身の、Dockerというのはイメージを作る部分とビルドをする部分というのは、今まで全部Pythonで書かれていたんですけど、それを全部一から、Pythonで一回再実装し直したものを、今はGoで書いてるんですよね。だからDocker自体は、今は全部Goになっている感じで。
naoya: そうそう。Goですね。あれはなんでGoなんですかね。
miyagawa: なんかねえ、聞いたんだけど。Pythonで書いてて、今はdotCloudの中ではPythonとnode.jsとGoらしくて。流行ってるのが。で、元々Pythonばっかりだったから、いやちょっと……気分転換に書いたって言ってましたけどね。
naoya: そんな理由（笑）。まあでも、おかげで、けっこうGoコミュニティって今、そういうエッジな人がいっぱいいるじゃないですか、アーリーアダプターの人が。だからその人たちもけっこうDocker、Dockerって言ってて。まあ、そういう効果はあるけど、なんでGoなんだろうなと思ったら、そんな理由……。
miyagawa: でもね、Goって、Cみたいなものだし、けっこうDevOpsとか、インフラの人には馴染みやすい言語だっていうのはあるみたいですね。
naoya: 低レベルAPIを操作できるけど、けっこう高級言語みたいに書ける。
miyagawa: そうそう、Javaみたいに変なレイヤーがないし、Cの生々しいAPIとかも触れるし、最後には(ネイティブに)コンパイルされるし、みたいなところで、けっこう最近はシリコンバレーとかサンフランシスコだと、Goがいいよっていう、会社をよく見ますね。
naoya: 最近、名前をよく聞くようになってきて。あとけっこう、ネットワーク・サーバまわり。本来、元々そういう用途のために書かれた言語だと思うんですけど、それをやっている人たちがGoを使ってますね。SPDYが、とか。
miyagawa: Bradfitzがね、Brad (Fitzpatrick)って、元Llivejournalで、memechacheとか書いた、元々PerlとかCのスーパーハッカーなんですけど、今はGoogleにいて、Golangをやっていてその辺がちょっと盛り上がっています。まあ、Goの話は、たぶん今から話し始めても終わらないので（笑）。もっと話したい人がいたら、ゲストに呼んで話したい感じですけどね。
54:45
miyagawa: ああ、そうそう。RSpecって、変な英語じゃないですか。変っていうか……。
naoya: shouldとか、expectとか。
miyagawa: そうそう。あれをCucumber（キューカンバー）でも、やろうと思えばできますよね、たぶん。
naoya: できますね。Cucumberで振る舞いを書いて、みたいなことをやってる人いましたね。しかも全部日本語で。
miyagawa: serverspecに対してCucumberで書けるようにすると、このサーバーの何とかっていうファイルに、何という文字が含まれているべきである、みたいなことを自然言語で書く、みたいな。
naoya: そうそう（笑）。たぶんそうでしょうね。ぼくはCucumberあまり好きじゃないので……。
miyagawa: たぶん好きだっていう人、ほとんどいないですよ（笑）
naoya: あれは何なんだろうって。
miyagawa: 良さはわかるんですよ。RSpecで長いスペックとかをリピートしていると、ああ、これ自然言語で書けたらいいのにな、って思うことはたまにあるんですけど。でも英語でね、直接テストを書いていない感が気持ち悪いんですよね。
naoya: そうそう。結局、テストのコードを読めば仕様がわかるみたいな話があるんですけど、知りたいのは仕様そのものよりも、もうちょっとコードで書かれた仕様が知りたいってことがほとんどなので、テストファイルをわざわざ開くときって。だから、Cucumberで書かれていると、かえって自然言語を読まなきゃいけなくて、かえって面倒くさい、みたいな。まあでも、そういう話じゃないのかな……。
miyagawa: Cucumberの本当にすごいやつは、テーブルとかをアスキーアートで書くじゃないですか。
naoya: ああ、そうなんだ（笑）。
miyagawa: このインプットのAとBは、AがこれでBがこれみたいのを、アスキーアートの+と-で、テーブルを作ってやってたりするんですよ。すごい、ちょっと間違った方向の努力な気がするんですけどね。
naoya: あれみたいですね、昔あった、ERツールでしたっけ。オブジェクトの関係を書いておくと、スキーマが勝手にできあがる、みたいなやつ。
miyagawa: うちの社内で今やってるのは、逆で。自然言語でテストを書くんじゃなくて、RSpecで書いたスペックを、自然言語みたいに出力して、それが仕様書になる、みたいな。そういう仕組を作っていて。autodocって言って、あとでリンク貼っておきますけど。
naoya: このあいだ、中村さんが作っていたやつ？
miyagawa: そうそう、たとえば、WebAPIのテストを書いたときに、テストに書く内容、テストでテストしている内容と、仕様書に、このエンドポイントはなんというデータを返す、とか書くのが、同じ内容を書いているじゃん、って気づいて。だからテストを更新すると、仕様書の方も更新されるっていう。まあ、RSpec自体もそういうことをやってるんですけどね、RSpecのホームページに行くと、こういうスペックファイルをやったらこういう結果が返る、みたいなメタな感じのサイトなんですけど。それにちょっと近いかな。
naoya: だんだん雑談になってきてますけど、なんか、ただぼく思うんですけど、よくメタデータをソースコードに埋め込んでおいて、そこからドキュメントを自動生成する、みたいなフレームワークはたくさんあるじゃないですか。そのときに、メタデータっていうのも、ある程度形式が決まってて、みたいなやつもあるし、CPANみたいに自由にかけるやつもあるんですけど。
なんかね、ぼくはあの自動生成系のAPIのドキュメントって、つらいんですよね、読むのが。CPANのドキュメントとかって、人が読むためにわざわざ書き起こしてるから、人によっては冗談が入っていたり、あとは強調する部分がどこかがわかりやすかったりして、自動生成ドキュメントの方が人にやさしく、ファジーな部分がけっこうあるから。なんか、そういうのはあんまり好きじゃないっていうのはあるんですよね。
miyagawa: それはたとえば、Javadocで、inputがこれで、outputがこれで、とかそういう話？
naoya: そうそう、それはインターフェイス見ればわかるんだと。でもぼくが知りたいのはそういうことじゃなくて、このクラスを使うときにはこういうところに気をつけなきゃいけない、とか。これはこういう目的のときにこういう背景があって作られたんだ、みたいな。そういうところをもっと最初に読みたいんだけど、Rubyのドキュメントとか読みに行くと、いきなりAPIがずらっと並んでて、これじゃなあ、みたいな。
miyagawa: そうなんですよね。JavadocもRdocもそうなんですけど、たぶんリファレンスとしてはよくて、まあRubyGemの場合はREADMEにけっこう、重要なことがだいたい書いてある感じで、実際のrbファイルのところには、APIドキュメントとか、メソッドのシグネチャがどうこうとか、そういうのが書いてあることが多いですよね。
ぼくもCPANのモジュールとかは、なるべくドキュメントは自動生成しないようにはしていて。自動生成されたドキュメントが混じっていると、どれが本当に重要なドキュメントなのかわからないっていうのがあるんですよね。
naoya: そうなんですよね。機械的になっちゃうんですよね。
59:30
miyagawa: なにか宣伝することはありますか？
naoya: ポロリがあるって言ったんだけど、じつはあまりないんですよね。（笑）
なんかあったかな。ちょっとなんかもう一冊、何か書きたいなと最近思い始めているんですけど、Chefほどなんと言うのかな、飢餓感があおられているものが、今のところ見つからないっていうね。Dockerの本とか書いても50人ぐらいしか読まないっていう（笑）。
miyagawa: あとは新しいものの本を書くと、すぐ廃れちゃうっていうのもあるんですよね。
naoya: そうそう。Chefもね、電子書籍だからアップデートしなきゃって思ってるんですけど、すでにVagrantが古かったりとかしてて。
miyagawa: でも、Chef自体は多少枯れてきてはいるでしょう。
naoya: そうそう。ちょうどあの本書いたときに、バージョン11が出たばっかりで、まあ11でけっこう大きくアーキテクチャが変更されたので、しばらくはないだろうっていう感じですよね。
mizzy: WEB+DBプレスの今月号が今日発売日ですかね。ペパボの人間が、第一特集で何人か書いているので、ぜひ読んで頂ければと。
miyagawa: 何の特集ですか。
mizzy: 継続的Webサービス改善ガイドという記事を、antipopさんとか、柴田さんとか、他何人かで書いてますので、ぜひぜひ、というところと。あとは直也さんの連載記事でも、serverspecのことを書いてくださっていて。さらに次号でまた詳しく書いていく感じなんですかね。
naoya: そうですね。今回はChefとVagrantを動かすところまでだったので、次の号で書こうかなと。
miyagawa: なんの連載ですか？
naoya: ぼくはなんか、テーマが決まっていなくて。そのときその時で、ちょっと面白いテクノロジーを紹介します、という。WEB+DBプレスの連載なんですけど。ペパボのやつ、面白かったです。読みましたけど。
mizzy: ありがとうございます。って、ぼくが書いたんじゃないですけど（笑）
naoya: でもなんか、今日の話ともけっこう近いところがあって。どうやってそういう、手動で管理していたサーバーとかを自動化したりとか、定量化して、技術的負債を増やさないようにしていくか、みたいなことが書いてあって。たぶん、そういうので悩んでる会社はむちゃくちゃあるから。
mizzy: そうですね。antipopさんと柴田さんは、どちらかと言うと開発サービス寄りなんですけど、Opsの方で、黒田さんと常松くんって二人が書いてくれているので、そっちのレイヤーの話もあったりして。けっこう幅広く書かれていますね。
miyagawa: なるほど。じゃあ、WEB+DBプレスにはリンクを、アサマシ付きで貼っておきます（笑）
naoya: まあ、WEB+DBが売れてもぼくらはべつに……って感じですけどね。稲尾さんが喜ぶ（笑）
miyagawa: 稲尾さんが喜ぶ。
Transcribed by Hiroaki Kadomatsu http://d.hatena.ne.jp/note103