Terraformのライセンス変更のせいでインフラプロジェクトの自動テストの設計が破綻した話
Terraform v1.6でtestが追加されたことを知り、そろそろ自動テスト可能なインフラプロジェクト作ってみようかなと思い、試しに作り始めてから早2ヶ月。
そして昨日知ったのだが、Terraformのv1.6からライセンスが変更(MPL2.0->BSL1.1)されたとのこと。
ざっくり言うと、別にIaCツールとして使っているだけならこれまでと変わりなく使い続けることが出来るが、Terraform(HashiCorp)の競合となりうるツールのコードでTerraformを利用する場合、ライセンス違反になるらしい。
別に普通使い出来るなら問題ないのではと思うかもしれないが、これのせいでTerraformのテストを実装するためのフレームワークであるTerratestが実質利用できなくなる。
一方で、Terraformはv1.6でTerraform Test、v1.7でTerraform Mockを機能追加している。
ライセンスの話抜きにインフラプロジェクトの自動テストを設計すると、テストフェーズは以下のようになるはずだった。
(テストコードの基本的な考え方はHashiCorpの記事が参考になる)
| フェーズ | 使用フレームワーク | テスト内容 |
|---|---|---|
| unitテスト | Terraform Test / Terraform Mock |
基本、terraform planを実行した結果の値が、想定通りの値になるかチェックするだけのテストになる。 あまり意味のないテストに見えるが、providerやTerraform自体のメジャーバージョンアップなどで既存リソースが意図しない値を出力するように変化した場合に検知できるのと、そのテストを書く過程の中で違和感に気付いてバグを回避できたりと、それなりに書く意味のあるテスト。 とはいえ、Terraformのリソースはapplyしないと値を取得できないものがほとんどで、さらにインフラリソースは実際に適用してみないと分からないことが多いので、けして十分なテストではない。 |
| integrationテスト | Terraform Test / (Optional) Terratest |
terraform applyを実行して、実際にリソースを作成して行うテスト。 例えばGCPのCloud SQLを構築する場合、まずVPCを作成する必要があるなど、依存関係をmockせずに一連のリソースの作成が正常に完了するかをテストすることになるので、unitテストよりは実践的なテストにはなる。 ただHCLのような宣言型言語では、自由度の高いテストを実装することは出来ない(まだちゃんと試していないので間違いかもしれないが)。 例として、ServiceAccountリソースを生成＆テストする場合、ServiceAccountの属性が意図する値になるかではなく、特定の権限を持つServiceAccountが権限に紐づくGCPのサービスを正常に操作出来るかを実際に試してみる方がいいテストになる。 そのようなテストを書きたい場合、やはり手続き型言語でテストを実装する必要が出てくる。 (そしてインフラのコード界隈はいつの間にかGoに支配されてる感があるので、Goで書くことになる) よって、チームがGoのテストコードを保守/運用していくと決めたのならば、Terratest、Google SDK(Go)、その他必要なGoライブラリ等を使用してintegrationテストを実装することになる。 ただ実際に試してみて思ったが、学習コストが非常に高くなるので、ある程度までの自動テスト能力で十分というなら、Terraformネイティブなテスト機能だけを使ってテストを構築することになる。 |
| e2eテスト | Terratest | インフラ構築後に、負荷テストやフロント側からPlaywrightなどでブラウザ操作などを行うといった、ユーザサービスを正しく提供できているかまで確認するテスト。 (一般的なインフラのe2eテストとは微妙に違うかも) ここまで複雑になるとHCLだけでの実装は絶対に無理なので、Terratest、Google SDK(Go)、その他必要なGoライブラリ等を使用することになる。 |
以上のように、基本はTerraformネイティブなテスト機能を使うようにして、ビジネスインパクトの大きな機能に関連するリソースのテストを厚くしたい、かつGo＆テストコード上等なチームの場合にはTerratestなども併用すればいいという方針でいく予定だった。
が、最初に書いたようにライセンスの変更によって、HashiCorp TerraformとTerratest(OpenTofu側)の併用はもう今後出来ない状態となっている。
GruntWorks(Terratestの開発元)の一連の問題への批判投稿にもあるように、そもそもTerraform自体が分裂して下火になる可能性もある。
Pulumiに移行すべきと言っている人も一定数いるが、Pulumiも結局はPulumi Corporationの製品なので、同じ道を辿る可能性は全然ある気がしている。
(ちなみに概要をさらっと見ただけだが、自動テストやPolicy as Codeの機能をPulumi自体がサポートしてそうな点は良さげとは思った)
とりあえず、各IaCツールの直近のシェア動向が知りたくて、何か参考になる値は無いかと調べていたら、GithubのStar数の推移見れるサイトあったので、Terraform、OpenTofu、PulumiのStar数の推移を出力してみた。
ライセンス変更発表があったのが2023年8月ごろらしいが、Terraformの成長率にあまり影響ないように見える。
Pulumiがその時期にStar数の増加率が上昇したようだが、そこまで一気にシェア(Star数)を獲得できたわけではなさそう。
そしてOpenTofuのStar数が、Pulumiに到達しようとしている。
しかしOpenTofuは2024年1月現在のコントリビュータ数が67人なのは多いのか、少ないのか。
(CHANGELOGみる限り機能の追従に苦労してる感はある)
とりあえず、IaCツールはTerraformのままでいったん行くことにして、Terratestが担当するはずだった部分のテストを別の方法で実現できないか調べる。
なんかさらに面倒なこと出てきたら、流石にPulumiに乗り換えるかも。
追記
- terraform-execが代替になるかもという記事
-
最近O'reillyから発売された、
詳解 Terraform 第3版の9章 TerraformのコードをテストするでTerratestについて言及されているが、上記の通りOpenToFuに移行しないと出来ない手法となってしまった。(同じことやろうとしている人に気づいてもらえないものか)
- そして今に至る
Discussion