Terraform Registry入門: 公式モジュールの安全な使い方［Associate対応］

Terraform Registryは、モジュールとプロバイダを検索・取得する公式カタログです。実務では“どのモジュールを、どのバージョンで、どう固定するか”が品質と再現性を左右します。

本稿では、Registryにおける検証済み(Verified)モジュールの見分け方、バージョニング、入力/出力の読み解き、プロバイダ連携、導入手順までを、Associate試験の観点を織り交ぜて整理します。

Registryの基礎と“公式”相当モジュールの見分け方

Terraform Registryには、モジュールとプロバイダが公開されています。モジュールは source に「<namespace>/<name>/<provider>」形式のアドレスを指定して参照します (例: terraform-aws-modules/vpc/aws)。

信頼性の目安として、発行元の名前空間、更新頻度、ダウンロード数、README/Examples、Issuesの解消状況、そしてRegistry上のバッジ(Verifiedなど)を確認します。UIやバッジ表記は時期により変わることがありますが、一般に“Verified”は審査済みの発行元であることを示し、品質や保守体制の期待値が高いと判断できます。

• モジュールのソース表記: <namespace>/<name>/<provider> (例: terraform-aws-modules/vpc/aws)
• 信頼の目安: Verifiedバッジ、発行元の実績、更新日、READMEの充実度、Examplesの有無
• 試験観点: Registryでの検索、モジュールの読み方、sourceとversionの指定方法が頻出

バージョニングと互換性の考え方

モジュールは一般にSemVerに従います。破壊的変更はメジャー、後方互換の追加はマイナー、修正はパッチと期待します。Terraformはモジュールのバージョンを lock ファイルで固定しません。したがって module ブロックの version で必ず制約を明示します。

プロバイダは required_providers で制約し、.terraform.lock.hcl に固定されます(初期化時に作成/更新)。この違いは試験でも問われやすく、実務でも混同しがちです。

• モジュールの固定: module "..." の version で指定 (例: "~> 5.0")
• プロバイダの固定: terraform.required_providers と .terraform.lock.hcl
• アップグレード: terraform init -upgrade で許容範囲内の最新版へ
• RegistryのRequirements欄でTerraform/Providerの対応バージョンを確認

Inputs/Outputs/Examplesの読み解き方

Registryのモジュール詳細では、Inputs(variables)、Outputs、Resources、Examplesが整理されています。まずExamplesで最小構成を掴み、次にInputsを上から精読して必須/任意、型、デフォルト、nullable、sensitiveを確認します。Outputsは後続モジュールや外部連携で参照する値の起点になります。

サブモジュール(submodules)がある場合は、用途別に分割提供されていることが多いため、過不足なく選ぶことが重要です。

• Inputsの必須/任意と型整合を最初に確認
• Examplesと実際の変数名を突き合わせて初期導入を短縮
• Outputsの名称・型を把握して他リソースの参照に活用
• sensitive=true の出力はCLI表示抑制。ログ/状態管理に配慮

プロバイダ連携とロックファイルの要点

モジュールは内部でプロバイダを利用しますが、プロバイダの設定・認証情報は原則としてルートモジュール側で行い、必要に応じて providers メタ引数でエイリアスを渡します。リージョン分割や複数アカウント運用では alias の設計が重要です。

.terraform.lock.hcl はプロバイダのバイナリを固定する仕組みであり、モジュールには適用されません。モジュールは version 制約で固定、プロバイダは lock ファイルで固定、という役割分担を押さえてください。

• required_providers でプロバイダのソースとバージョンを制約
• provider "aws" { alias = "..." } と module providers で明示的にマッピング
• lockファイルはVCSで共有し、再現性を担保
• 認証とリージョンはルートで設定、モジュールへ過不足なく引き渡す

実務手順: VerifiedなVPCモジュール導入の最小例

例として、AWSのVPCを作る検証済みモジュールを採用します。Registryで“terraform-aws-modules/vpc/aws”を検索し、READMEとInputs/Outputs、Requirements、バージョン履歴(CHANGELOG)を確認。メジャーバージョンの互換性に注意しつつ、~> でマイナーパッチだけ許容する形で固定します。

最小構成の例をベースに、CIDRやサブネットの設計指針は自社標準(命名規則、タグ、分割方針)に合わせて変数化します。

• Registryで対象モジュールを選定し、Verifiedと更新履歴を確認
• module.versionでSemVer制約を明示 (~> 推奨)
• terraform init で取得、plan で差分を確認、apply は承認フローに乗せる
• Outputsを使ってSGやEC2等の後段リソースに値を渡す

最小構成の例(バージョン固定とプロバイダ制約を含む)

terraform {
  required_version = ">= 1.4.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

variable "aws_region" {
  type        = string
  description = "AWS region"
  default     = "ap-northeast-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "nicheelab-main"
  cidr = "10.10.0.0/16"

  azs             = ["ap-northeast-1a", "ap-northeast-1c"]
  private_subnets = ["10.10.1.0/24", "10.10.2.0/24"]
  public_subnets  = ["10.10.11.0/24", "10.10.12.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
  tags = {
    Project = "NicheeLab"
    Env     = "dev"
  }
}

output "vpc_id" {
  value = module.vpc.vpc_id
}

Associate試験の要点と落とし穴

頻出ポイントは、Registryの参照方法(sourceアドレスの形式)、モジュールとプロバイダのバージョン固定の違い、Verified等の信頼性指標、variables/outputsの読み方、そして init/plan/apply の基本フローです。

落とし穴は、moduleのversion未指定による意図せぬアップグレード、providerのalias未設定、Requirements不一致(例えばTerraformやプロバイダの最小バージョン未達)など。

• sourceは <namespace>/<name>/<provider> を正確に記す
• moduleはversionで固定、providerはrequired_providersとlockで固定
• RegistryページのRequirements/Inputs/Outputs/Examplesを優先的に精読
• init時の -upgrade の挙動を理解し、意図しない更新を避ける

Registryからルート/子モジュール、プロバイダへの流れ

問題で確認

よくある質問