Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』

著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。

Serverspec

さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。

Serverspec誕生の頃

約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけてる設計があるのではないかと、議論を重ねていたのだった。その結果としての設計は、僕の『入門Puppet - Automate Your Infrastructure』にも反映されているが、それはあと数ヶ月先の話。ある程度設計が固まり、さてその方針で既存のPuppetマニフェストをリファクタリングしなければ、という時に、mizzyさんがあっという間にServerspecを作り上げ、公開した。

構築したサーバをRSpecでテストするという発想は筆者オリジナルのものではありません。前職時代の同僚であるhiboma氏が、LXCによるコンテナにChefレシピを適用したあとに行うテストをRSpecで書いていて、それを真似させてもらいました。Serverspecの初期プロトタイプも彼のコードからのコピペが多く、一日、というよりも数時間で完成しています。そして次の一日で、より汎用的に使えるようにブラッシュアップして、Serverspecという名前をつけてRubyGems.orgで公開しました。それが2013年3月24日です。

(pp.2-3)

本書でも「もともとは、筆者が当時書いたPuppetマニフェストをリファクタリングするためのテストツールとして開発」(p.5)したとある通り、我々のPuppetマニフェスト書きにとって大いに役立ったのはもちろん、本書でも利用目的として紹介されている、著者が必ずしもそのように使われることをあらかじめ意図していたわけではない、下記に示す多様な用途に、リリース直後からすぐに使われ始め、あっという間に広まった。

1. テスト駆動開発によるインフラコード開発
2. サーバ構築後の確認作業の自動化
3. 稼働しているサーバの監視
4. サーバ再起動後の状態確認
5. サーバのあるべき状態の抽象化

(p.5)

まさに、僕が「代表的プロダクト」と呼ぶものを、ほとんど一瞬にして作り上げたのを目の当たりにして、感嘆したのだった(そのあたりについては、「代表的プロダクト」についてというエントリに書いた。また、mizzyさんには他にも「代表的プロダクト」と呼べるものが既にあれこれあるわけだが)。もちろん、著者のインフラに関する経験や、「インフラをコードし、それをテストする」という熟成されたコンセプトが時機を得て花開いた、という、長年の蓄積あってのことなわけだけれども。

あるOSSの文化事例

そのような著者が、「思いを綴ったエッセイ」でもある本書は、Serverspecのユーザにとってもコントリビュータ(候補)にとっても「実用書」としておおいに有用であるのはもちろんのこと、広く使われているOSSについてその作者がどのような考えをもって開発してきたか、今後するつもりかということを記した、OSSに関する文化的な書物としても面白い。たとえばこんな調子だ。

Serverspecというツールの存在意義がある限りは、長く継続的にメンテナンスを行っていきたいと筆者は考えていますが、それを阻害する一番の要因はServerspec開発に対するモチベーションの低下です。特に、自分のためではなく、他人(特に意見を言うだけでコードで貢献しない人)のために開発を行うことが、最もモチベーションをすり減らす要因となります。

(p.12)

と述べた後、いくつかの方針を述べている。

• 自分で使わない機能は、自分では実装しない
• プルリクエストを送ってきた場合は、自分が使わなくても取り込む
• ただし、Serverspecの基本方針にそわない機能は取り込まない
• Rubyがまったく書けないひとのためには開発しない
• 自分が困ってないバグは、困るひとが直すべき
• コードの添付されない単なるバグレポートはいらない

「Serverspecの究極の目標」(p.16)が「『システムの継続的改善』に寄与すること」(同)であるように、Serverspecそのものの「継続的改善」のために著者が極めて明確なポリシを持ち、その通りの言動を貫いているのは、まったくもってmizzyさんらしいストイックさだなあとあらためて感心するとともに、ひとりのOSS開発者のあり方を述べた文章として、貴重だ。

一方で、単なる口先だけの意見ではなく、コードによってコントリビュートしようという気概の持ち主に対しては、著者は優しい。

仮に他のOSに対応できそうな拡張であっても、自身で利用していないOSに無理に対応する必要はありません。また、動作確認する必要もありません。筆者も基本的には自分がよく使うOS以外については、対応や動作確認はしないというスタンスでやっています。そのOSを使う人が自分で対応したり動作確認をすればよいという考えです。

(pp.115-116)

と、コントリビュータに対しても、自身へのそれと同様、公正にポリシを適用しつつ、プルリクエストの送り方について丁寧に述べ、「とはいえ、筆者はそれほど作法にうるさくありませんので、お気軽にプルリクエストを送ってください」(p.116)と呼びかける。Rebuild: 75: Book Driven Development (gosukenator)では、「コードの直し方は自分が一番知っているから、下手にコード書くより問題だけ指摘してほしい」というひともいるという話もあったが、いずれにせよ、これもまた、あるひとつのOSS開発の文化を端的に示す「エッセイ」として秀逸なエピソードである。

また、実際に本書を読むとすぐに気づくと思われるが、コントリビュートしてくれたひとのことをよく憶えていて、かつ、本書では重要な契機となった改善について、きちんと名前を挙げて紹介しているのも著者らしいなと、僕などは思わされるところだ。さらには、名前を挙げる際には、(確実に意図があって)必ず註釈の中でGitHubのURLを添えるというのも、まさにmizzyさんらしい細部でもある。ちなみに、僕自身の名前も、ある箇所で紹介していただいていてる(内容はコードのことではなくて恥ずかしいのだが。また、最近ちょっと別のことに打ち込んでいたせいでGitHubのコントリビューションが壊滅しているのも厳しい……)。

ServerspecとUNIX哲学

そうした「文化的」側面を伝える記述の他にも、「3.12 テストコードの指針」において述べられる考えにも、mizzyさんらしさはよく現れている。たとえば、Nginxのインストール状態を、バージョンをも指定してテストするべきか述べる場面で、

もし、「Puppetが正しく動作するか不安なので、指定のパッケージが指定のバージョンできちんとインストールされているかテストしたい」という考えでこのテストコードを書くとしたら、それはナンセンスです。そこが信頼できないのであれば、そのツールの使用はやめるべきです。

(p.58)

と書いたあと、続けて、

「Puppetマニフェストを書く人がパッケージ名を間違えたり、記述を削除したりするかもしれない」「バージョンが変わると自己が起きる可能性があるため、誤ってバージョンを書き換えたり、勝手にアップデートされたりしないようにしておきたい」という理由でしたら、このテストコードに大いに意味があります。

(同)

と述べるのは、短いパッセージでありながら「テスト」というもののあり方に対する著者の考えを示しつつ、極めて啓発的な文章になっている。同じ主題は、「5.4 サーバ構成管理ツール」において再び変奏される。ChefのNode AttirbutesをServerspecから読めるようにしてほしいという要望に著者は否定的な考えを持っていると述べた後、

Node Attributesと連携したいということは、Node Attributesで設定されているパラメータが、Chefによって正しく設定されているかテストしたいということだと思われます。ですがそれは、Chefが正しく動作している限りにおいては、正しく設定されているはずであり、そこはChefを信頼すべきでしょう。信頼できないのであれば、Chefを使うのはやめましょう。もし正しく設定されていないとしたら、それはChefのバグです。

このような著者の考えはまた、UNIX哲学における「1つのことをうまくやる」につながるものでもあり、また、「現実のシステムの複雑さと変化に対応するために、システムのあるべき状態を簡潔に記述し、継続するためのもの」(p.16)という「究極の目標」(同)を持つ、ServerspecというOSSを開発するに際して、一連のツールチェインのひとつをなす、そしてそこにとどまり続けることこそが正しいあり方なのだということを堅持する、これもまた、著者のOSS開発に対する活きた思想を示すことでもある。

おわりに

本エントリでは、僕自身の知るmizzyさんのひととなりを思い起こしながら、文化的な側面にフォーカスして本書を紹介してみた。もちろん、本書は実用書としても、広く使われているOSSの内部実装を解説する技術書としても非常に有用なものであることは、あえていうまでもないことだ。そのあたりは、多くのひとが書くだろうので、そちらを参照してもらいたい。

僕が述べたかったのは、本書が、我々のようなOSSに対して関わりの強いソフトウェアエンジニアにとって、たとえば『ハッカーと画家』や『Joel on Software』のような、技術文化に関するエッセイのような味わいを持つ傑作であるということである。

Serverspec