suzuki-shunsuke
commented
4 years ago Ansible のテストは実装ではなく仕様を満たしているかテストすべき
- Playbook を元にそのままテストを書くのは良くない
- 変更に弱くなる
- ソフトウェアのアップグレードで設定ファイルのパスとかが変わったときにテストがこける
- 設定ファイルのパスは本来重要ではないはず。アプリケーションが正しく動作していればよいはず
- 無意味なテストが多くなる
- Playbook を他の言語(ツール)でそのまま書き直すみたいなことになり、「これ意味あるのか？」という気持ちになる
- サービスの振る舞いをテストするべき
- アプリケーションが起動しているか。 port が listen しているか。バージョンが正しいか
- むしろ振る舞いをテストとして表現し、それを満たすように Ansible を書くのが筋
- 静的なテストと動的なテストを区別する
- 静的なテスト: Ansible を実行しなくても、Playbook を静的に解析してテストする
- Ansible Lint とか
- 静的にテストできるものは動的なテストでチェックしなくてよいのでは
- 例えばファイルのパーミッションが不適切に付与されてないかセキュリティ的な観点でチェックしたいとかであれば Conftest のようなツールでテストすべき
- Conftest で Playbook テストしたことはないけど
- Playbook を元に serverspec や goss のようなツールでテスト書いてテストする場合、多分 mode とか owner, group ってコピペになってて意味がない(playbookが間違ってたらテストもそのまま間違ってる)
- 動的なテスト: Ansible でプロビジョニングしたインスタンスに対してテストする
- ちゃんとアプリケーションが起動しているかは静的には分からないので動的なテストが必要
- 振る舞いをテストする
ブログにする前の下書きてきななにかです。
Ansible ではテスト書く必要ないのでは
そう思ってた頃が自分にもありました。 というのも Ansible の Playbook がサーバのあるべき姿を表現しているものであり、それをそのまま他のツール(serverspec や goss など)でテストにしたとしても、同じものを別の言語で書き直しているようなものであり、この作業意味ある？って感覚に陥るからです。 尤も、 Ansible 自体のバグを発見できる場合はありますが(service を enabled にしているはずが実際には enabled になってないことがあるみたいな既知のバグを見つけたことがあります。最新では直ってるはず)。
そういったテストを書いておいてテストが落ちたとしても、多くの場合 Playbook の変更にテストが追従できてなかっただけみたいなことも多く、無駄なメンテコストが発生することも多かったです。
しかし、本当にテストがいらないかというとそんなことはなくて、プロセスが起動しているかとか、 listen しているかみたいなテストは必要です。 例えば Ansible に成功しても Nginx の起動に失敗しているとかそういうことはままあります。
なので本当に必要なのはブラックボックステスト的なものです。
仕様を考えてテストとして表現し、そのあとその仕様を満たす Ansible を実装すべきなのではないかと思います。 Ansible を書いてからそれを元にテストを書き始めると、実装の詳細にテストが引っ張られ、 本質的ではないテストが増え、変更に弱いテストになってしまいます。
と言っても、現実には既に Playbook があるけどテストはないみたいなケースも多く、今更 test first と言っても遅いということはありますが。
ここまで書いてて思ったのは「Ansible でテストって書けたっけな。あるいは Ansible でテスト書いたほうがいいかもな。全部は無理でも一部のテストは Ansible で書ける気がしないでもないな」ということです。あとで調べてみようと思います。