Serverspec読みました

皆が待ってたServerspec本が発売されました。オライリーから電子版で購入。

実のところServerspecはずっと気にはしつつも、横目で見るだけで使いどころを決めかねていました。

自分のサーバ管理のスタイルは、

というもので、2007年のSofeware Designでmizzyさんの記事を読んでPuppetを使い始めて以来、構成管理はずっとPuppetです。

モジュールは全て自作で、年単位でメンテしているモジュール群を投入しつつ、必要なものをその都度追加していくスタンス。

Puppetサーバを起動するモデルではなく、--noopでdiffを確認してから必要な時だけマニフェストを適用しています。

適用後のサーバの挙動に問題があれば監視からアラートが上がるので、実質的にそれがサーバの受け入れテストとなっています。

現状のサーバ運用であればServerspecの必要性もあまり高くはないのですが、「マニフェストを更新するPull Requestがレビューを経てmergeされたけど実は間違っていた」みたいなこともあるので、そこをCIしたいとは思いつつ、メンテナンス対象のコードが増えることに二の足を踏んでいました。

特にテストしたい部分としてはNagios等の監視ではカバー出来ない部分、例えば

といった細かいものが多かったのも難しい部分です。

ここにServerspecを投入するのも本筋ではないよなぁなどと考えながらずるずると今日まで過ごしていました。

ところが、こうした事情がdockerによって大きく変わりつつあり、いよいよ自分にとってのServerspecの必要性が一気に高まってきました。

PuppetやChefなどの構成管理ツールは、そもそもが「サーバのあるべき状態」を定義するためのもので、安定した土台の上で生きていく分にはServerspecの恩恵はそこまで大きくないでしょう。そこは本書にもある通りです。

一方でDockerfileは通常のシェルスクリプトのように「何をするか」を記述していくため、それらよりも簡単に扱える反面、定義的に書くものではありません。

いくらシンプルなコンテナであっても、そのコンテナが正しく動作することに自信を持つのは難しくなってきます。

「dockerコンテナを本番環境に投入するのにインフラをCIしないのは、テストコードを書かないのと同じ」と言い切ってもいいかもしれません。

というわけで、今年は積極的にインフラのCIを回していく所存です。

また、本書は周辺情報も豊富です。中でもNagiosとの連携は個人的に非常に可能性を感じました。

Nagiosは台数や監視項目が増えてくると、ひとつの障害で多数のアラートが飛ぶ状況に陥りがちです。

現在はそれを回避するためにcheck_multiを利用して、複数のコマンドをひとつの監視項目にまとめています。

例えば、Webアプリケーションの監視は

という監視を個別に登録すると、このアプリケーションを起点とするアラートが2つ上がる場合がありますが、check_multiを使うことでこの通知を集約できます。

check_multiの難点としては、コマンドそのものが複雑化するため、監視が正常に回っていることに自信を持ちづらいというものがあります。

ここをServerspecに置き換えることで、開発段階からサーバ設定とテスト内容を両輪で育てていく体制が作れるのではないかと目論んでいます。

Pythonのfabricと連携するenvassertも本書で知りました。

本番環境のオペレーションにはfabricを使っていますが、開発時には使っていないので自分の環境に合うかは分かりませんが、こちらも興味深いプロダクトです。

他にも本書の大きなポイントは、あちこちで述べられているように、Serverspecの背景となる思想や実装の理由などが切々と語られているところにあります。

ある意味Rubyっぽくないその思想には大いに共感するとともに、そうしたスタンスでRubyと付き合うのもありなのだと本書は改めて気付かせてくれます。

全体的に非常に読みやすく、実用書としても読み物としても大いに楽しめるので、Serverspecを使う人だけでなく全てのWebエンジニアに強くおすすめしたい一冊です。

Nekoya Press