TerraformのGoogle SKillsをやってみた
Google SkillsでTerraformとGoogle Cloudを扱う学習をした。この記事は、そこで考えたインフラ管理のポイントを、自分用に整理したメモ。
公開にあたって: 教材の設問、指定値、解答、採点条件、画面は再現していません。内容をぼかし、以下の設定例も独自の学習用サンプルに置き換えています。ラボの解答ではなく、実環境での動作や採点結果も確認していません。
既存リソースを管理対象にするとき
既存の仮想マシンをTerraformで管理する場合、クラウド上の実体、設定ファイル、Stateの対応関係を区別して考える。importは既存リソースをStateに関連付ける操作であり、CLIによるインポートだけで設定ファイルが完成するわけではない。取り込み後もterraform planで意図しない変更や再作成がないか確認する。
以下は書式のイメージ。リソースID、構成値、インポート先アドレスは対象環境に合わせて確認する。これだけで実行できる完成形ではない。
# 既存VMに対応する設定の例。実機の設定に合わせて項目を補う。
resource "google_compute_instance" "existing_example" {
name = "example-existing-vm"
machine_type = var.machine_type
zone = var.zone
boot_disk {
initialize_params {
image = var.boot_image
}
}
network_interface {
network = var.network_name
}
}
# 取り込み先のアドレスと、既存リソースのIDを対応させる例。
import {
to = google_compute_instance.existing_example
id = "projects/EXAMPLE_PROJECT/zones/EXAMPLE_ZONE/instances/example-existing-vm"
}
importブロックを利用できるTerraformのバージョンや、対象リソースのID形式は公式ドキュメントで確認する。
Stateの保存先を考える
Stateは、Terraformの設定と実際のリソースの対応を記録する。共有して運用する場合は保存先、アクセス権、バックアップ方法を先に決めたい。GCSバックエンドを使うなら、保存先のバケットをバックエンドの初期化前に用意する必要がある。バケットのオブジェクトバージョニングも復旧に備えた検討事項になる。
# 既に存在する、適切に保護されたバケットを指定する書式例。
terraform {
backend "gcs" {
bucket = "example-terraform-state-bucket"
prefix = "practice/environment-a"
}
}
保存先を切り替えた後は、どのStateを参照しているかを確認してから変更を適用する。管理対象が突然すべて新規作成として表示された場合、そのプランは適用せず、バックエンド設定、ワークスペース、Stateの内容とバックアップを調べる。Stateファイル、バックアップ、認証情報、保存済みプランは公開リポジトリに置かない。
モジュールとバージョンの扱い
ネットワークのような構成をモジュール化するときは、入力値だけでなく、Terraform本体、モジュール、プロバイダのバージョン要件を確認する。依存関係の更新後にエラーが出ても、すぐにStateからリソースを外して再インポートする、という手順にはしない。
terraform state rmはクラウド上の実体を削除せず、State上の紐付けを外す操作。設定が残っていれば、次のプランで新規作成が提案される場合がある。バージョンの問題はエラー内容と公式資料を確認し、変更前のStateを保護したうえで対処を判断する。
ネットワーク設定で気を付けること
VPCやサブネットを追加する際は、アドレス範囲の重複、VMの接続先変更による影響、ファイアウォールの適用対象を確認する。受信ルールは、送信元・対象・プロトコル・ポートを必要な範囲に限定する。学習用の設定をそのまま実運用へ持ち込まない。
まとめ
今回の学習では、コマンドを実行する前に設定ファイル、State、実リソースの三者がどう対応しているかを確認することが重要だと感じた。特にインポート、バックエンド変更、依存関係の更新、リソース削除では、プランの変更対象を読んでから判断する。
※ このメモは教材の利用条件や画像の権利について判断するものではありません。公開する場合は、教材の転載やスクリーンショットの扱いを別途確認してください。