事象内容
CDKTFでLambdaの公式モジュールを利用しているんですが、
timestampの変更によって変更があるように見えてしまう事象があります。（実際は変更されない）
- 差分内容
# module.lambda.null_resource.archive[0] must be replaced
+/- resource "null_resource" "archive" {
~ id = "3206448567786064651" -> (known after apply)
~ triggers = { # forces replacement
~ "timestamp" = "1718001864670115000" -> "1718478355312732000"
# (1 unchanged element hidden)
}
}
この対策としてv6.7.0がリリースされましたが、
Lambdaのmoduleをアップグレード対応時にはまりどころがあったので備忘録的に残しておこうと思います。
元々の定義内容
CDKTFを利用してmoduleを利用する場合は
cdktf.jsonに以下のような感じで定義しています。
"terraformModules": [
{
"name": "lambda",
"source": "terraform-aws-modules/lambda/aws",
"version": "6.5.0"
}
],
versionが6.5.0になっていますが、これのバージョンアップすることが目的になります。
試行錯誤の記録
ますはmoduleを最新化する必要があるのでcdktf.jsonのversionの箇所を
現時点(2024/06/16)の最新v7.6.0に変更します。
変更後ローカルにあるmoduleを更新します。
cdktf get
- 出力
[2024-06-15T19:14:05.186] [INFO] default - The CDKTF version has changed, generating all constraints. The previouGenerated typescript constructs in the output directory: .gen
→更新は正常にできたようだ。
いざデプロイ
cdktf diff
- エラーログ
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/aws:
│ locked provider registry.terraform.io/hashicorp/aws 5.28.0 does not match
│ configured version constraint >= 4.0.0, >= 4.9.0, >= 5.6.0, >= 5.9.0, 5.28.0,
│ >= 5.32.0; must use terraform init -upgrade to allow selection of new
│ versions
→providerのバージョンが合わないとのことなので、providerのバージョンを上げる必要があるようだ。
init -upgradeをやれとあるのでやってみる
terraformは関係なさそうだなと思いつつも愚直に指示通りにやってみる。
terraform -chdir=cdktf.out/stacks/sample init -upgrade
- エラーログ
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/aws: no available releases match the
│ given constraints >= 4.0.0, >= 4.9.0, >= 5.6.0, >= 5.9.0, 5.28.0, >= 5.32.0
やはり関係ないな。
Synthをやってみる
- cdktf synthとは
CDKTFのコードをTerraformのコードに変換するコマンドです。
cdktf synth
→ 状況変わらず。
package.jsonが古いことに気づく
- 差分
諸々最新バージョンを指定
@@ -20,9 +20,9 @@
"node": ">=18.0"
},
"dependencies": {
- "@cdktf/provider-archive": "^9.0.1",
- "@cdktf/provider-aws": "^18.0.8",
- "cdktf": "^0.19.2",
+ "@cdktf/provider-archive": "^10.0.1",
+ "@cdktf/provider-aws": "^19.23.0",
+ "cdktf": "^0.20.7",
"constructs": "^10.3.0"
},
"devDependencies": {
npm 再install
- 古いnode_modulesを削除
rm -rf node_modules
- 再install
npm install
→ package-lock.jsonが更新される。
cdktf diff確認
# module.lambda.aws_lambda_function.this[0] will be updated in-place
~ resource "aws_lambda_function" "this" {
id = "lambda-function-name"
~ tags = {
+ "terraform-aws-modules" = "lambda"
}
~ tags_all = {
+ "terraform-aws-modules" = "lambda"
# (3 unchanged elements hidden)
}
# (28 unchanged attributes hidden)
- timeouts {}
# (4 unchanged blocks hidden)
}
# module.lambda.null_resource.archive[0] must be replaced
+/- resource "null_resource" "archive" {
~ id = "3206448567786064651" -> (known after apply)
~ triggers = { # forces replacement
~ "timestamp" = "1718001864670115000" -> null
# (1 unchanged element hidden)
}
}
timestampの箇所がnullになっており、次回以降無視されるようになった。
補足としてterraform-aws-modulesのタグがどこかのバージョンから追加されるようになったようだ。
まとめ
moduleのバージョン書き換えだけで済むのかと思いきや、
package.jsonの存在を失念していました。（失念しがち）
GitHubActionsなどに組み込む場合、Version管理は重要な要素なのでこれからも留意していきたいですね。
なお、補足として賛否両論分かれるterraformの公式モジュール利用の可否ですが、
開発も活発に行われておりきちんとバージョン管理などを行うようすれば非常に便利な機能です。
公式モジュールを使わない理由としてよく聞くのが「 細かい要件にあわない」
「 いつ使えなくなるかもしれない」などがありますが、
それはterraformそのものにも言えることだと割り切って利用目的に合いそうであれば積極的に利用しています。
全部が全部公式モジュールでいいとは思いませんが、
部分的に利用する分には 車輪の再発明 をする必要がなくなり、
結果として工数削減にもつながるので、結局は設計、管理方式次第かなと考えています。
Discussion