HCP Terraform No Code Moduleのバージョン指定を考えてみる
No Code Moduleは、利用者がTerraformコードを書かずにTerraformでリソースをデプロイできる機能です。
この特性から、通常のTerraformと同じようにバージョン指定をすると不便なことがあります。
今回は、No Code ModuleのTerraform・Providerバージョン制約のおすすめ設定方法を紹介します。
結論
メジャーバージョン | マイナーバージョン | パッチバージョン | 設定例 | |
---|---|---|---|---|
Terraform | 固定 | 最新 | 最新 | >= 1.12.0 |
Provider | 固定 | 固定 | 最新 | ~> 5.99.0 |
tfファイルにすると以下のような形です。
terraform {
required_version = ">= 1.12.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.99.0"
}
}
}
No Code Moduleの特徴
No Code Moduleには、以下の特徴があります。
- 再利用可能なモジュール
- ルートモジュール(呼び出し元のコードは存在しない)
通常のモジュールだと、ルートモジュールから呼び出して使います。
しかし、No Code Moduleでは呼び出し元のコードが存在せず、ルートモジュール的な役割もあると思います。
ここで、公式ドキュメントをみてみましょう。
Reusable modules should constrain only their minimum allowed versions of Terraform and providers, such as >= 0.12.0. This helps avoid known incompatibilities, while allowing the user of the module flexibility to upgrade to newer versions of Terraform without altering the module.
Root modules should use a ~> constraint to set both a lower and upper bound on versions for each provider they depend on.
Version Constraints - Configuration Language | Terraform | HashiCorp Developer
以下のように解釈しました。
- 再利用可能なモジュール:
>=
を使用。最小バージョンを制約。 - ルートモジュール:
~>
を使用。バージョンの下限と上限を設定。
No Code Moduleはどちらの特徴も持ちます。どちらに従うべきか迷います。
TerraformバージョンとProviderバージョンで分けて考えてみます。
Terraformバージョン: Terraformバージョン制約によるRunの失敗回避
No Code Moduleを利用して作成されるWorkspaceは、その時点の最新のTerraformバージョンが指定されます。(2025/6時点)
この動作は、No Code Moduleのtfファイルにrequired_version
の設定が含まれていても関係ありません。
以下のように設定していても、その時点で1.12.0
が最新だと1.12.0
がWorkspaceに設定されます。
terraform {
required_version = "~> 1.10.0"
}
このままRunが行われると~> 1.10.0
の制約では、1.10.3
は許容しますが1.12.0
は許容できません。
そのためエラーになり、Runが失敗します。
Workspace作成後にWorkspaceのTerraformバージョンは変更可能です。
今回であれば、1.10.0
に設定してRunを再実行すればエラーは解消されます。
No Code Moduleのコンセプトとして、Terraformを分からない人でもTerraform経由でリソースを作成できることがあると思います。
そういったユーザーは、Workspaceのバージョン変更もハードルが高いように思います。単純に手間でもあります。
上記からTerraformバージョンはメジャーバージョン固定・マイナーバージョン・パッチバージョン最新(例: >= 1.10.0
)をおすすめします。
Providerバージョン: 意図しない変更を防ぐ
Providerバージョンに関しては、required_providers.version
に従ってバージョンが設定されます。
バージョン指定可能・安定性を確保するために、パッチバージョンだけ最新化(例: ~> 5.99.0
)することをおすすめします。
マイナーバージョンを最新にした場合(例: >= 5.99.0
)も考えてみます。
ユーザーが作成した時点の最新のマイナーバージョンが適用されます。
作成タイミングによっては、5.100.0
5.99.0
5.101.0
のように同じ No Code ModuleでもProviderバージョンが異なることになります。
マイナーバージョンは基本的には後方互換性があります。
しかし、Providerによってはマイナーバージョン内にBREAKING_CHANGE
が含まれていることもあり、特定バージョンでは既存のコードで動かなくなることもありえます。
マイナーバージョンのアップデートのタイミングはコントロールできたほうが運用しやすいです。(マイナーバージョン固定)
おわりに
No Code Moduleは、ModuleとついているのでModuleと同じようにバージョン制約を考えたくなります。
しかし、呼び出し元のコードが無くルートモジュール的な面もあります。
作成されるWorkspaceのTerraformバージョンがモジュールのコード内で指定可能になったら、Terraform・Providerどちらもパッチバージョンで指定するのが良さそうです。
今後のアップデートに期待ですね。
以上、AWS事業本部の佐藤(@chari7311)でした。