Serverspec誕生からインフラCIの今後までを開発者に聞いてみた
インフラ構築の現場で活用が広がっている国産OSS「Serverspec」をご存知でしょうか。Think ITで活用連載を執筆したTISの池田氏と、開発者であるServerspec Operationsの宮下氏のインタビューが実現したので対談形式でお届けします。Serverspecってなに? という方はぜひこちらの連載もご覧ください。
宮下:宮下です。よろしくお願いします。4月からフリーランスでソフトウェアエンジニアとして仕事をしています。個人事業主の届け出を出すと屋号を付けられるので、「Serverspec Operations」にしてみました。ただ、特にそれを前面に押し出して活動しているわけでもなく、今はクックパッドでフルタイムで仕事をしています。主にインフラ周りの業務、たとえばVagrantを導入したり以前から使っているPuppetの整備をしたりなど、あとはインフラCI※の整備をしています。
※ソフトウェア開発のCI(継続的インテグレーション)をインフラレイヤーにも適用した考え方
池田:TISの池田と申します。よろしくお願いします。私はServerspecのユーザーとしてお話させていただきます。使い始めたきっかけは、Twitterのタイムラインでよく見かけるようになって面白そうだなと思う程度だったのですが、今は仕事でも使用するようになってきています。私たちTISはいわゆるSIerで、お客様にシステムを納品してそれを運用したりしています。その中でより早くより安定したシステムを提供できるように日夜取り組んでいます。私たちが所属する戦略技術センターという本部系の部署では、実際にお客様とやりとりするのはすごく少ないです。ただし、現場の事業部門に向けて、こういう新しいツールを検証して伝えるというのが、主な業務になっています。
Serverspecってどんなところで使われてるの
池田:私はServerspecを実際に使っていて、すごく便利なんですけど、実際にどんな場面で使われているんでしょうか? 社内で広めていくにしても、そういった情報があると安心して使えます。
宮下:そのあたり、実は僕もよくわからないんですよね(笑)。ツイートを見ていると結構使っている人がいるなと、あとは検索で引っかかったりプレゼン資料があったりして。ただ実際のところそれがどれくらいの規模でどこまで使われているのかというところまではなかなかわかんないです。
池田:実際に使っている方に相談されたりとか、Serverspecの導入支援をしたりとか、そういう活動もされたりしてるんでしょうか。
宮下:この前までやっていた仕事は、まさにそういう仕事でしたね。そんなに大きな規模ではないですが、とあるシステムを作る際に活用していました。そのシステムが、性質上作ったり壊したりを頻繁にやるんです。作る部分はChefを使って、そのテストをServerspecが担当しました。
池田:テスト工程を少しでも減らすためにServerspecに興味がある、という声を社内でも聞いたりするのですが、そういったServerspec単体での使い方もあるのかなと思っています。一方で、やはり効果を発揮できるのはよりたくさんのマシンを作ったり、より頻繁に作り替えたりとか、そういう場面になるのかなとも。
宮下:そうですね。もともと僕はずっとPuppet使っていて、Puppetマニフェストをリファクタリングするために作ったのがきっかけだったりします。サーバ構成管理ツールとの組み合わせが一番マッチするところだと思います。構成部分がコード化されていないのに、いきなりテストをコード化しようみたいな発想にはならないと思うんですよね。
プロジェクト誕生は”パクリ”から
池田:やっぱり自分自身の経験からこういうのが必要だ、というところからスタートしたのが大きいですよね。Serverspecを開発される前と後とでどう変わってきたのか少しご説明いただけないでしょうか。
宮下:Puppetを使い始めたのは2006年頃で、それまではほとんど手動か、すごい長いシェルスクリプトで構築している状況でした。ただ、ちょっとこのやり方はどうだろうと思い、ツールを探してPuppetを導入しました。Puppetで構築が自動化できるめどが立ったんですけれども、テストが手動なんですね。手動でエクセルのチェックシートみたいなのがあって、それに担当者が目視でコマンド入れて確認したのをチェックしていって、それにハンコを押して上司に出すみたいなことやっていました。
池田:私たちもそういう感じですね。
宮下:せっかく構築を自動化したのに、そこ(テスト)が手動なのはどうなのかなと。そこで「Assurer」というツールをPerlで作り始めました。発想としては、開発のテストみたいな感じで、サーバーインフラもテストできないかなというものです。その根底は、まさにServerspecと一緒なんですね。ただ、Assurerはやりたいことを多く詰め込みすぎて複雑になってしまい、結局はお蔵入りになってしまったんですけれども。その経験があり何かいい方法はないかなとずっと意識していました。
RSpecでサーバーのテストをやる発想は、実は僕オリジナルではなくて、前職の同僚の伊藤洋也君が考えたものです。伊藤直也さんの弟さんですね。SqaleというPaaSはLXCを利用しているんですけれども、コンテナを作るところの処理のテストをRSpecで書いていたんですね。それがすごいかっこいいなと思ってパクらせてもらいました(笑)。
池田:そのアイデアに影響されて作ったという形ですね。
宮下:そうですね。そのころ僕はマネジャー職で、あまり現場でバリバリコードを書いていませんでした。ただ、Puppetマニフェストをちょっといじる機会があって。そうすると、昔僕が書いたマニフェストをベースにしているので、すごく古臭いんですよね。それが気になり始めて、これをもっとモダンにしようと思い書き換えました。開発のリファクタリングとまったく一緒ですね、リファクタリングって絶対テストが必要じゃないですか。何かいいツールがないかなと探していたんですけれども、僕の要望にぴったりマッチするものはなかったんですよね。じゃあ、自分で作るしかないかなということで作ったのがServerspecです。
池田:自分が課題として直面したのをきっかけに、自分がほしいものをどんどん作っていくスタンスですね。
話が戻るんですけれども、最近よく言われているインフラのTDD(編注:テスト駆動開発)について、実装している部分などあれば教えてください。test-kitchenなどいろいろなツールとかあるのですが、どこまで本当に使われているのか、どういうシステムで使われているのか気になったりします。
宮下:クックパッドの同じインフラ部にいる荒井良太君が作っている「Itamae」というChefライクでシンプルなサーバー構成管理ツールがあります。それは最近クックバットでも使い始めているんですけれども、そういうのでインフラのコードを書くときには、大体僕はServerspecでテストコードを書いていますね。
池田:私もChefは最初のころ使っていたんですけれども、もっと軽くやりたいなと思ってAnsibleに手を出しています。
宮下:Ansibleはすごくよく聞きますよね。
Serverspecはエンタープライズでも使えるのか?
池田:いろいろなケースを教えていただいたのですが、SIerである私たちが担当しているようなエンタープライズ領域で使用するうえで注意したほうがいいところってあったりしますか。
宮下:僕はもともとSIerにいたんですけれども、もうWeb業界に来てから長いので疎いんです。。ただ、エンタープライズになると、やっぱりWindows対応は結構強く求められるのかなと思っています。
池田:確かにそうですね。WinRMでつないで、Power Shellコマンドを実行できるようにはなっているんですよね。基本的なテストとかであればすでに実践的に使える状況でしょうか。
宮下:割とカバーはしていると思います。実は僕はまったくノータッチでPull Requestが来たものを取り込んでいるだけなんです。実際に最近ツイートされていた方で、Windowsで納品用のサーバーのテストをやっているというツイートしていた方もいらっしゃいます。あと、いわゆるプロプライエタリなソフトウェアだと、そこのテストは難しいですよね、実際にその製品の中身がまったくわからないので。
池田:製品特有のテストだとなかなか難しそうではあります。Serverspecで対応しているのは、基本的にオープンなもの、よくあるパターンのものですね。例えばあるアプリケーションのテスト用のモジュールを取り込んでください、といったリクエストが来た場合はどうされるんでしょうか。
宮下:あんまり特殊だと多分取り込まないですね。恐らく別のGemにしても普通に動くと思います。ですので、本体に入れることはあまりしないと思います。ただ、拡張はしやすくしているつもりなので、そこは自由にできるのではないでしょうか。
池田:エンタープライズな視点だと、どうしても報告というのが求められます。一番気になるところは、本当にServerspecのテスト結果が正しいのか、というのは結構お客さんから言われそうな気がするんです。
宮下:言われます、それ。
池田:今だとどうしてもエクセルのファイルでテスト結果を残して、それをお客様に説明しに行くみたいなのがよくあるんですけれども、そのあたりって何か良い方法はないでしょうか。
宮下:実際にそういうケースのプルリクエストが来たことがあります。Serverspecのテストは失敗したときだけ実行したコマンドを出しているのですが、成功したときにも出したいという方がいました。僕は必要がないので、そのリクエストをリジェクトしたんですけれども。ただ、ベースになっているRSpecが、カスタムフォーマッターを作れるんですね。なので、そういうのをやりたい人は自分でフォーマッターを作ってくださいというそういうスタンスです。
エクセルとかで出したい場合もRubyのGemもあると思うので、そういうのを使ってフォーマッターを自作してもらえればいいかなと思っています。
池田:SIerとしてはレポーティング機能を提供できるようになるとちょっと実用に近づくかなという感じです。
宮下:僕自身は必要ないんで作りはしないんですけれども、要望しているところは結構あると思います。そういうのを作って公開とかされると、割と喜ぶ人もいるんじゃないでしょうか。
池田:Serverspec自体が柔軟な作りで、カスタマイズ性が確保されているので、自分たちがやりたいテストを自由に書けるかもしれないとは思っています。エンタープライズ領域での可能性はあるかなという気がしています。
でもやはりどうしてもネックになるのは、お客さんとの間のやりとりで、そこが一番心配なところです。それを受け入れてくれるようなお客さんであればすぐにでも使っていただけるんじゃないかなと。お客さんも一緒に巻き込んで、納得していただいてちゃんと理解していただいた上で導入を進める。そういうやりとりをちょっと変えていくというところが、重要なのかなと感じているところです。
池田:先ほどおっしゃっていたように、Serverspecが価値を発揮できるところは、たくさんのマシンがあってそれに自動構築して、それをちゃんとテストしていくというところになりますよね。
宮下:そうですね、例えばマシンが少なくてもChefとかを使う意義がある場合もあるじゃないですか。個人的にはあまりマシンの台数とかは関係ないかなと思っているんですけれども。
池田:Chefは結構最初にコードを書くのに時間がかかったりして、少ない台数を管理するシステムに導入しようとすると、コスト的に見合うかどうかという問題がありますよね。
運用になると安定思考というか、作ったらいじらないみたいなのがあったりします。そういう場面だとChefとかは使いづらい気はします。ただ当然全部自動化しておくと、後々何かあったときに便利な面もあって、そこをなかなか説明できないのですが。。
宮下:確かに難しいですよね。
Serverspec導入の障壁になるのは
池田:ChefとかよりもServerspecのほうが導入コストがすごく低いというのが個人的な印象です。
宮下:確かに、実際Chefの導入とか相談されたら、まずServerspecの導入から勧める、と知人が言っていました。現状の手動やシェルスクリプトなどの構築手順をテストするコードをServerspecで書いて、そのテストが通るようにChefでコードを書いていく。
池田:まさにTDDで進める感じですね。ちょっとずつ進めるには、そういう方向性のほうがやりやすいのかもしれないですね。
宮下:特にServerspecはまずやってみるというところをかなり意識しているつもりです。
池田:確かにそうですよね。Serverspecは、最初に初期化したときもうすぐに使える状態でパッと出てきてくれるので、そのあたりはすごい参考になりました。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- テスト駆動インフラ/インフラCIの潮流、Serverspecが果たす役割
- Serverspecの概要からインストールまで
- ChefConf 2017、楽天におけるHabitat導入のポイントとは?
- 楽天のOpsのトップが語る「コアなビジネスにこそオープンソースを」
- Serverspecの効果的活用に向けたTips
- Ansibleにおいてテストを行う理由
- CI/CD Conference 2023から、GMOペパボのSREがVM/Kubernetes混在環境でのCI/CDについて解説
- 合理化・効率化のために先行投資をする覚悟
- Dockerを使いこなすには。Dockerはこの先どこへ向かうのか? Docker座談会(後編)
- レッドハットのマネージャーに訊いた女性エンジニアを増やす方法とは?