Terraformのtfstateを理解する〜VPC作成・変更から学ぶ状態管理の仕組み〜
目的
この記事の目的はTerraform におけるtfstateの役割を理解し、実際に VPC を作成・変更するハンズオンを通して、Terraform がどのようにAWSリソースの状態を管理しているのかを体験することです。
Terraform開始の準備
Terraform CLIのインストール
TerraformCLIのインストールをします。
自分の場合は昔ChocolateyというWindows向けのパッケージマネージャで、TerraformCLIをインストールしていました。
インストールは以下で行えます👇
AWS CLIのインストール・設定
AWS CLIのインストールを行います。公式インストーラをダウンロードした後にAWSマネジメントコンソールで作成したIAMユーザーの以下の認証情報を設定します。
・Access Key ID
・Secret Access Key
・利用リージョン（例: ap-northeast-1)
AWS CLIインストール公式サイトは以下👇
以下のコマンドでAWSに接続できるかを確認できます。
これができればTerraformの準備ができました。
aws sts get-caller-identity
Terraformプロジェクトを作成
今回のVPC用のプロジェクトのディレクトリを作成してmain.tfだけを記載しました。
ここではproviderブロックとしてAWSを指定してどのようなVPCを作成したいかを書きます。
この時点では main.tf を作成しただけなので、まだ 今回の主役のterraform.tfstate は存在しません。tfstate は Terraformが実際にリソースを作成・管理し始めてから生成されます。
main.tfには、プロバイダーはAWS・リージョンはap-northest1でVPCのリソースを作成するで、とだけ記載してます。
Terraform initの実行
次にmain.tfで記述した後にターミナルで初期準備コマンドのterraform initを実行してみます。
terraform init
terraform init を実行すると、.terraform ディレクトリと.terraform.lock.hcl が作成されます。これらはAWSを動かすためのProviderのインストールと、そのProviderのversionを固定するためのロックファイルができます。
initはTerraform がAWSを操作するための実行環境の準備であり、この時点ではまだリソースは作成されていないためtfstateは存在しません。
Terraform plan
次に以下のコマンドのterraform planを実行してみます。
このterraform planは、main.tfに記載された理想の状態と、現在の状態（tfstate）を比較し、
これからどのような変更を行うかを事前に表示するコマンドです。
terraform plan
ただ今はまだtfstateが作られていないので、現在の状態(tfstate)は白紙の状況です。
実際にコマンドを実行してみると、以下のような実行結果がターミナルに表示されます。
これはこれからこんなVPCを作っていくでーと記載されています。
そして、最後の行に以下が表示されます。新しく作るリソースが1つで、変更点と削除の予定は0ということがここで分かります。
Plan: 1 to add, 0 to change, 0 to destroy.
Terraform applyの実行
次に、terraform applyを実行してみましょう。
これは、terraform planで確認した変更内容を実際にクラウド上に反映するコマンドです。
terraform apply
つまり、main.tfで記述したVPCをこのコマンドで作成できます。
そうすると以下のようにほんまに作成してよいんか?と聞かれるのでyesと記載します。
そうすると...VPCが作成できたようです!
実際にAWSコンソール上で確認してみます。
ちゃんといました。すごすぎます。
また、今のapply実行後に今回の主役のtfstateというのができています。
中身はJSONで今のVPCを作成したものの設定値としての値が記載されています。
作成したVPCのタグを変えてtfstateの効果を確認
main.tfのVPCのタグのところをv2というのを後ろにつけて、少し変更してみました。
それを踏まえてterraform planを行ってみます。
そうすると先ほどとは違い、新規作成ではなく変更のところに1と出てきます。
tfstate ファイルのJSONにすでにこんなVPCが存在するでと記録されているため、
Terraform は"新しく作る"のではなく"既存の VPC を変更する"と判断したということです。
これがtfstateの効果で、もしterraform君が何を作成したか覚えてなかったらまた新規作成でVPCを作成していたはずだからです。
ではそれを踏まえてterraform applyを実行してみましょう。
そうすると今度はchangeのところに1となり変更が適応されていることが分かります。
AWSコンソール上で確認してみましょう。
無事にタグが変更されており、tfstate-handson-vpc-v2となっています!
tfstateのJSONでのタグも変更されていることが分かりました!
今回学んだこと-まとめ
今回の検証結果
- 初回terraform applyではVPCが新規作成され、tfstateが生成された。
⇩ その後、VPC のタグのみを変更したところ - terraform plan で「新規作成」ではなく「変更」と判定された
tfstate を基準に Terraform がAWSリソースの状態を判断していることを確認できました。
今回学んだことを可視化して図にしてみました。
tfstateがあるからこそ、既存リソースを不用意に作り直すことなく、必要最小限の変更を安全に適用できるようになっているのだと理解しました。
Discussion