JTF2014「Serverspecに見る技術トレンドを生み出すヒント」の聴講メモ #techfesta

JTF2014 最初のセッションは Serverspec Operations 宮下剛輔 (id:MIZZY) 氏の「Serverspecに見る技術トレンドを生み出すヒント」。宮下さんの講演は今年のデブサミ以来 (デブサミ2014 「サーバプロビジョニングのこれまでとこれから」のメモ #devsumi - べにやまぶろぐ) でしたが、その間にペパボを退職され、肩書きがフリーランスエンジニア (Serverspec Operations が屋号）になられていました。

テスト駆動インフラや Immutable Infrastructure といった話を体系的にお話しされたデブサミとはまた違った内容で、Serverspec 誕生の歴史・裏話？など興味深く聞かせていただきました。

個人的に響いたこと

"ServerSpec" や "Server Spec" という表記は誤りで、"Serverspec", "serverspec", "SERVERSPEC" が正しいスペル（表記がまちまちなのでもやっとしてました）
Serverspec を使ったセキュリティチェック : ミドルの設定など新しく立てたサーバー・サービスが自社のガイドラインに準拠できているか確認する用途にも使えるかも
人類の技術発展のための無償開発という考え方では良いものは作れない（自分が使いたいものを作るという理解で正しいでしょうか）
Shut the fuck up and write some code （今のプロジェクトにはこれも欠けている）

講演メモ

インフラ（OS からミドルまで）系技術のトレンド
- Chef 人気、US では 2014 年になってようやく Puppet のシェアを超えたらしい
- 大企業向けで複雑な Chef/Puppet のカウンターとしてライトに使いやすい Ansible も普及
- テスト駆動インフラとインフラ CI (Test Kitchen, Serverspec など)
- Immutable Infrastructure => WEB DB PRESS Vol.81 （先行発売中）
  - Vol.80 ではテスト駆動インフラ特集
テスト駆動インフラとインフラ CI
- DeNA の@riywo さんが 2012年にインフラCIについて言及
- 宮下さんの中でも 2007 年には構想があった(テスト駆動サーバ構築)
Serverspec
- RSpec でサーバの状態をテスト、本質的には『サーバの状態を記述したコードをテスト』するもの
- ServerSpec や Server Spec は誤りで Serverspec, serverspec, SERVERSPEC が正しいスペル (RSpec と Server の組み合わせであるため)
テストツール開発のきっかけ
- Excel チェックシートでの目視確認はやめたいと思い、 Assurer というサーバテストフレームワークを Perl で 2007 年に作っていたが広まらなかった
  - Serverspec と違って振る舞いをテストするため、状態をテストするより複雑になった
  - フェーズ分け・プラガブル・分散処理・シェルと複雑になりすぎた
  - コンセプトが曖昧になり、自分でも使わなくなった
- しばらくたって自分で書いた Puppet マニュフェストがレガシーになってしまっためリファクタリングしたくなった => テストが必要になった
  - LXC コンテナでテストするためにコンテナをさくっとつくれる Puppet マニュフェストを書いたが、Docker がちょうど同じタイミングで出てきたので無用な長物になった
  - テスト用ツールは rspec-puppet くらいしか Puppet で使えるものはなさそうで Chef の方が充実していた
    - rspec-puppet はモジュール化されているマニフェストしかテストできなくて自分ものには使えなかった
    - また実際のサーバをテストするわけではなくプロビジョニングの処理過程をテストするためツール依存になってしまい嫌だった
- 同僚だった @hiboma さんが LXC のコンテナをテストするコードを RSpec で書いていたのでそれを拡張した
- さらに拡張性を高くするため Serverspec は現在 2.0 に向けて鋭意リファクタリング・拡張中
Serverspec の認知度
- Black Duck Open Source Rookies of the Year 2013 (Docker/InfluxDB/Appium などと並んで受賞)
- rubygems.org で30万DL、Chef は400万DL
- WEB+DB PRESS 75/76/80/81 やその他いろいろな書籍で言及されている
なぜ Serverspec は成功したのか？
- 別領域で成功しているプラクティスを持ち込んだ
  - TDD/CI といったソフトウェア開発の世界のプラクティスを踏襲してテスト駆動インフラ/インフラCI というようにコンセプトを表現
- わかりやすい名前 : Server + RSpec という直球のネーミング
- 英語のドキュメントは世界的に認知してもらうのには必須、README や serverspec.org などは最初から英語で書いた
- メジャーなキーワードやプロダクトに乗っかる (Puppet/Chef といったワードをちりばめることで Puppet/Chef 界隈の人に拾ってもらえた)
- 斜め読みしてもすぐにわかるドキュメント
- ツールそのものもシンプルでわかりやすいものにする
  - 構成管理ツールとの連携や VM 操作などは省いた
  - とはいえいろいろなユースシーンに対応する必要はあるので、拡張しやすいように作る
  - KISS の原則 : Keep it simple, stupid
- インフラに余計なものを入れるのはすごく嫌なのでエージェントレスであることにこだわっている
  - テスト実行するマシンには Ruby さえあればよい
  - テスト対象マシンには SSH で入れればそれでよい
- 使うまでの敷居を下げるため、Ruby 1.8.7 以降をサポートしている => Redhat 向け
- 自分一人でやり過ぎない
  - 自分で使う機能しか基本的に実装しない
  - (OSS なので) 欲しい機能は個々の開発者に実装してもらう
- 技術トレンドに乗った
  - Puppet から９年、Chef から５年たったのでみんなが次のことを考え始めた (元々テストに対して意識の高かった Chef 界隈の人に拾ってもらえた)
  - Vagrant が普及したので手元でテストを回すことができ始めた
  - Jenkins/CI/GitHub Flow といったツールや仕組みが普及してきた
  - 仮想化・構成管理・CI についての定番がなかったところにうまくはまった
とはいえ技術トレンドを生むとか考えないで自分が欲しいもの、おもしろいと思うものを自分のために作る
- 人類の技術発展のための無償開発という考え方では良いものは作れない
- 自分がほしいもの、おもしろいと思うものを作って公開、その積み重ねがすばらしいものを生むことにつながるはず
好きな言葉
- Shut the fuck up and write some code
- Openness is our driver for excellence
- 楽しんだものが強い（孔子の言葉）