terraform-lt-outline.pdf

Transcript

1. terraform apply の中で何が起きているのか terraform apply の中で 何が起きているのか 1
2. terraform apply の中で何が起きているのか この2つ、心当たりありませんか コンソールで直した設定が、次の plan で元に戻されそうになる 既存リソースをコードに書いたら already exists で apply が落ちる 2
3. terraform apply の中で何が起きているのか 今日話すこと 1. 登場人物は3人（コード / State / 実リソース） 2. apply で何をしているのか 3. なぜ作成順序が守られるのか → 最後に冒頭の2つの謎を回収します 3
4. terraform apply の中で何が起きているのか 1. 登場人物は3人 4
5. terraform apply の中で何が起きているのか コード・State・実リソース コード（.tf） あるべき姿 diff State Terraformの認識 refresh 実リソース 現実のAWS apply 登場人物 役割 コード（.tf） あるべき姿の宣言 State（tfstate） Terraform が把握している現状。 実リソース（AWS） 現実にあるもの 5
6. terraform apply の中で何が起きているのか State ファイルの中身 { } "version": 4, "terraform_version": "1.9.0", "resources": [ { "type": "aws_instance", "name": "web", "instances": [ { "attributes": { "id": "i-0123456789abcdef0", "instance_type": "t3.micro", "ami": "ami-0abcdef1234567890" } } ] } ] 6
7. terraform apply の中で何が起きているのか State が管理する範囲 Stateが把握しているのは そのstateファイルに書き込まれたリソースだけ（アカウ ント/リージョン全体ではない） コンソールで新規作成したリソース → どのstateにも載らない「野良リソース」に なる（ドリフトとは別物） 1アカウントで複数stateに分けていても、基本的には互いに影響しない 例外: terraform_remote_state で明示的に繋いでいる場合、または AWS側の制 約（グローバル一意な名前・アカウント単位のリソース上限）を介して間接的に 衝突する場合がある 7
8. terraform apply の中で何が起きているのか 2. apply で何をしているのか 8
9. terraform apply の中で何が起きているのか apply の4ステップ 1. 依存グラフを構築 — コードを読み込み、リソース間の依存関係を解析する 2. refresh — 実 API を叩いて現状を取得し、State を実態に合わせる 3. diff — コードと refresh 後の State を比較し、変更内容を計算する（ + create / ~ update / - destroy ） 4. apply — 実際に変更を加え、結果を State に書き戻す → plan はこの 1〜3で止まる読み取り専用の操作 9
10. terraform apply の中で何が起きているのか ignore_changes の実際の挙動 plan の差分計算からのみ属性を除外する create 時には効かない — 初回 apply では config の値が使われる refresh は通常どおり走り、State は実態に更新されうる（リソース依存） 初回 apply で PLACEHOLDER を撒くと、それを参照する下流リソースにも PLACEHOLDER が流れる。ただし次の apply で解消される 10
11. terraform apply の中で何が起きているのか 3. なぜ順序が守られるのか 11
12. terraform apply の中で何が起きているのか 依存グラフ リソース参照（ aws_vpc.main.id ）が暗黙の依存を作る Terraform は plan の時点で依存グラフを構築する apply はそのグラフの順に変更を実行する（依存のないリソースは並列に実行） 参照がないのに順序が要る場合だけ depends_on 12
13. terraform apply の中で何が起きているのか 4. 冒頭の謎を回収する 13
14. terraform apply の中で何が起きているのか 謎1: コンソールの変更が戻される ドリフト = 実リソースだけが動いた状態 1. refresh が実リソースの現状を State に取 り込む 2. diff でコードと比較 → コードの方が 「正」 3. コードの状態に戻す plan が出る → Terraform 管理下のリソースを手で触ると、 こうなる 実リソース 現実のAWS apply コード（.tf） あるべき姿 refresh diff State Terraformの認識 14
15. terraform apply の中で何が起きているのか 謎2: already exists で落ちる 実リソースはあるが、State に無い状態 Terraform は「知らないから作ろう」とす る → 実際にはもうある → 衝突 解決策: import して State に登録する 実リソース 現実のAWS apply コード（.tf） あるべき姿 refresh diff State Terraformの認識 15
16. terraform apply の中で何が起きているのか backup: 参考資料 コード・State・実リソースの三者関係（Qiita） Terraform state 概論（chroju.dev） AWS 規範ガイダンス: Terraform モジュールについて Terraform モジュール構成のベストプラクティス（ENECHANGE） 16