Terraform Associate 004 #3 Terraform の基本 — バージョン制約、ロックファイル、provider 設定

読了 4分

今回の範囲は Terraform と provider を「準備する」領域です。実務では一度設定したら忘れる部分だからこそ、試験直前に揺らぎやすく、特にバージョン制約演算子の読み方とロックファイルの役割は、問題製造機と呼んでいいほど頻出です。基礎 #1のインストールと基礎 #2のブロック文法を、試験の角度から見直します。

インストールとバージョン確認 #

Terraform は単一バイナリなのでインストールは単純です。試験の観点で要点だけ絞ると、公式の配布チャネル(パッケージマネージャーまたはバイナリダウンロード)でインストールして terraform version で確認すること、そして複数のプロジェクトが異なる Terraform バージョンを要求する場合のためにバージョン管理ツール(tfenv 系)が存在すること、この程度です。出題の重みはインストール自体ではなく、次の節のバージョン指定にかかっています。

バージョン制約演算子 — ~> を読めなければなりません #

terraform ブロックと required_providers で使う制約の文法です。

main.tf
terraform {
  required_version = ">= 1.12.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
演算子意味例
= 6.2.0(または 6.2.0)正確にこのバージョンだけ6.2.0 のみ許可
>= 6.2以上6.2 以降すべて
>= 6.2, < 7.0範囲の組み合わせカンマは AND
~> 6.2最後の桁だけ増加を許可6.2、6.3、… 6.x を許可、7.0 は不可
~> 6.2.0最後の桁だけ増加を許可6.2.0〜6.2.x を許可、6.3 は不可

試験の定番は波形(pessimistic)演算子 ~> です。核心のルールは明示した最後の桁だけが上がれるというもので、~> 6.2 と ~> 6.2.0 が許可する範囲は異なる、という点まで区別する必要があります。「メジャーアップグレードの破壊的変更は防ぎつつ、マイナー・パッチは受け取る」という実務上の意図がこの演算子の存在理由であり、基礎と実践を通してずっと ~> 6.0 を使っていた理由でもあります。

ロックファイル — 制約と固定の区別 #

バージョンに関わる 2 つのファイルの役割の区別が、この領域の 2 つ目の定番です。

  • required_providers の version: 許可する範囲の宣言です。人間が書きます。
  • .terraform.lock.hcl: init がその範囲の中から実際に選んだ正確なバージョンとチェックサムの記録です。Terraform が生成します。

範囲が ~> 6.0 でも、ロックファイルが 6.4.1 を記録していれば、チーム全員と CI は 6.4.1 を使います。だからロックファイルはバージョン管理にコミットすべきファイルです(基礎 #5で state はコミット禁止、ロックファイルはコミットと区別した、まさにその内容が出題ポイントです)。制約の範囲内で最新に上げたいときに使うコマンドが terraform init -upgrade である、というところまでがワンセットです。

provider 設定と alias #

provider ブロックは認証情報やリージョンといった接続設定を持ちます。試験ポイントは 2 つです。

  1. 同じ provider を複数の設定で使う: alias を付けて登録し、リソース側で provider = aws.us_east_1 と指定します。実践 #10で CloudFront の証明書のために us-east-1 を併用した構成が、まさにこの問題の実物です。
main.tf
provider "aws" {
  region = "ap-northeast-2"
}

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}
  1. 認証情報をコードに書かない: provider ブロックにアクセスキーをハードコードする選択肢は常に不正解です。環境変数、共有認証情報ファイル、IAM ロールといった外部からの注入が正解の方向です。

.terraform ディレクトリ — init が作るもの #

「init 後に生まれるもの」を問う問題への備えとして、区別しておきます。

生成物内容コミットするか
.terraform/ダウンロードした provider プラグイン、モジュールキャッシュ、バックエンド設定コミットしない(.gitignore)
.terraform.lock.hclprovider のバージョン・チェックサムの固定コミットする

.terraform/ はいつでも init で再生成できるローカルキャッシュという性質、ロックファイルはチームの再現性を守る共有記録という性質、この対比が答えの根拠になります。

まとめ #

今回扱った内容です。

  • バージョン制約の核心は ~> です。明示した最後の桁だけ増加を許可し、~> 6.2 と ~> 6.2.0 の範囲の違いを区別します
  • required_providers は許可範囲、.terraform.lock.hcl は実際に選んだバージョンの固定です。ロックファイルはコミットし、更新は init -upgrade です
  • 同じ provider の複数設定は alias で行い、リソース側で provider 引数を指定します
  • 認証情報をハードコードする選択肢は常に不正解です。外部からの注入が正解の方向です
  • .terraform ディレクトリは再生成可能なローカルキャッシュなのでコミットしません

次回(#4 コアワークフロー)では、試験の中心領域である init、plan、apply、destroy のサイクルと各コマンドのオプション、そしてデバッグログの設定を扱います。

X