Qcon SFでYevgeniy Brikman氏が、"Automated Testing for Terraform, Docker, Packer, Kubernetes, and More"と題したプレゼンテーションを行った。その主題は、静的分析やユニットテスト、インテグレーションテスト、エンドツーエンドテストなど、すべてのテストテクニックを適切に使い分けることの提唱だ。氏が推奨するのは、"テストピラミッド"で示されるとおりの、多数のユニットテストと静的分析テスト、いくつかのインテグレーションテスト、少数のエンドツーエンドテストを行う方法である。最終的には、インフラストラクチャテストコードがデプロイメントに対する自信を確立し、不安を取り除いてくれる。
"DevOps as a Service"を提供するGruntworkの創設者のひとりであるBrikman氏の講演は、システムダウンやセキュリティ侵害、データ損失や改ざんといった、DevOpsの世界で恐れられている問題に関する話題から始まった。このような問題により、DevOpsチームのデプロイ数が少なくなり、結果としてデプロイ作業時間は全体の60パーセントに過ぎなくなっている、と氏は指摘する。このような不安に対処するよい方法は、自信を高める手段としての自動テストの導入だ。氏が指摘するように、アプリケーションコードの自動テストの記述方法は誰でも知っているが、その動作対象となるインフラストラクチャをデプロイするTerraformコードや、最終的にサービスをデプロイするKubernetesコードのテスト方法については事情が違う。
インフラストラクチャコードをテストするためのテクニックとしては、次のようなものがある。
- 静的分析
- ユニットテスト
- インテグレーションテスト
- エンドツーエンドテスト
最初に取り上げたテクニックは、実際にリソースのデプロイを行わずに実行する、インフラストラクチャコードの静的分析だ。コードはコンパイラやパーザ、あるいはインタプリタを通じて文法と構造をチェックし、コードが有効かどうかを判断する。例としてBrikman氏は、Terraform用の分析ツールであるterraform validateを使用して、Terraform demoの分析を実施してみせた。続いて氏は、すべてのインバウンドトラフィックを許可するセキュリティグループのような、一般的なエラーを検出する別のツールを紹介した。そして最後に、コードを実行するだけで実際のデプロイを行わないドライランについて説明した。これについても、Terraform planなどのツールが存在する他、Kubernetesを使った次のようなコマンドを利用する方法もある。
kubectl apply -f <file> --server-dry-run
次にBrikman氏は、コードを分離してテストする方法であるユニットテストについて論じた。クラウドインフラストラクチャにおけるユニットは、ひとつないし複数の依存リソースを含む単一モジュール、ということになる。さらに、それをテストするには、実際の環境でそのモジュールにインフラストラクチャをデプロイする以外の方法はない。講演で氏が話したように、インフラストラクチャコードの完全なユニットテストというものは存在しないのだ。
具体的な方法としては、定義されたリソースをデプロイして、その動作を検証し、後でアンデプロイする、という手順になる。この方法に関しても、Terratestのようなサポートツールが存在する。Brickman氏はTerraformユニットテストの実行デモを公開した上で、関連コードについて説明した。ここで使用されたコードは、GitHubで公開されている。最後に氏は、Docker/Kubernetesで同様なデモを行った。
ユニットテストを論じた後には、すべてのユニットテストを一度に行うテクニックとしてインテグレーションテストを紹介した。インテグレーションテストの基本的なアプローチは、ユニットテストと同じようなものだ。氏は、先程のTereraformユニットテストのデモで用いたものと同じコードを、今度は2つのユニットのリソースにデプロイした。デモが終了した後には、テストを並列実行するインテグレーションテストによってスピードアップしたことを示すと同時に、並列で行うことに伴うコンフリクト、例えばリソース名がユニークでないことによる問題を指摘した。さらに氏は、テストステージとリトライの概念についても説明した。
最後にBrikman氏が論じたのは、インフラストラクチャ全体のデプロイメントをテストするエンドツーエンドテストだ。アプローチはユニットテストの場合と同じようになる。すなわち、すべてのインフラストラクチャをデプロイし、正常動作を評価し、ティアダウンする、という手順だ。しかし氏は、これが一般的な運用方法ではない点を指摘した上で、静的分析を底辺とし、続いてユニットテストとインテグレーションテストを配置し、頂上にエンドツーエンドテストを置くという、テストピラミッドを紹介した。
氏によれば、
このピラミッドで注目すべきなのは、テスト記述のコスト、テストの不安定性、テスト実行時間といったものが、上に行くに従って高くなっていることです。
テストで多くのリソースをデプロイするほど、エンドツーエンドテスト実行時に障害を発見するチャンスは大きくなる、とBrikman氏は言う。ユニットテストとインテグレーションレストが再実行が可能だが、エンドツーエンドテストは不安定であり、実行時間も多く必要とする。そのためBrikman氏は、インクリメンタルな実行がより望ましい、と示唆している。
- 永続的なテスト環境をデプロイし、実行したままにする。
- モジュールアップデートの都度、そのモジュールのデプロイと評価を行う。
すべてのテストテクニックを使用することは可能だが、同時にテストピラミッドも適用することを提唱して、氏は講演を締め括った。
Yevgeniy Brikman氏のQCon San-Francisoでの講演内容については、カンファレンスのWebサイトに詳しい説明がある。講演のスライドが公開されており、ビデオも数ヶ月中にInfoQから公開される予定である。