Rubyで作られたオープンソースソフトウェア（以下OSS）といえば，フルスタックなWebアプリケーションフレームワークのRuby on Railsが有名です。しかし，それ以外にも公開されているツールやライブラリなどはたくさんあります。

本稿ではRubyでプログラミングを行う際に利用されるライブラリではなく，主に利用者として扱う場面があるツール類を紹介します。

Infrastructure as CodeとRuby

近年，サーバの設定などをコード化することで，通常のプログラミングと同じように変更履歴の管理や反映の自動化で注目されています。

このような概念をInfrastructure as Codeと呼びます。これを実現するために，chefやitamaeなどが利用されています。

これらはRubyで実装されており，サーバの設定自体をRubyのDSLで記述することで高い表現力を実現しています。

両者の違いについての詳しい説明は本稿では省略しますが，大まかに述べるとchefは非常によく作り込まれたソフトウェアであるものの，やや重厚な作りになっています。反面，itamaeはより軽量な作りになっており，手軽に扱うことができます。

以下は，itamaeを使った設定の抜粋です。一見すると専用の構文のようにも見えますが，この記述はpackageメソッドを呼び出すというRubyの構文です。

package 'nginx' do
  action :install
end

itamaeでは設定を記述したファイルをレシピファイルと呼びます。このレシピファイルをitamaeコマンドで実行すると，指定したサーバへ設定が反映されます。この例ではOSによって提供されているパッケージシステムを通じてnginxのインストールが行われます。実際にパッケージをインストールする処理は，対象となるOSの種類によって適切なパッケージシステムが選択されます。例えば，Ubuntuのようにaptを利用する環境ではapt-getコマンドを使ったインストールが行われます。

このように，OSの種類によって異なるコマンドや引数の取り方など，細かい部分が抽象化されるため，「⁠どの設定を行うか」という点に注力できます。

構築されたサーバのテストとRuby

前項ではサーバの設定のコード化について紹介しました。こういった方法で十分設定の可視化などは行われるようになりますが，それとは別軸でテストを書く，ということもサーバの状態を管理するための重要な観点です。

サーバの設定も一度適用すれば終わりではなく，チューニングや用途の拡大などで時間とともに設定が変更されていくことがあります。サーバの設定として「どうあるべきか」という振る舞いを検証できれば，より確かな状態を確認できるでしょう。

その検証にはServerspecを使うことで，テストケースを記述し実際にサーバに対してテストを実行することができます。これにより，アプリケーションのテストと同じような感覚で，サーバの動作や状態を検証できるわけです。

ServerspecはRSpecというRubyのテスティングフレームワークをベースにしていますが，Serverspecのサイト上で紹介されているテストケースなどを読み書きできる程度の習熟度で十分利用できます。実際に検証で利用できるメソッドなども詳しく載っているため，どのような検証項目があるのか目を通しておくのが良いでしょう。

以下はServerspecのWebサイトに記述されているテストケースの一部を抜粋したものです。

describe port(80) do
  it { should be_listening }
end

このテストケースは80番ポートが待ち受け状態になっているかを検証するテストです。このテストケースをrspecコマンドで実行することで，対象のサーバで正しくポートが開いているかを検証できます。

Serverspecを使ってテストケースを書いておくことで「ある設定を変えたために別の部分に影響を与えてしまった」というようなことを早期に発見できるかもしれません。また，今までコード化されていなかったサーバを別サーバやクラウド環境へのリプレイスを行う際のテストケースとしてあらかじめ作っておくような使い方も有効でしょう。