Puppet や Serverspec に限らず、Chef でも Itamae でも awspec でも自前スクリプトでも何でもいい話なんですが。 つまり テストコードに書く期待値を、構成管理ツールで使っているパラメータファイルから取ってきたほうがいいのか という話題。
結論から言うと「何をテストしたいのか」によって Yes/No が変わるんじゃないかな、と思います。
前置き: 例えばこんなこと
hiera でこう書いてたとして
--- packages: - emacs - vim
manifest でこう書いてたとすると
$packages = hiera('packages') package { $packages: ensure => latest }
Serverspec ではこう書くと思います
describe package('vim') do it { should be_installed } end describe package('emacs') do it { should be_installed } end
ある日、こんな要望がありました
packages: - - emacs - vim + - php-common
このとき、テストコードでは describe package('xxx') の部分を一つずつ直していくことになるでしょう。
数はまだ少ないですが、もしパッケージ数が5個とか10個とかになるとどうでしょうか。
また、パッケージだけならともかく、service だったり iptables だったり、その他細々としたものを書き換える度に
「よっしゃ、manifest 書いてデプロイ完了したぜっってテスト落ちてる…あーはいはい、テストコードの部分を更新し忘れてましたね…」
となることはないでしょうか*1。 その時にアナタはこう思うでしょうか。
「テストコードも hiera を参照してくれれば変更点1箇所で済むのに」
すると、アナタはこんな感じでがんばるかもしれません
hiera = Hiera.new(config: '/path/to/hiera.yaml') hiera.config[:yaml][:datadir] = '/path/to/hiera/hiera_data' packages = hiera.lookup('packages', nil, {}) # ['vim', 'php5-common'] packages.each do |pkg| describe package(pkg) do it { should be_installed } end end
こうすることで
- パラメータの変更を hiera に反映する
puppet applyrspec
という形で サーバの仕様変更におけるパラメータ編集箇所 が1箇所に集約できるメリットが生まれました
本題: これでいいのかどうか
これまでの流れからすると、おそらく Puppet でサーバを構築しつつ Serverspec でテストしているこの人は
さきほど修正した hiera が、ちゃんとサーバに apply されているかどうか
というのを一番チェックしたいと考えていると思います。
これ自体は特に問題ないと思っていて、ちゃんとテスト流してて素晴しいですよねみたいな未来です。
ですがこれはあくまで視点の一つで、おそらくもう一つ、下図のような見方をすることもあると考えています。
つまり直前にテストしたかどうか、とかは関係なく、純粋に 現時点でのサーバが期待した状態(つまり仕様)を保っているか を中心とするテストです。
この場合、逆に hiera の値をテストコードに使うのはよくなくて
- hiera で php を追加するつもりが ruby を追加してしまった
- 気づかずに apply
- rspec
- 本当は php がインストールされていてほしいが、hiera 上は ruby が正義なので PASS
ここもレビューをしっかりしていれば防げるかもしれません。しかし、往々にして人は見逃してしまうものなので、ありえない未来じゃないなと思っています。
まとめ
私が業務で触っている部分では
- Puppet
- Terraform
に対して
- Serverspec
- infrataster
- awspec
のテストを用意していて、それぞれのディレクトリも似たような構成にしています。 そのため、hiera ファイルをそのまま使えちゃうので、どうしても「テストコードにも書くのめんどいわー」みたいなことが、無くも無いです。
最終的にはどちらが良い悪い、ということではなくて「何をテストしたいか」っていう当たり前のことを忘れないでいてくれれば10年後の8月また元気で出会えるんじゃないかなと思います。
