HCL, Provider และ Resource

ไอเดียในหนึ่งประโยค

configuration ของ Terraform ทุกส่วนคือ block เขียนด้วย HCL — terraform, provider, resource และ data คือสี่ตัวที่คุณจะเขียนบ่อยที่สุด รวมกันแล้วสี่ตัวนี้บอก Terraform ว่าต้องโหลด plugin อะไร คุยกับ Azure ยังไง ต้องสร้างอะไร และต้องอ่านอะไร

HCL block syntax

HCL (HashiCorp Configuration Language) สร้างจาก block รูปแบบทั่วไปคือ block type ตามด้วย label ที่ครอบด้วยเครื่องหมายคำพูดศูนย์ตัวขึ้นไป แล้วปิดท้ายด้วย body ของ argument ใน {}

block_type "label1" "label2" {
  argument = value
}

อย่าง resource block มี label สองตัว ส่วน provider block มี label ตัวเดียว comment ใช้ # หรือ // สำหรับบรรทัดเดียว และ /* */ สำหรับหลายบรรทัด string รองรับ interpolation ด้วย ${...} แต่ถ้าอ้างอิงค่าอื่นตรง ๆ (name = azurerm_resource_group.main.name) ไม่ต้องครอบด้วย ${} — syntax แบบนั้นใช้เฉพาะตอนอยู่ข้างใน string ที่ยาวกว่านั้น

# A single-line comment.
// Also a single-line comment.

resource "azurerm_resource_group" "main" {
  name     = "example-resources-${var.environment}" # interpolation inside a string
  location = "East US"
}

terraform block กับ provider block

terraform block คือการตั้งค่า Terraform เอง ว่า Terraform เวอร์ชันไหนรัน configuration นี้ได้ และต้องใช้ provider อะไรบ้าง รวมถึงแต่ละ provider มาจากไหนและเวอร์ชันไหนที่รับได้

terraform {
  required_version = ">= 1.11.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 5.0"
    }
  }
}

source คือ registry address ของ provider (hashicorp/azurerm ชี้ไปที่ Azure provider ตัวจริงบน Terraform Registry) ส่วน version เป็น constraint ไม่ใช่การ pin ตายตัว — ~> 5.0 อนุญาตทุก release ในสาย 5.x

จากนั้น provider block ตั้งค่า instance หนึ่งของ provider ที่ประกาศไว้ด้านบน สำหรับ azurerm ตรงนี้คือที่อยู่ของ subscription — และมี quirk ที่รู้กันดีที่ควรพูดถึงตรง ๆ คือ features {} block เป็นสิ่งที่จำเป็นต้องมี แม้จะว่างเปล่าก็ตาม การไม่ใส่เลยเป็นหนึ่งใน error แรก ๆ ที่คนใหม่มักเจอกับ provider ตัวนี้

provider "azurerm" {
  features {}

  subscription_id = "00000000-0000-0000-0000-000000000000"
}

resource block: สอง label ที่มีความหมาย และทำไม Azure ต้องมี resource group

resource block คือวิธีบอก Terraform ว่า “สิ่งนี้ควรมีอยู่” resource block มี label สองตัวเสมอ resource เกือบทุกตัวใน Azure ต้องอยู่ภายใน resource group — เป็น container/scoping construct ที่รวม resource ที่เกี่ยวข้องกันไว้ด้วยกัน คุม lifecycle ร่วมกันเป็นก้อนเดียว และไม่มี equivalent ตรง ๆ ใน AWS หรือ GCP (การจัดกลุ่มด้วย tag ใน AWS ไม่มีการบังคับใด ๆ อยู่เบื้องหลัง ส่วน GCP project ก็เป็น boundary ที่หนักกว่ามาก) นั่นทำให้ azurerm_resource_group เป็น resource แรกในเกือบทุก configuration ของ Azure

resource "azurerm_resource_group" "main" {
  name     = "example-resources"
  location = "East US"
}

• label แรก azurerm_resource_group คือ type ของ resource ถูกกำหนดโดย provider และเป็นตัวตัดสินว่า argument ไหนใช้ได้ และ Azure API ตัวไหนที่ Terraform จะเรียก
• label ที่สอง main คือ name ที่คุณเลือกเอง มีความหมายแค่ภายใน configuration นี้เท่านั้น

รวมกันแล้วทั้งสองตัวคือ address ของ resource นั้น คือ azurerm_resource_group.main ที่ใช้อ้างอิง attribute ของ resource นี้จากที่ไหนก็ได้ใน configuration ของคุณ

resource "azurerm_linux_virtual_machine" "web" {
  name                = "web-vm"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_B1s"
  admin_username      = "adminuser"

  network_interface_ids = [
    azurerm_network_interface.web.id, # defined elsewhere in this configuration
  ]

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }
}

การอ้างอิง azurerm_resource_group.main.name และ azurerm_resource_group.main.location จาก VM resource คือ implicit dependency แบบเป๊ะ ๆ ที่สร้าง dependency graph ของ Terraform ตามที่จะพูดถึงด้านล่าง — ตอนนี้ Terraform รู้แล้วว่า resource group ต้องมีอยู่ก่อนถึงจะสร้าง VM ได้

data block: อ่านโดยไม่เป็นเจ้าของ

data block อ่านข้อมูลของสิ่งที่มีอยู่แล้ว คือ infrastructure ที่ configuration นี้ไม่ได้จัดการและจะไม่มีวันสร้าง อัปเดต หรือลบ นี่คือ read-only lookup ของ Terraform

data "azurerm_resource_group" "existing" {
  name = "networking-shared"
}

resource "azurerm_virtual_network" "app" {
  name                = "app-vnet"
  address_space       = ["10.0.0.0/16"]
  resource_group_name = data.azurerm_resource_group.existing.name
  location            = data.azurerm_resource_group.existing.location
}

data.azurerm_resource_group.existing.location อ่านเหมือน resource address เป๊ะ ๆ แค่มี data. นำหน้า — label type กับ name ทำงานแบบเดียวกัน แต่ไม่มีอะไรจาก data block ที่จะโผล่เป็น create, update หรือ destroy ใน plan เลย เพราะมีหน้าที่อ่านอย่างเดียว

Dependency graph

Terraform ไม่ได้ apply configuration ของคุณเรียงจากบนลงล่างตามที่เขียนไว้ แต่สร้าง DAG (directed acyclic graph) ของทุก resource และ data source แล้วใช้กราฟนั้นหาลำดับที่ถูกต้อง — พร้อมทั้งดูว่า resource ตัวไหนเป็นอิสระจากกันพอที่จะสร้าง พร้อมกัน ได้

edge ในกราฟนั้นมาจากสองที่

• Implicit dependency เมื่อไหร่ที่ argument ของ resource หนึ่งอ้างอิง attribute ของอีก resource หนึ่ง (เช่น VM อ้างอิง azurerm_resource_group.main.name หรือ subnet อ้างอิงชื่อของ virtual network) Terraform จะสรุปเองว่า resource ที่ถูกอ้างอิงต้องมีอยู่ก่อน
• Explicit dependency คือ depends_on บน resource ใช้ตอนที่ resource หนึ่งขึ้นกับอีกตัวจริง ๆ แต่ความสัมพันธ์นั้นไม่โผล่ผ่าน attribute reference ไหนเลย (เช่น role assignment ที่ต้องมีอยู่ก่อนแอปเริ่มพึ่งพา โดยไม่มี argument เชื่อมกันตรง ๆ)

resource "azurerm_resource_group" "main" {
  name     = "example-resources"
  location = "East US"
}

resource "azurerm_virtual_network" "main" {
  name                = "example-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.main.location # implicit dependency on azurerm_resource_group.main
  resource_group_name = azurerm_resource_group.main.name
}

resource "azurerm_subnet" "app" {
  name                 = "app-subnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name # implicit dependency on azurerm_virtual_network.main
  address_prefixes     = ["10.0.1.0/24"]
}

flowchart LR
  rg["azurerm_resource_group.main"] --> vnet["azurerm_virtual_network.main"] --> subnet["azurerm_subnet.app"] --> vm["azurerm_linux_virtual_machine.web"]
  storage["azurerm_storage_account.logs (unrelated, applies in parallel)"]

Terraform สร้าง DAG จาก reference แล้ว apply กิ่งที่เป็นอิสระต่อกันพร้อมกัน

lifecycle block: เปลี่ยนพฤติกรรม default ของ Terraform

ทุก resource รับ lifecycle block เป็นตัวเลือกได้ ซึ่งเปลี่ยนวิธีที่ Terraform plan การเปลี่ยนแปลงสำหรับ resource นั้นตัวเดียว โดยไม่เกี่ยวกับส่วนอื่นใน configuration argument สี่ตัวครอบคลุมความต้องการจริงแทบทั้งหมด

prevent_destroy เปลี่ยนการ destroy ที่ plan ไว้ให้กลายเป็น error หนัก ๆ แทนที่จะปล่อยให้ดำเนินต่อ — ราวกั้นความปลอดภัยสำหรับ resource ที่ต้องไม่ถูกลบโดยไม่ตั้งใจเด็ดขาด:

resource "local_file" "protected" {
  filename = "${path.module}/protected.txt"
  content  = var.content

  lifecycle {
    prevent_destroy = true
  }
}

Error จริงจาก terraform plan -destroy กับบล็อกเดียวกันเป๊ะข้างบน:

$ terraform plan -destroy
Plan: 0 to add, 0 to change, 1 to destroy.
╷
│ Error: Instance cannot be destroyed
│
│   on main.tf line 10:
│   10: resource "local_file" "protected" {
│
│ Resource local_file.protected has lifecycle.prevent_destroy set, but the
│ plan calls for this resource to be destroyed. To avoid this error and
│ continue with the plan, either disable lifecycle.prevent_destroy or reduce
│ the scope of the plan using the -target option.
╵

สังเกตว่า Terraform ยังคำนวณ plan อยู่ (Plan: 0 to add, 0 to change, 1 to destroy พิมพ์ก่อน) — prevent_destroy ถูกเช็คและหยุดการทำงานหลังจาก plan ตัดสินใจแล้วว่าต้อง destroy เท่านั้น ไม่ใช่ก่อนหน้านั้น

create_before_destroy สลับลำดับ replace default ปกติแล้วการ replace resource คือ destroy-แล้ว-create (-/+ ใน plan); เมื่อตั้งค่านี้ Terraform จะสร้างตัวแทนก่อน แล้วค่อย destroy ตัวเก่าหลังจากตัวใหม่มีอยู่แล้ว — จำเป็นมากสำหรับอะไรก็ตามที่ช่วงเวลา “ไม่มีทั้งคู่” ยอมรับไม่ได้ อย่าง azurerm_linux_virtual_machine ที่อยู่หลัง load balancer

resource "local_file" "app" {
  filename = "${path.module}/app-${var.content}.txt"
  content  = var.content

  lifecycle {
    create_before_destroy = true
  }
}

Plan จริงหลังเปลี่ยน var.content (ซึ่งบังคับให้ filename เปลี่ยนตามไปด้วย และ filename บังคับให้ replace):

$ terraform plan
  # local_file.app must be replaced
+/- resource "local_file" "app" {
      ~ content  = "v1" -> "v2" # forces replacement
      ~ filename = "./app-v1.txt" -> "./app-v2.txt" # forces replacement
        # (2 unchanged attributes hidden)
    }
Plan: 1 to add, 0 to change, 1 to destroy.

สัญลักษณ์คือตัวบ่งชี้: +/- (create แล้ว destroy) แทน -/+ default (destroy แล้ว create) ที่เห็นทั่วทั้งคอร์สนี้ create_before_destroy เปลี่ยนแค่สัญลักษณ์ลำดับนั้น ไม่เปลี่ยนจำนวนบรรทัดของ plan เลย

ignore_changes บอก Terraform ให้เลิกมองการเปลี่ยนแปลงของ argument เฉพาะเป็น drift — มีประโยชน์เมื่อบางอย่างนอก Terraform (autoscaler, คนแก้ tag ใน Azure Portal) คาดว่าจะเปลี่ยนค่า และการยืนยันค่าเดิมซ้ำทุก apply จะไปขัดกับมัน

resource "terraform_data" "app" {
  input = {
    tags = { managed_by = "terraform" }
  }
  lifecycle {
    ignore_changes = [input]
  }
}

Plan จริงหลังเปลี่ยน input ใน configuration เอง:

$ terraform plan
No changes. Your infrastructure matches the configuration.

ถ้าไม่มี ignore_changes = [input] การแก้คอนฟิกแบบเดียวกันนั้นจะ plan update จริง แต่มีมันแล้ว Terraform ไม่เทียบ input ปัจจุบันกับค่าคอนฟิกใหม่สำหรับ argument นั้นเลยด้วยซ้ำ — การเปลี่ยนแปลงมองไม่เห็นสำหรับ plan ไม่ใช่แค่ปล่อยให้เกิดครั้งเดียวแล้วค่อย track ใหม่

replace_triggered_by (อธิบายลึกพร้อมพิสูจน์จริงในบท Count and For Each) บังคับให้ resource ถูก replace ทุกครั้งที่ค่าที่อ้างอิงเปลี่ยน แม้ argument ของ resource เองจะไม่เปลี่ยนเลย — ปัญหาตรงข้ามกับ ignore_changes: แทนที่จะซ่อนการเปลี่ยนแปลง มันสร้างการ replace ขึ้นมาจากการเปลี่ยนแปลงที่ปกติมองไม่เห็นสำหรับ resource นี้

terraform graph output จริง

terraform graph พิมพ์ dependency graph จริงที่ Terraform คำนวณ — ไม่ใช่คำอธิบาย แต่เป็น DOT output จริงที่ GraphViz (หรือเครื่องมืออ่าน DOT ไหนก็ได้) render ได้ตรง ๆ รันโดยไม่มี -type จะได้ resource-level summary graph เป็น default ซึ่งอ่านด้วยตาเปล่าง่ายที่สุด และไม่ต้องมี Azure credentials เลย — มันไม่เรียก Azure API เลย เพียงแค่ resolve reference ที่มีอยู่แล้วในคอนฟิก:

$ terraform graph
digraph G {
  rankdir = "RL";
  node [shape = rect, fontname = "sans-serif"];
  "azurerm_resource_group.logs" [label="azurerm_resource_group.logs"];
  "azurerm_resource_group.main" [label="azurerm_resource_group.main"];
  "azurerm_subnet.app" [label="azurerm_subnet.app"];
  "azurerm_virtual_network.main" [label="azurerm_virtual_network.main"];
  "azurerm_subnet.app" -> "azurerm_virtual_network.main";
  "azurerm_virtual_network.main" -> "azurerm_resource_group.main";
}

นั่นคือกราฟจริงของ azurerm_resource_group.main → azurerm_virtual_network.main → azurerm_subnet.app บวกกับ resource group ตัวที่สองที่ไม่เกี่ยวข้องกัน azurerm_resource_group.logs — อ่านตาม rankdir = "RL" (ขวาไปซ้าย) edge A -> B หมายถึง “A ขึ้นกับ B” ตรงกับเหตุผลเรื่อง implicit dependency จากหัวข้อก่อนหน้าเป๊ะ: azurerm_subnet.app ขึ้นกับ azurerm_virtual_network.main ซึ่งขึ้นกับ azurerm_resource_group.main azurerm_resource_group.logs ไม่มี edge เข้าหรือออกจากอะไรเลย ซึ่งเป็นเหตุผลที่ Terraform สร้างมันพร้อมกับ chain ของ networking ได้อย่างอิสระ

flowchart RL
  subnet["azurerm_subnet.app"] --> vnet["azurerm_virtual_network.main"]
  vnet --> rg["azurerm_resource_group.main"]
  logs["azurerm_resource_group.logs (no edges: parallel)"]

dependency graph เดียวกันที่ terraform graph พิมพ์ข้างบน วาดใหม่

Provider protocol: เกิดอะไรขึ้นจริง ๆ ตอน terraform init

ทุก provider — รวมถึง hashicorp/azurerm — เป็น binary แยกต่างหากที่มี version เป็นของตัวเอง ที่ Terraform Core ดาวน์โหลดแล้วรันเป็น subprocess คุยกันผ่าน gRPC ด้วย protocol ตายตัว (protocol version 5 หรือ 6 แล้วแต่ SDK ของ provider) นี่คือเหตุผลที่ terraform init ต้องดาวน์โหลด binary เฉพาะต่อ OS/architecture แทนที่ Terraform จะ “รู้” วิธีคุยกับ Azure, AWS หรือ GCP เองมาตั้งแต่ต้น — provider plugin protocol, plugin handshake และเหตุผลที่ provider crash แล้วเกิด log แบบเฉพาะเจาะจง จะอธิบายลึกพร้อม trace จริงของ TF_LOG=TRACE ตอน provider เริ่มทำงาน ใน Provider Plugin Protocol ในโมดูล Terraform Internals

Mental Model

ทุกอย่างในบทนี้มีหน้าที่เดียว: ช่วยให้ Terraform สร้าง plan ที่ถูกต้องก่อนที่มันจะแตะ Azure เลย resource/data block และการอ้างอิงของมันสร้าง dependency graph; การ override ด้วย lifecycle คือข้อยกเว้นที่ซ้อนอยู่บนพฤติกรรมปกติของกราฟนั้นสำหรับ resource ทีละตัว (หยุดหนัก ๆ, สลับลำดับ, จุดบอดที่ตั้งใจ, edge เพิ่ม) — ไม่มีตัวไหนเปลี่ยนหน้าตาของกราฟเลย เปลี่ยนแค่สิ่งที่ Terraform ทำเมื่อไปถึง node นั้น ตัว provider เองเป็น process แยกที่ Terraform Core คุยด้วยผ่าน protocol ตายตัว ซึ่งเป็นเหตุผลที่ “provider” กับ “Terraform” มี version อิสระจากกันได้ — required_providers pin ตัวหนึ่ง required_version pin อีกตัว

Trade-offs

ตัวเลือก	ข้อดี	ต้นทุน
prevent_destroy	หยุดหนัก ๆ ป้องกัน destroy โดยไม่ตั้งใจ พิสูจน์ข้างบนด้วย error จริงก่อน API call ใด ๆ	บล็อกทุกการ destroy รวมถึงที่ตั้งใจด้วย — ต้องลบออกจากโค้ด (ไม่ใช่แค่ -target เลี่ยง) เพื่อรื้อ resource จริง ๆ
create_before_destroy	ไม่มีช่วง “ไม่มีทั้งคู่” ตอน replace พิสูจน์ข้างบนผ่านสัญลักษณ์ลำดับ +/-	ต้องมีสองชุดอยู่ร่วมกันชั่วขณะ — ปัญหาสำหรับอะไรที่มี uniqueness constraint (ชื่อตายตัว, static IP ที่จองไว้) นอกจาก argument นั้นจะเปลี่ยนด้วย
ignore_changes	หยุด Terraform สู้กับการเปลี่ยนแปลงนอกระบบ พิสูจน์ข้างบนด้วย “No changes” จริงแม้แก้คอนฟิก	ค่าจริงของ argument ที่ถูก ignore ใน Portal/API เบี่ยงห่างจากที่อยู่ใน .tf ได้ไม่จำกัด โดย plan ไม่พูดถึงเลย
replace_triggered_by	ทำให้ dependency ที่ปกติมองไม่เห็นบังคับ replace จริงได้ อย่างตั้งใจ	ต้นทุนเดียวกับ forced replacement ใด ๆ: destroy + recreate ทั้งหมด ไม่ใช่ update บางส่วน
terraform graph (default ไม่มี -type)	สะอาด เป็น summary ระดับ resource — ตัวที่ควรอ่านด้วยตาเปล่า พิสูจน์ข้างบน และไม่ต้องมี Azure credentials	ไม่มี provider node, internal (expand) และ action เฉพาะ plan ที่ -type=plan แสดง — ไม่ใช่ภาพเต็มที่ Terraform เดินจริง

ความเข้าใจผิดที่พบบ่อย

• “prevent_destroy หยุด Terraform ไม่ให้คำนวณ destroy plan เลยด้วยซ้ำ” พิสูจน์ข้างบนแล้วว่าไม่ใช่: บรรทัดสรุป plan (Plan: 0 to add, 0 to change, 1 to destroy) พิมพ์ ก่อน error — prevent_destroy ดักการทำงานหลังจาก plan เสร็จ ไม่ใช่ก่อน
• “create_before_destroy หลีกเลี่ยงการเปลี่ยนจำนวนบรรทัดของ plan diff” มันเปลี่ยนแค่สัญลักษณ์ (+/- กับ -/+) พิสูจน์ข้างบน ไม่เปลี่ยนจำนวนบรรทัด — 1 to add, 0 to change, 1 to destroy เหมือนกันทั้งคู่
• “ignore_changes แค่ ignore drift ครั้งแรก แล้วก็ resync” พิสูจน์ข้างบนแล้วว่าไม่ใช่การข้ามครั้งเดียว — ทุก plan ถัดไปยังมองว่า argument นั้นมองไม่เห็นต่อไปเรื่อย ๆ จนกว่า lifecycle block เองจะถูกแก้
• “Terraform apply resource ตามลำดับที่เขียนในไฟล์” พิสูจน์ข้างบนด้วย terraform graph จริง: ลำดับมาจาก dependency graph ทั้งหมด ไม่ใช่ตำแหน่งในไฟล์ — azurerm_resource_group.logs ที่เขียนไว้ท้ายสุด ไม่มี edge เลยและ apply ก่อนได้
• “provider เป็นส่วนหนึ่งของ Terraform binary compile ติดมาด้วย” มันเป็น binary ที่ดาวน์โหลดแยกต่างหาก รันเป็น subprocess ผ่าน gRPC — อธิบายพร้อม trace จริงในโมดูล Terraform Internals นี่คือเหตุผลที่ terraform init ต้องใช้ network access สำหรับ provider ที่ Terraform เองไม่ได้มากับตัว

อ่านโค้ดที่ AI สร้างให้

• lifecycle { prevent_destroy = true } ที่ใส่ในทุก resource “เพื่อความปลอดภัย” รวมถึงตัวที่จำเป็นต้องถูก destroy จริงเป็นส่วนหนึ่งของการทำงานปกติ (resource ชั่วคราว, อะไรก็ตามที่อยู่หลัง count/for_each ที่หดตัวจริง ๆ) — พิสูจน์ข้างบนแล้วว่านี่เปลี่ยน destroy ที่ตั้งใจให้เป็น error หนัก ๆ ที่ต้องแก้ด้วยการแก้โค้ด ไม่ใช่คำเตือนเบา ๆ
• create_before_destroy = true ที่ใส่ใน resource ที่มี uniqueness constraint บน argument ที่ไม่ได้เปลี่ยน (name ตายตัว, static IP ที่จองไว้) — ตัวแทนจะสร้างไม่สำเร็จเพราะตัวเก่าที่ยังไม่ถูก destroy ยังถือชื่อนั้นอยู่
• ignore_changes = [tags] (หรือแย่กว่านั้น ignore_changes = all) ที่ copy มาจากตัวอย่างโดยไม่เช็คว่า tags ของ resource นี้ ควรถูกจัดการโดย Terraform ไหม — พิสูจน์ข้างบนแล้วว่านี่ซ่อน drift แบบเงียบและตลอดไป ไม่ใช่แค่ครั้งเดียว
• depends_on ที่หายไปเมื่อ comment อ้างว่า “X ต้องมีก่อน Y” แต่ไม่มี argument reference ไหนเข้ารหัสสิ่งนั้นจริง — พิสูจน์ข้างบนแล้วว่า implicit dependency ต้องการ attribute reference จริง comment เฉย ๆ ไม่เข้ากราฟเลย
• โค้ดที่อ้างพฤติกรรมของ provider version เฉพาะโดยไม่เช็ค required_providers — หัวข้อ provider protocol ข้างบนเตือนว่า “Terraform” กับ “azurerm provider” เป็นซอฟต์แวร์สอง version อิสระที่คุยกันผ่าน wire protocol ตายตัว

🐛 หา bug ในโค้ดนี้

resource "azurerm_storage_account" "data" {
name                     = "appdatastorage"
resource_group_name      = azurerm_resource_group.main.name
location                 = azurerm_resource_group.main.location
account_tier             = "Standard"
account_replication_type = "LRS"

lifecycle {
  create_before_destroy = true
}
}

เฉลย

name ไม่ได้แสดงว่าเปลี่ยนตรงนี้ แต่ไม่จำเป็นต้องเปลี่ยนด้วย — ชื่อ Azure storage account ต้องไม่ซ้ำกันทั่วทั้ง Azure ไม่ใช่แค่ในระดับ subscription หรือ resource group ถ้ามีการเปลี่ยนแปลงใด ๆ กับ resource นี้ที่บังคับให้ replace (account_tier และ argument อื่นอีกหลายตัวของ resource นี้เป็น ForceNew argument จริง) create_before_destroy จะพยายามสร้าง appdatastorage ตัวใหม่ก่อน destroy ตัวเก่า — และ Azure จะปฏิเสธการสร้างทันที เพราะ appdatastorage ตัวเก่ายังอยู่และถือชื่อนั้นแบบ global อาการที่เห็นคือความล้มเหลวจริงตอน apply (ไม่ใช่ plan เพราะ plan ขอให้ Azure จองชื่อที่ unique ทั่วโลกไว้ล่วงหน้าไม่ได้) ประมาณ “StorageAccountAlreadyTaken” ทางแก้คือถอด create_before_destroy ออกจาก resource นี้ (ยอมรับช่วง destroy-แล้ว-create) หรือทำให้ name เองเปลี่ยนทุกครั้งที่ replace (เช่น ใส่ suffix จาก random_id) เพื่อให้ชื่อใหม่กับเก่าไม่ชนกันตอนที่ทั้งคู่ยังอยู่

🏗️ สรุปหนึ่งบรรทัด

configuration แบบ HCL ประกอบด้วย block: terraform ประกาศ provider และ version ที่ต้องใช้, provider ตั้งค่าว่า Terraform คุยกับ Azure ยังไง (และ azurerm ต้องมี features {} block แม้จะว่างเปล่าก็ตาม), resource block (ระบุด้วย type และ name ที่คุณเลือก รวมกันเป็น address) ประกาศสิ่งที่ Terraform ควรสร้างและจัดการ — เกือบทุกครั้งอยู่ภายใน azurerm_resource_group ที่เป็น scoping construct ที่มีเฉพาะใน Azure — ส่วน data block มีหน้าที่ อ่าน infrastructure ที่มีอยู่แล้วเท่านั้นโดยไม่เข้าไปเป็นเจ้าของ Terraform สร้าง dependency graph (DAG) จาก implicit reference กับ depends_on แบบ explicit แล้ว apply resource ที่เป็นอิสระต่อกันพร้อมกัน — พิสูจน์ข้างบนด้วย terraform graph DOT dump จริง lifecycle block override พฤติกรรม default ของ Terraform ต่อ resource: prevent_destroy เปลี่ยน destroy ที่ plan ไว้ให้เป็น error หนัก ๆ (พิสูจน์ข้างบน), create_before_destroy สลับลำดับ replace เป็น +/- แทน -/+ (พิสูจน์ข้างบน), ignore_changes ทำให้การเปลี่ยน argument เฉพาะมองไม่เห็นต่อ plan (พิสูจน์ข้างบนด้วย “No changes” จริง) และ replace_triggered_by บังคับ replace จากสัญญาณภายนอก ทุก provider เป็น binary แยกที่คุยผ่าน gRPC protocol ตายตัวกับ Terraform Core อธิบายในโมดูล Terraform Internals

ใน resource "azurerm_linux_virtual_machine" "web" { ... } สอง label นี้คืออะไร

ทั้งสอง label เป็นชื่ออะไรก็ได้ ไม่มีความหมายพิเศษ label แรกคือ resource type (กำหนดโดย provider) ส่วน label ที่สองคือ name ที่คุณเลือกเอง รวมกันเป็น resource address label แรกคือ Azure region ส่วนที่สองคือ resource group label แรกคือชื่อ provider ส่วนที่สองคือ resource type

ทำไม features block ของ azurerm provider ถึงจำเป็นต้องมีแม้จะว่างเปล่า

จริง ๆ แล้วไม่จำเป็น เป็นแค่ convention ที่บางทีมทำตามกัน azurerm provider ต้องมี features block เพื่อ initialize พฤติกรรมระดับ provider และ Terraform จะ error ถ้าไม่ใส่ แม้จะไม่มีอะไรเฉพาะเจาะจงให้ตั้งค่าข้างในก็ตาม จำเป็นเฉพาะตอนใช้ data block เท่านั้น ใช้แทน argument subscription_id ได้

Terraform ตัดสินใจลำดับการสร้าง resource ยังไง โดยใช้ตัวอย่าง resource group จากบทนี้

เรียงจากบนลงล่างตามลำดับที่เขียนในไฟล์เป๊ะ ๆ เรียงตามตัวอักษรของชื่อ resource Terraform สร้าง dependency graph (DAG) จาก implicit attribute reference (เช่น virtual machine ที่อ้างอิง azurerm_resource_group.main.name) กับ depends_on แบบ explicit แล้วเรียงลำดับพร้อม parallelize ตามนั้น Terraform สร้างทุก resource พร้อมกันเป๊ะ ๆ เสมอ

ข้อไหนอธิบาย required_providers ใน terraform block ได้ถูกต้อง

ตั้งค่า Azure subscription ให้ทุก resource ระบุ provider แต่ละตัวที่ต้องใช้ รวมถึง registry source และ version constraint ที่รับได้ แสดงรายชื่อ resource type ทุกตัวที่ใช้ใน configuration จำเป็นเฉพาะตอนใช้ data block เท่านั้น

เกิดอะไรขึ้นเมื่อรัน terraform plan -destroy กับ resource ที่มี lifecycle.prevent_destroy = true

Terraform ข้ามการ destroy resource นั้นแบบเงียบ ๆ ไม่มี output เลย Terraform ยังคำนวณและพิมพ์ plan (รวมถึง destroy) แล้วค่อย error: "Instance cannot be destroyed" Terraform ตั้ง prevent_destroy = false ให้อัตโนมัติแล้วดำเนินต่อ คำสั่ง plan เองปฏิเสธที่จะรันเลย

ใน plan diff ของ terraform สัญลักษณ์ +/- (เทียบกับ -/+ default) บ่งบอกอะไรสำหรับ resource ที่ถูก replace

update บางส่วนแทนที่จะ replace ทั้งหมด create_before_destroy ถูกตั้งไว้: ตัวแทนถูกสร้างก่อน แล้วตัวเก่าค่อยถูก destroy -- กลับด้านจากลำดับ default resource จะถูก import แทนที่จะสร้าง การเปลี่ยนแปลงกระทบแค่ resource ที่อยู่ใน module เท่านั้น

argument ของ resource อยู่ใน lifecycle.ignore_changes แล้วค่าของมันถูกเปลี่ยนตรง ๆ ในไฟล์ .tf terraform plan ถัดไปจะแสดงอะไร

"No changes" -- การเปลี่ยนแปลงของ argument นั้นมองไม่เห็นสำหรับ plan ตลอดไป จนกว่า lifecycle block เองจะถูกแก้ คำเตือน drift ครั้งเดียว แล้ว resync ใน plan ถัดไป error จริงที่ปฏิเสธจะ plan จนกว่า ignore_changes list จะถูกอัปเดต การเปลี่ยนแปลงถูก apply ทันทีโดยไม่ถาม

terraform graph (default ไม่มี flag -type) ต้องมี Azure credentials ไหมถึงจะรันได้

ต้องมี ต้องเรียก Azure API เพื่อ resolve resource ID ก่อนวาดกราฟ ไม่ต้อง -- มัน resolve แค่ reference ที่มีอยู่แล้วในคอนฟิก และไม่เรียก Azure API เลย พิสูจน์ข้างบนด้วยการรันจริงกับ azurerm provider ที่ไม่ได้ authenticate ต้องมีเฉพาะตอนคอนฟิกใช้ data block ต้องมีเฉพาะตอน subscription_id หายไปจาก provider block

Submit

Mark as complete