3章 Terraformのコマンドを利用する
主要コマンド
terraform init: カレントディレクトリを作業ディレクトリして初期化するコマンド
Terraform の開発を始める時や、既存リポジトリをクローンしてきた際に実行する
ステートを保管するためのバックエンドを初期化する処理もこのとき走る
デフォルトだとローカルディスク
特定のクラウドサービスのインフラを構成する場合には、以下のようにプロバイダをあらかじめ指定してコマンドを実行する必要がある
warning.icon プロバイダを追加するたびに init コマンドの実行が必要
code:provider.tf
provider "aws" {
region = "ap-northeast-1"
}
ただし、このまま指定すると開発者間での統制が取れなくなるので、プロバイダのバージョン、取得リポジトリ、Terraform 本体のバージョンを tf ファイルに定義することが多い
code:versions.tf
terraform {
required_version = "~> 1.2.8"
required_providers {
aws = {
source = "hashicorp/aws"
version = "4.10.0"
}
}
}
バージョンは値のみだと完全一致、~> を付けるとパッチバージョンの違いは許容する
-upgrade フラグを付けると、プロバイダのバージョンアップをするが、terraform ブロックで記述している required_providers の内容は 自動で修正されない
terraform fmt: tf ファイルのフォーマット
terraform validate: tf ファイルが有効かチェックする
terraform plan: ステートに記録されている現在の状態と、コードから導かれる設定の差分を示す
差分 = データソースの読み取り、リソースの作成・変更・削除
-target オプションを指定すると、特定のリソースの差分のみ確認できる
$ terraform plan -target=module.ecr.aws_ecr_lifecycle_policy.policy
warning.icon -target はエラー解消目的で利用するためのものなので、常時利用するものではない
-out オプションを指定すると、差分ファイルを作成できる
生成した差分ファイルを apply に渡すと、plan の結果を確実反映できる
-destroyフラグを付けると、destroy 実行時の差分を確認できる
terraform apply: ファイルの内容に沿って、実際にインフラを構成するリソースの構築・変更・削除する
-auto-approve フラグを付けると、yes を入力するのをスキップできる
-parrallelism オプションを指定すると、並列度 を指定できる
リソース同士の依存関係が、内部のリソース作成に問題がない限り並列化が可能
$ terraform apply -parrallelism=6
terraform destroy: 構築されたリソースを削除する
terraform apply -destroy のエイリアス
そのため、-auto-approve など apply のフラグ / オプションが使える
terraform import: 構築済みリソースを Terraform で管理する
$ terraform import ステート中のアドレス リソースのID
ステート中のアドレスには、terraform state show や terraform state list で表示される値を指定する
リソースの ID には、リソースの種類によって異なるので、Terraform プロバイダとそのリソースの公式ドキュメントを参照する必要がある
ステートを管理するためのコマンド
terraform state list: ステートに含まれるリソースの一覧表示
terraform state show: ステートに含まれる個々のリソースを確認する
$ terraform state show module.iam_role.aws_iam_role_policy.inline_policies\"ImagePush\"
terraform state mv: ステートで管理されているリソースのアドレスを変更する
code:.tf
resource "aws_iam_role" "role" {...} # 変更前
resource "aws_iam_role" "new_role" {...} # 変更後
変更後に apply コマンドを実行すると、role を削除した上で、new_role を作成する
しかし、terraform state mv を使うと、リソースを再作成することなくアドレスを付け替えることが可能
このコマンドの代わりに moved ブロックを使うことも可能
code:.tf
moved {
from = aws_iam_role.role
to = aws_iam_role.new_role
}
resource "aws_iam_role: "new_role" {...}
terraform state rm: ステートに含まれる特定のリソースを削除する
terraform import とセットで利用することが多い
e.g. IAM ロールを他のステートに付け替える
https://gyazo.com/02e10aabfca9c1d770b78f6d5d6f1c16
このコマンドの代わりに removed ブロックを使うことも可能
code:.tf
removed {
from = aws_iam_role.role
lifecycle {
destroy = false
}
}
ステートの管理場所
デフォルトではローカルディスク上にファイルとして保存される
チーム開発を進める場合、S3 のバケットなどで管理する
warning.icon 複数人で同時に apply コマンドを実行すると、ステートの 一貫性 が失われる
これを避けるために 排他制御 が必要となるが、AWS では Amazon DynamoDB を使うことが多い
code:.tf
terraform {
backend "s3" {
bucket = "バケット名"
key = "ステートのキー(= ファイルパス)"
region = "バケットのリージョン"
dynamo_db_table = "排他制御に利用する DynamoDB テーブル"
}
}
が、v1.11 以降では S3 バックエンドだけでロック管理が可能になった
code:.tf
terraform {
backend "s3" {
bucket = "バケット名"
key = "ステートのキー(= ファイルパス)"
region = "バケットのリージョン"
use_lockfile = true
}
}
ワークスペースの管理
terraform workspace new: ワークスペースを作成する時に実行する
init コマンド直後のワークスペースは default のみ
terraform workspace list: ワークスペースの一覧と現在のワークスペースを確認する
terraform workspace select: 現在のワークスペースを切り替える
terraform workspace delete: ワークスペースを削除する
default は削除できない
コード上からワークスペース名にアクセスする
terraform.workspace で参照可能
code:.tf
resource "aws_s3_bucket" "bucket" {
bucket = "sample-bucket-${terraform.workspace}"
tags {
env = terraform.workspace
}
}
活用方法
同一の tf ファイル・バックエンド設定を使って複数環境を作成できる
count と terraform.workspace を組み合わせ、リソース作成の有無を切り替える
code:.tf
resource "リソース種別" "リソース名" {
count = terraform.workspace == "prod" ? 1 : 0
...
}
warning.icon 上記のようなコードが大量に発生するとコードが複雑になるため、あるリソースだけを管理するための tf ファイルとステートを別に準備する など、コードの構成を見直した方が良い
https://gyazo.com/28ddb9825154578b69c035f5f32003aa
#Terraform #読書メモ