Linux環境でServerspecを使ってみる part7
今回はこちらの続きで、apacheを例に設定ファイルのテストをしてみます。
前回:Linux環境でServerspecを使ってみる part6 - ressyのナレッジ的なブログ
テスト内容
以下の内容をテストします。
- パッケージがインストールされているか(
yum install
相当) - サービス
httpd
が起動しているか- サービスがシステム起動時に立ち上がるようになっているか(
chkconfig
相当) - テスト時点で立ち上がっているか(
service httpd
相当)
- サービスがシステム起動時に立ち上がるようになっているか(
- 特定のポート(80/tcp)でリスニングしているか(
netstat
相当) httpd.conf
の設定は正しいか(grep ** httpd.conf
相当)- ファイルが存在するか
Listen
は80
になっているかDocumentRoot
は/var/www/html
になっているか
記述例
テストコードを示す前に、リソースタイプとマッチャーという用語を簡単に説明しておきます。
- リソースタイプ:試験対象のリソースの種類(パッケージ、サービス、ファイル、etc...)
- マッチャー:リソースのあるべき状態(インストールされている、サービスが起動している、etc...)
Serverspecのテストコードは、リソースタイプとマッチャーの組み合わせで記述します。
細かく説明するより、実際のコードを見た方が早いと思うので、記述例を見てみましょう。
シンプルに記述するとこんな感じになります。
$ cat spec/WEB01/http_spec.rb require 'spec_helper' # 1. パッケージがインストールされているか describe package('httpd') do it { should be_installed } end # 2. サービスhttpdが起動しているか describe service('httpd') do it { should be_enabled } it { should be_running } end # 3. 特定のポート(80/tcp)でリスニングしているか describe port(80) do it { should be_listening } end # 4. httpd.confの設定は正しいか describe file('/etc/httpd/conf/httpd.conf') do it { should be_file } its(:content) { should match(/Listen 80/) } its(:content) { should match %r{DocumentRoot "/var/www/html"} } end
package(**)
とかservice(**)
がリソースタイプ、it { ** }
などで記述しているようなbe_installed
などがマッチャーに相当します。
1.〜3.は、コードを見るだけでなんとなくわかると思うので、説明は割愛します。
どんなことをしているか知りたい方は、ServerspecのHPを参照すると良いでしょう。
4.だけ簡単に解説します。
まず、テスト対象が'/etc/httpd/conf/httpd.conf'
となります。
it { should be_file }
で、テスト対象がファイルであるかどうかをテストしています。
its(:content) { should match(/Listen 80/) }
で、httpd.conf
のなかにListen 80
という設定が記述されているかをテストしています。
its(:content) { should match %r{DocumentRoot "/var/www/html"} }
で、httpd.conf
のなかにDocumentRoot "/var/www/html"
という設定が記述されているかをテストします。
ところで、同じshould match
を使用しているのにListen
とDocumentRoot
で記述が異なっています。
細かい説明は省略しますが、簡単にいうとテストしたい内容に、正規表現で使う記号が含まれているか/いないかで記述を使い分けます。
今回の例だとDocumentRoot
には、正規表現ではエスケープ文字として使用する/
が使われているので、%r{***}
という記述を使用しています。
逆にListen
では正規表現で使うような記号が含まれていないので(/***/)
という記述を使用します。
テストを流してみる
記述したテストコードで実際にテストして見ましょう。
実行コマンドは、前回記事の通りです。
$ TARGET_HOST=WEB01 ASK_SUDO_PASSWORD=1 bundle exec rspec spec/WEB01/http_spec.rb Enter sudo password: Package "httpd" should be installed Service "httpd" should be enabled should be running Port "80" should be listening File "/etc/httpd/conf/httpd.conf" should be file content should match /Listen 80/ content should match /DocumentRoot "\/var\/www\/html"/ Finished in 2.57 seconds (files took 5.88 seconds to load) 7 examples, 0 failures
こんな感じになればOKです。
Failure
などが散見される場合は、WEB01
側の設定が間違っていたり、テストコードが間違っている可能性があるので見直しましょう。
最後に
part1で目標にしていたapacheのテストができたので、「Linux環境でServerspecを使ってみる」のシリーズは一旦終了したいと思います。
とはいっても、今後もServerpsecの話題は取り上げるかと思いますが。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ
Linux環境でServerspecを使ってみる part6
今回はこちらの続きで、特定のサーバだけテストしたり、特定の設定だけテストする方法を解説します。
前回:Linux環境でServerspecを使ってみる part5 - ressyのナレッジ的なブログ
特定のサーバだけテストする
私の勉強環境を例にとると、サーバはWEB01
、DBS01
、MGS01
の3種類があります。
前回記事で解説したテスト方法だと、毎回全てのサーバをテストすることになります。
しかし、実際の運用では「WEB01
だけ設定を変えたからWEB01
だけテストしたい」という場面もあると思います。
Serverspecでは、このようなテストも可能です。
具体的にはこのようなコマンドを実行します。
$ ASK_SUDO_PASSWORD=1 bundle exec rake spec:WEB01
rakeの後にspec:<テスト対象サーバ>
を指定すればOKです。
これにより./spec/<テスト対象サーバ>/
配下に格納したテストが実行されます。
特定の設定だけテストする
特定のサーバに加え、例えば「httpdだけをテストしたい」という場面もあると思います。
そのような実行も可能です。
例えば以下のようなコマンドを実行します。
$ TARGET_HOST=WEB01 ASK_SUDO_PASSWORD=1 bundle exec rspec spec/WEB01/http_spec.rb
使用するオプションもコマンドも変わってることがわかるかと思います。
TARGET_HOST
で、試験対象のサーバを指定します。
rspec spec/WEB01/http_spec.rb
で、spec/WEB01/http_spec.rb
に記述されたテストのみ実行することを表しています。
ここにhttpd関連のテストだけを記述すればいいわけです。
ところで実行するコマンドがrake
ではなくrspec
になっています。
詳しくは省略しますが、以前serverspec-init
で初期設定を行った時に生成されたRakefile
は、サーバ単位or全サーバを対象にテストを行うように記述されています。
なので、rake
コマンドではなくrspec
コマンドを使用しています。
テストの実行方法の解説は以上です。
次回は、apache
を例にテストコードを書いてみたいと思います。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ
Linux環境でServerspecを使ってみる part5
今回はこちらの続きで、テストの実行方法について簡単に解説します。
前回:Linux環境でServerspecを使ってみる part4 - ressyのナレッジ的なブログ
テストを実行するコマンド
まずは、前回実行したコマンドをベースに、テストの実施方法を解説します。
$ ASK_SUDO_PASSWORD=1 bundle exec rake
最初のASK_SUDO_PASSWORD=1
は、テスト実行時にsudoパスワードを要求するかを表す環境変数です。
こちらの記事で解説した通り、リモートでテストを実施する場合はsudo権限を持ったログインユーザでテストを実施します。
Linux環境でServerspecを使ってみる part2 - ressyのナレッジ的なブログ
この環境変数によってsudoパスワードを入力し、リモートでテストを実行できるようにします。
ASK_SUDO_PASSWORD
を使用しない場合、SUDO_PASSWORD
という別の環境変数にsudoパスワードを直接設定する必要があります。
bundle exec rake
は、Gemfile
で指定された環境でrake
を実行することを表しています。
rake
コマンドによって、同ディレクトリにあるRakefile
が実行され、さらにそこからディレクトリspec
配下のテストコードが順次読み込まれてテストが実施されます。
簡単ですが、コマンドの解説は以上です。
ちなみに、今回実行したコマンドだと、テスト対象サーバが複数台あったり、1サーバあたりで複数のテストファイルがある場合、コマンドを実行するたびに全てのサーバ・テストファイルが実行されます。
実際にテストを流す場面では「このサーバだけテストしたい」とか「httpd.confの修正だけをしたから、httpdまわりだけテストしたい」といったことが多いかと思います。
次回の記事では、このような場合のテスト方法を取り上げたいと思います。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ
Linux環境でServerspecを使ってみる part4
今回はこちらの続きで、Serverspecでテストを実行してみます。
前回:Linux環境でServerspecを使ってみる part3 - ressyのナレッジ的なブログ
サンプルのテストコード
前回、Serverspecの初期設定を実施したことで、以下のようなファイルが出来上がっているかと思います。
spec/WEB01/sample_spec.rb
これが、WEB01
用のテストケースを記述したサンプルファイルになります。
内容はこのような感じになっていると思います。
$ cat spec/WEB01/sample_spec.rb require 'spec_helper' describe package('httpd'), :if => os[:family] == 'redhat' do it { should be_installed } end describe package('apache2'), :if => os[:family] == 'ubuntu' do it { should be_installed } end describe service('httpd'), :if => os[:family] == 'redhat' do it { should be_enabled } it { should be_running } end describe service('apache2'), :if => os[:family] == 'ubuntu' do it { should be_enabled } it { should be_running } end describe service('org.apache.httpd'), :if => os[:family] == 'darwin' do it { should be_enabled } it { should be_running } end describe port(80) do it { should be_listening } end
大まかに説明すると、describe
〜end
までで一括りとなっており、上から順に
- OSがRedHat系の場合:httpdがインストールされているか
- OSがUbuntu系の場合:apache2がインストールされているか
- OSがRedHat系の場合:httpdが起動しているか
- OSがUbuntu系の場合:apache2が起動しているか
- OSがDarwinの場合:httpdが起動しているか
- 80番ポートがリスニングしているか
がそれぞれ記述されています。
テスト対象のOSに応じて、適切にテストを実施できるように記載されています。
サンプルを使ってテストを実行
せっかくなので、このテストコードをそのまま実行してみましょう。
本ブログの勉強環境はCentOSを使用しているので、os[:family] == 'redhat'
のテストが実行されます。
以下のように、Rakefile
が置かれたディレクトリへ移動して、テストコマンドを実行します。
$ cd cd <任意のディレクトリ>/Serverspec $ ASK_SUDO_PASSWORD=1 bundle exec rake /usr/local/rbenv/versions/2.3.3/bin/ruby -I/usr/local/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/lib:/usr/local/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-support-3.5.0/lib /usr/local/rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/rspec-core-3.5.4/exe/rspec --pattern spec/WEB01/\*_spec.rb Enter sudo password: Package "httpd" should be installed Service "httpd" should be enabled should be running Port "80" should be listening Finished in 0.45621 seconds (files took 3.99 seconds to load) 4 examples, 0 failures
テストが実行されいてる様子が、なんとなくでもわかるかと思います。
ちなみに、4 examples, 0 failures
と出ているので、「4件のテストを実施し、NGは0件でした」となります。
4件と言うのはshould be ....
となっている部分(=実際のテスト部分)の件数になります。
以上で、サンプルのテストコードが実行できたことを確認できました。
次回は、実行したコマンドの解説をしたいと思います。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ
Serverspecでサーバの構成をテストする 導入と個人的知見 - Qiita
Linux環境でServerspecを使ってみる part3
今回はこちらの続きで、Serverspecの初期設定をしていきます。
Linux環境でServerspecを使ってみる part2 - ressyのナレッジ的なブログ
初期設定
以下のコマンドを実行して、初期設定を開始します。
まずは試験対象のサーバをWEB01
としてセットアップを行います。
$ cd <任意のディレクトリ>/Serverspec # 前回記事で作成したディレクトリ $ serverspec-init
OSの種類を質問されます。
今回はLinux環境なので、1
を選択します。
Select OS type: 1) UN*X 2) Windows Select number: 1
次の質問では、リモート接続でテストを行うか、ローカルでテストを行うか選択します。
WEB01
には、リモート接続してテストを行うので、1
を選択します。
Select a backend type: 1) SSH 2) Exec (local) Select number: 1
補足
Serverspecをインストールしているサーバ(今回だとMGS01
)でテストをする場合は、上記で1
と2
のどちらでもOKです。
ただし、1
を選択する場合は、MGS01
自分自身に公開鍵認証でログインできるようにする必要があります。
参考:Linux環境でServerspecを使ってみる part1 - ressyのナレッジ的なブログ
初期設定に戻ります
続いて、Vagrant環境(Vagrantという仮想環境を構築できるソフトウェアで作った環境)かどうかを質問されます。
今回は違うのでn
を選択します。
Vagrant instance y/n: n
最後に試験対象のホスト名を入力します。
今回はWEB01
と入力します。
Input target host name: WEB01
以上でWEB01
用の初期設定はおわりです。
以下のファイル・ディレクトリが出来上がっていればOKです。
+ spec/ + spec/WEB01/ + spec/WEB01/sample_spec.rb + spec/spec_helper.rb + Rakefile + .rspec
作成されたファイル一つ一つの説明は割愛します。
知りたい方は、こちらの記事を参考にすると良いかと思います。
Serverspecでサーバの構成をテストする 導入と個人的知見 - Qiita
ちなみに、他のサーバ(DBS01
とMGS01
)についても試験をする場合は、本記事の内容をもう一度実施すればOKです。
次回の記事で、テストを実施してみたいと思います。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ
Serverspecでサーバの構成をテストする 導入と個人的知見 - Qiita
Linux環境でServerspecを使ってみる part2
今回から、Serverspecの環境を用意していきましょう。
こちらの記事の続きです。
Linux環境でServerspecを使ってみる part1 - ressyのナレッジ的なブログ
はじめに
bundlerを使用してServerspecでテストできる環境を構築していきましょう。
bundlerとは、Rubyのライブラリ管理ができるツールですが、詳細な説明は省略します。
こちらの記事がわかりやすいかなと思います。
あらためてBundlerに関して理解する - Qiita
今回は、こちらの記事で取り上げている勉強環境をベースに行います。
こんなシステム構成で色々勉強していく - ressyのナレッジ的なブログ
ServerspecはサーバMGS01
にインストールし、MGS01
、WEB01
、DBS01
のテストを行えるようにします。
インストール前の準備作業
リモートでテストする場合、接続先サーバにて以下の要件を満たしておく必要があります。
事前に設定しておきましょう。
- 公開鍵認証でsshログインできること
- ログインユーザがsudo権限を持っていること
※ 詳しくは次回以降取り上げますが、MGS01
(=Serverspecインストール先)も試験対象とする場合、方式次第では自分自身に公開鍵認証でログインできるようにしておく必要があるみたいです。
Serverspecのインストール
まずはbundlerをインストールしましょう。
$ sudo gem install bundler
bundlerをインストールしたら、作業用のディレクトリを作成し、そこでGemfileを作成しましょう。
ここでは、Serverspec
というディレクトリを作成します。
$ mkdir <任意のディレクトリ>/Serverspec $ cd <任意のディレクトリ>/Serverspec
作業用ディレクトリ内でGemfileの雛形を作成します。
Gemfileとは、gemでインストールしたいパッケージの記述するファイルです。
$ bundle init
$ ls
Gemfile
Gemfileをエディタで編集し、以下のようにしてください。
具体的にはgem
でrake
、serverspec
、highline
の3つをインストールします。
rake
:Ruby用のビルドツール。C言語でいうとmakeみたいなもの。serverspec
:Serverspec本体。highline
:CLI入出力を支援するパッケージ。テスト対象のサーバのsudoパスワードを入力するために使用する。
ちなみにGemfileの雛形ではrails
がコメントアウトされた状態で作成されますが、今回は使用しないのでコメントアウトのままにしています。
$ cat Gemfile # frozen_string_literal: true source "https://rubygems.org" # gem "rails" gem "rake" gem "serverspec" gem "highline"
Gemfileに記載したパッケージをインストールします。
$ bundle install
実行後、パッケージがインストールされたかを確認します。
以下は、一例です。
rake
、serverspec
、highline
などが確認できればOKです。
$ bundle exec gem list *** LOCAL GEMS *** bundler (1.13.6) diff-lcs (1.2.5) highline (1.7.8) multi_json (1.12.1) net-scp (1.2.1) net-ssh (3.2.0) net-telnet (0.1.1) rake (12.0.0) rspec (3.5.0) rspec-core (3.5.4) rspec-expectations (3.5.0) rspec-its (1.2.0) rspec-mocks (3.5.0) rspec-support (3.5.0) serverspec (2.37.2) sfl (2.3) specinfra (2.66.2)
これでインストールは完了です。
次回は、Serverspecでテストするための準備作業を取り上げます。
参考
この記事は、以下を参考にしています。
「Serverspec」を使ってサーバー環境を自動テストしよう - さくらのナレッジ