Terraform Associate 004 #3 Terraform の基本 — バージョン制約、ロックファイル、provider 設定
今回の範囲は Terraform と provider を「準備する」領域です。実務では一度設定したら忘れる部分だからこそ、試験直前に揺らぎやすく、特にバージョン制約演算子の読み方とロックファイルの役割は、問題製造機と呼んでいいほど頻出です。基礎 #1のインストールと基礎 #2のブロック文法を、試験の角度から見直します。
インストールとバージョン確認 #
Terraform は単一バイナリなのでインストールは単純です。試験の観点で要点だけ絞ると、公式の配布チャネル(パッケージマネージャーまたはバイナリダウンロード)でインストールして terraform version で確認すること、そして複数のプロジェクトが異なる Terraform バージョンを要求する場合のためにバージョン管理ツール(tfenv 系)が存在すること、この程度です。出題の重みはインストール自体ではなく、次の節のバージョン指定にかかっています。
バージョン制約演算子 — ~> を読めなければなりません #
terraform ブロックと required_providers で使う制約の文法です。
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 つです。
- 同じ provider を複数の設定で使う:
aliasを付けて登録し、リソース側でprovider = aws.us_east_1と指定します。実践 #10で CloudFront の証明書のために us-east-1 を併用した構成が、まさにこの問題の実物です。
provider "aws" {
region = "ap-northeast-2"
}
provider "aws" {
alias = "us_east_1"
region = "us-east-1"
}- 認証情報をコードに書かない: provider ブロックにアクセスキーをハードコードする選択肢は常に不正解です。環境変数、共有認証情報ファイル、IAM ロールといった外部からの注入が正解の方向です。
.terraform ディレクトリ — init が作るもの #
「init 後に生まれるもの」を問う問題への備えとして、区別しておきます。
| 生成物 | 内容 | コミットするか |
|---|---|---|
.terraform/ | ダウンロードした provider プラグイン、モジュールキャッシュ、バックエンド設定 | コミットしない(.gitignore) |
.terraform.lock.hcl | provider のバージョン・チェックサムの固定 | コミットする |
.terraform/ はいつでも init で再生成できるローカルキャッシュという性質、ロックファイルはチームの再現性を守る共有記録という性質、この対比が答えの根拠になります。
まとめ #
今回扱った内容です。
- バージョン制約の核心は
~>です。明示した最後の桁だけ増加を許可し、~> 6.2と~> 6.2.0の範囲の違いを区別します - required_providers は許可範囲、.terraform.lock.hcl は実際に選んだバージョンの固定です。ロックファイルはコミットし、更新は init -upgrade です
- 同じ provider の複数設定は alias で行い、リソース側で provider 引数を指定します
- 認証情報をハードコードする選択肢は常に不正解です。外部からの注入が正解の方向です
- .terraform ディレクトリは再生成可能なローカルキャッシュなのでコミットしません
次回(#4 コアワークフロー)では、試験の中心領域である init、plan、apply、destroy のサイクルと各コマンドのオプション、そしてデバッグログの設定を扱います。