2025-11-03

Terraformのmoduleではnested block構文が使えない

terraform

Terraformのresourceやdata sourceではnested block構文を利用できるが、 module定義ではnested block構文を利用できないし、resourceなどにおいても現在は非推奨であることを知ったのでメモ。

resourceでのnested block構文

resourceのような top-level block type 内において利用するblock構文をnested blockと呼ぶらしい。

例えば aws_instance resourceでは、ebs_block_device blockを複数回指定できる。この ebs_block_device がnested block構文。これは attribute ではないので ebs_block_device = {...} のような構文になっていないことに注意。

resource "aws_instance" "example" {
  ami           = "ami-12345678"
  instance_type = "t3.micro"

  ebs_block_device {
    device_name = "/dev/sdf"
    volume_size = 10
  }

  ebs_block_device {
    device_name = "/dev/sdg"
    volume_size = 20
  }
}

Block構文は詳細にはList Nested, Set Nested, Single Nestedの3種類が存在する。これはterraformのplugin開発者向けのドキュメントで解説されている。実際のところ、 ebs_block_device の場合は順番が考慮されない Set Nested Block Typeであることが、実装などからもわかる。

moduleにはblock構文が利用できない

module呼び出しでは同様のblock構文を利用できない。

module "example" {
  source = "./modules/example"

  # これは不可能
  ebs_block_device {
    device_name = "/dev/sdf"
    volume_size = 10
  }

  # これは可能
  ebs_block_device = {
    device_name = "/dev/sdf"
    volume_size = 10
  }
}

moduleの入力変数はすべてattributeとして扱われるため、blockを指定することはできない。あまり意識したことが無かったのでmodule block referenceを確認したが、特に block構文についての説明は無かった。

resourceにおけるblock要素の非推奨化について

参考に、resourceのlifecycleのようなmeta-argumentはnested block構文で定義されている。一方で、AWS providerなどで定義されているresourceやdata sourceにおいてはblock構文は非推奨化されている。前述のaws_instance resourceでいえば ebs_block_deviceのようなblock構文は非推奨で、互換性のためにサポートされている。代替としてattributeを利用することを推奨している。

Tip

Use nested attribute types instead of block types for new schema implementations. Block support is mainly for migrating legacy SDK-based providers.

もちろん、awsなどのproviderを利用する上では関係無いが、providerを開発する上では block構文は非推奨でattributeを利用すればよいこと、block構文は基本的にはmeta-argumentで利用するものと考えておいてよさそう。

2025-08-11

aqua本体の更新エラーをSLSA無効化で回避する

Linux

aquaの更新エラー

aqua upaでaqua本体をアップデートしようとした際、SLSA検証で以下のエラーが発生した：

Verifying artifact /tmp/996689781: FAILED: matching bundle entry with content: unexpected tlog entry type: expected intoto:0.0.2, got dsse:0.0.1
FAILED: SLSA verification failed: matching bundle entry with content: unexpected tlog entry type: expected intoto:0.0.2, got dsse:0.0.1

実際には5回のリトライ後に失敗し、アップデートが完了しなかった。アップデートは v2.31.0からv2.53.9に更新しようとしていた。

SLSA検証を無効化してアップデート

SLSA証明書の形式変更による互換性の問題によるエラー。一時的にSLSA検証を無効化してアップデートを実行する。以下のように実行することで正常に更新できるようになった。

AQUA_DISABLE_SLSA=true aqua upa

アップデート後にシェルキャッシュをクリア

aqua upaが成功してもaqua versionを実行すると古いバージョンが表示された。which aqua でインストール先を確認すると確かに更新されているようだった。

これは、シェルのコマンドキャッシュが原因の様子。シェルが実行効率のためにキャッシュしているコマンドのフルパスをhash -rで全てクリアすることで解消できる。バイナリが更新された際に新しいバージョンを確実に実行するために必要。

# コマンドハッシュテーブルをクリア
hash -r

# バージョン確認
aqua version

2025-08-10

go fmtとgofmtの違いと使い分け

goのフォーマッタとしてgofmt と go fmtがあることを知った。

go fmt

go fmtはgoのサブコマンドとして実装されているフォーマッタ。その実態は gofmt -l -w を指定パスに対して適用してくれる。

$ go help fmt 
usage: go fmt [-n] [-x] [packages]

Fmt runs the command 'gofmt -l -w' on the packages named
by the import paths. It prints the names of the files that are modified.

gofmt

pkg.go.dev

フォーマッタの実態。差分表示(-d)やコード簡略化(-s)など、go fmtでは指定されていない細かなオプションなどを指定できる。

$ gofmt -h
usage: gofmt [flags] [path ...]
  -cpuprofile string
        write cpu profile to this file
  -d    display diffs instead of rewriting files
  -e    report all errors (not just the first 10 on different lines)
  -l    list files whose formatting differs from gofmt's
  -r string
        rewrite rule (e.g., 'a[b:len(a)] -> a[b:]')
  -s    simplify code
  -w    write result to (source) file instead of stdout

何が違うのか、どう使い分けるのか

go fmt 実行時に指定されるオプションの -l と -w なので、デフォルトルールでフォーマットの修正を適用した上で修正したファイル一覧を出力してくれる。なので基本的な動作は同じ。

基本的にはフォーマッタを適用して欲しいので、普段使いとしては go fmt ./... でよさそう。 CIで差分検知だけして書き換えまでは行いたくないときや、書き換えルールをカスタマイズしたいような特別なケースで gofmt を使えばよさそう。

2025-02-15

Google Cloud release notes キャッチアップ 2025-02-08 - 2025-02-14

Google Cloud

resourceでのnested block構文

moduleにはblock構文が利用できない

resourceにおけるblock要素の非推奨化について

aquaの更新エラー

SLSA検証を無効化してアップデート

アップデート後にシェルキャッシュをクリア

go fmt

gofmt

何が違うのか、どう使い分けるのか

Kubernetes Engine

BigQuery

Cloud CDN

Cloud NAT

Cloud Run functions

AlloyDB

Cloud SQL

Cloud Monitoring

Cloud Asset Inventory

VPC Service Controls

Organization Policy

Cloud Billing

Kubernetes Engine

Cloud Service Mesh

Config Connector

Cloud Storage

BigQuery

Cloud Run

AlloyDB for PostgreSQL

Cloud SQL for PostgreSQL

Cloud Logging

Cloud Monitoring

Resource Manager

Cloud Billing

Compute Engine

Kubernetes Engine

BigQuery

Virtual Private Cloud

Cloud DNS

Cloud Monitoring

Cloud Asset Inventory

Compute Engine

Kubernetes Engine

BigQuery

Network Service

Load Balancing

Cloud Run

Cloud Logging

Trace

Organization Policy