↓の本の「9章 Terraformのコードをテストする」のメモを残します。
前章のメモ
テストの目的
成功確率を高め、自身をもってデプロイをできるようにするため
手動テスト
手動テストの基礎
Terraformのコードはローカルホストが使えず、実際にデプロイして確かめる必要がある。
ただ、書いたコードを本番やステージングにデプロイするのはリスクが高い。
なので、サンドボックス環境へモジュールのサンプルコードをデプロイするなどでテストをする。
テスト後の後片付け
手動テストでデプロイしたものを残しておくのはお金がかかる。
cronジョブで定期的にリソースを削除するなど、後片付けを仕組化しておく。
自動テスト
ユニットテスト
ユニットテストの基本
Terraformにおいて、ユニット＝再利用可能なモジュール
テストの流れは手動テストと同じく、
モジュールのサンプルコードをデプロイ ⇒ 振る舞いを確認 ⇒ 削除
これをTerratestとGoのコードを書いて自動でテストする。
外部依存性
他のモジュールと依存性がある場合は、入力変数を利用し外部から注入できるようにする。
テストを並列に実行する
デフォルトでは、Goは直列にテストを実行する。
たくさんのテストがあると、とても時間がかかりテストを何回も実行できなくなる。
そこで、t.Parallel() をGoコードの最初に追加して並列に実行する。
ただ、テスト用にデプロイしたリソースの名前がかぶってしまいテストが失敗するかも。
避けるには、環境名や外部から名前を指定できるようにする。
統合テスト
統合テスト＝複数のモジュールをデプロイして正しく動作しているかのテスト
ただ、毎回複数のモジュールをデプロイしていては時間がかかる。
テストに時間がかかり、複数回できなくなるのは効率が悪い。
デプロイ⇒テスト⇒修正⇒テスト⇒削除
のように、一度デプロイしてテストしたら修正デプロイをするため残しておく。
テストに通ったらインフラリソースを削除するようにする。
また、一時的なエラーに関してはリトライ処理をするなど対処しておく必要がある。
E2Eテスト
Terraformで0からデプロイしてのE2Eテストを実施するのは難しい
- デプロイが遅い
- アーキテクチャ全体のデプロイ＆削除は時間がかかる。
- テストの回数が限られる
- 不安定すぎる
- AWSやGitHubのトラブル起因でテストが失敗することがある
代わりに本番環境に近い環境を1回だけ構築し、そこに追加でデプロイしていきE2Eテストする。
本番へのデプロイも環境に追加デプロイする流れであり、似たプロセスでテストできる
その他のテスト手法
- 静的解析
- コードの解析。
- terraform validate がシンプル
- 他には tfsec , tflint など
- プランを使ったテスト
- terraform planを実行し、出力を解析。
- プロバイダの認証を突破する必要あり。
- Terratestなどで実装可能。
- Open Policy AgentというPolicy as Code ツールとして人気
- 構築したサーバのテスト
- サーバが正しく構築されているかのテスト。
- InSpec, Serverspec, Goss などがある。
- プロバイダへの認証が必要
次章のメモ
コメント