ข้ามไปยังเนื้อหา
Terraform & Terragrunt for AWS — From Zero to Hero

The State File

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

หัวข้อที่มีชื่อว่า “ไอเดียในหนึ่งประโยค”

state ของ Terraform คือไฟล์ JSON ที่แมป resource แต่ละตัวใน configuration ของคุณเข้ากับ object จริงที่สร้างขึ้น และเป็นสิ่งเดียวที่ทำให้ Terraform รู้ว่าตัวเองจัดการอะไรอยู่

ทำไม Terraform ถึงต้องมี state

หัวข้อที่มีชื่อว่า “ทำไม Terraform ถึงต้องมี state”

ตอนคุณรัน terraform apply Terraform สร้าง resource ผ่าน API ของ cloud provider — EC2 instance, S3 bucket, IAM role สักตัว API ของ provider ไม่มีแนวคิดเรื่อง “Terraform” เลย ถ้าคุณมี EC2 instance 500 ตัวใน AWS account เดียว AWS API ก็บอกไม่ได้ว่าตัวไหนคือตัวที่ Terraform สร้างให้กับ resource "aws_instance" "web" block นี้ ตัวไหนที่เพื่อนร่วมทีมสร้างมือใน console และตัวไหนเป็นของ Terraform configuration อื่นไปเลย

Terraform แก้ปัญหานี้ด้วยการเก็บ record ของตัวเอง ทุกครั้งที่ apply Terraform จะเขียน mapping ระหว่าง resource address ใน configuration กับ ID จริงของ infrastructure ลงไฟล์ state ที่ชื่อ default คือ terraform.tfstate

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
}

หลัง apply ไฟล์ state จะบันทึกประมาณว่า aws_instance.web -> i-0123456789abcdef0 พร้อม attribute ทุกตัวที่ AWS ส่งกลับมาสำหรับ instance นั้น — private IP, ARN, security group ที่ผูกอยู่ และอื่น ๆ ข้อมูลที่ cache ไว้นี้ทำให้ Terraform ไม่ต้องเรียก AWS API แล้ว describe resource ทุกตัวใหม่แค่เพื่อคำนวณ plan เพราะเทียบ configuration กับ state ล่าสุดก่อนได้เลย นี่คือทั้งวิธีตรวจจับว่าอะไรเปลี่ยน และเป็นข้อดีด้าน performance จริง ๆ กับ configuration ขนาดใหญ่ state ยังเป็นที่เก็บ dependency metadata ด้วย ทำให้ Terraform รู้ลำดับที่ต้องสร้าง แก้ไข หรือลบ resource

ความเสี่ยงของ plaintext ที่ซ่อนอยู่ใน state file

หัวข้อที่มีชื่อว่า “ความเสี่ยงของ plaintext ที่ซ่อนอยู่ใน state file”

state file ไม่ได้ผ่านการ sanitize attribute value ใด ๆ ที่ Terraform ได้รับจาก provider — หรือที่คุณตั้งตรงใน configuration — จะไปอยู่ใน terraform.tfstate แบบ plaintext รวมถึงค่าที่เป็น secret ด้วย ตัวอย่างที่เจอบ่อย

resource "aws_db_instance" "main" {
  identifier     = "app-db"
  engine         = "postgres"
  instance_class = "db.t3.micro"
  username       = "app_admin"
  password       = "S3cretPassword!"
}

คุณไม่เคยรัน terraform output กับ password ตัวนั้น และไม่เคย print ใน log แต่ค่านั้นก็ยังไปอยู่ใน terraform.tfstate แบบ plaintext อยู่ดี เพราะ Terraform ต้องจำ attribute ทุกตัวที่ตั้งไว้ เพื่อตรวจ drift ตอน plan ครั้งถัดไป ใครก็ตามที่อ่านไฟล์นั้นได้ก็อ่าน password ได้ด้วย (บทถัดไป sensitive-data-and-team-workflows.mdx พูดถึง sensitive = true, ephemeral, และ write-only argument — ไม่มีตัวไหนทำให้ตัวอย่างนี้ปลอดภัยขึ้น และบทนั้นพิสูจน์ให้เห็นเหตุผลตรง ๆ)

นี่คือเหตุผลที่ terraform.tfstate ห้าม commit เข้า version control เด็ดขาด ใส่ลง .gitignore ตั้งแต่ commit แรกของโปรเจกต์ใหม่

.gitignore
terraform.tfstate
terraform.tfstate.backup
*.tfstate
*.tfstate.*

บทถัดไปจะพูดถึงการย้าย state ออกจาก laptop ไปไว้บน remote backend ที่ควบคุม access ได้จริง นั่นคือวิธีแก้ความเสี่ยงนี้ที่แท้จริง — .gitignore แค่กันอุบัติเหตุที่เห็นชัดที่สุดเท่านั้น

กายวิภาคของ state file จริง

หัวข้อที่มีชื่อว่า “กายวิภาคของ state file จริง”

ตัวอย่างข้างล่างนี้ไม่ได้เขียนจากความจำ — มาจาก terraform apply จริงกับ resource สองตัวที่ไม่ต้องใช้ cloud credential เลย: terraform_data (ตัวแทน null_resource ที่ deprecated ไปแล้วของ built-in provider) และ local_file (hashicorp/local) configuration:

main.tf
terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}


resource "terraform_data" "trigger" {
  input = "v1"
}


resource "local_file" "config" {
  filename = "${path.module}/generated/app.conf"
  content  = "listen=8080\ntrigger_id=${terraform_data.trigger.output}\n"
}

หลัง terraform init -backend=false && terraform apply -auto-approve ไฟล์ terraform.tfstate จริงบน disk (ตัด machine path ออกแล้ว)

{
  "version": 4,
  "terraform_version": "1.16.4",
  "serial": 6,
  "lineage": "91789eb2-a206-8e38-2571-62323b581164",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "local_file",
      "name": "config",
      "provider": "provider[\"registry.terraform.io/hashicorp/local\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "content": "listen=8080\ntrigger_id=v1\n",
            "content_sha1": "7551ae2164513c74b5c0665a6b28b6a40399686f",
            "filename": "./generated/app.conf",
            "id": "7551ae2164513c74b5c0665a6b28b6a40399686f"
          },
          "dependencies": ["terraform_data.trigger"],
          "sensitive_attributes": [[{ "type": "get_attr", "value": "sensitive_content" }]]
        }
      ]
    },
    {
      "mode": "managed",
      "type": "terraform_data",
      "name": "trigger",
      "provider": "provider[\"terraform.io/builtin/terraform\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "7e48645a-6b7e-14c9-d8b3-99d042610145",
            "input": { "value": "v1", "type": "string" },
            "output": { "value": "v1", "type": "string" }
          },
          "sensitive_attributes": []
        }
      ]
    }
  ],
  "check_results": null
}

field ระดับบนสุดแต่ละตัวมีความหมายเฉพาะ

  • version — เวอร์ชันของ format ไฟล์ state (เป็น 4 มาตั้งแต่ Terraform 0.12 — ไม่เกี่ยวกับเวอร์ชันของตัว Terraform binary)
  • terraform_version — เวอร์ชัน CLI จริงที่เขียนไฟล์นี้ครั้งล่าสุด
  • serial — ตัวนับที่เพิ่มขึ้นทุกครั้งที่เขียน state ไฟล์ state สองไฟล์ที่มี lineage เดียวกันจะถูกเทียบกันด้วย serial เพื่อดูว่าไฟล์ไหนใหม่กว่า
  • lineage — UUID ที่ generate ครั้งเดียวตอนสร้าง state ให้ working directory ครั้งแรก มันไม่เปลี่ยนตลอดอายุของ state นั้น และเป็นวิธีที่ Terraform แยก “state เดียวกันแต่เป็นก็อปปี้เก่ากว่า” ออกจาก “state คนละไฟล์กันที่หน้าตาคล้ายกันเฉย ๆ”
  • resources[] — หนึ่ง entry ต่อ resource block (ไม่ใช่ต่อ instance — count/for_each ใช้ entry เดียวกันแต่มีหลาย instances[]) แต่ละตัวมี mode, type, name, provider, และ instances
  • instances[].attributes — attribute ทุกตัวที่ provider ส่งกลับมาหลัง create/read ข้อมูลชุดเดียวกับที่ terraform state show print ออกมา
  • instances[].dependencies — resource address ที่ configuration ของ instance นี้อ้างถึง (พิสูจน์ข้างบน: local_file.config depend on terraform_data.trigger เพราะ content ของมัน interpolate terraform_data.trigger.output) นี่คือ dependency metadata ที่พูดถึงข้างบนเป๊ะ ๆ — เป็นเหตุผลที่ destroy รื้อ resource ตามลำดับที่ถูกต้องได้โดยไม่ต้องคำนวณ dependency ใหม่ตั้งแต่ต้น

terraform show -json ข้อมูลชุดเดียวกัน แต่ provider-agnostic และเสถียร

หัวข้อที่มีชื่อว่า “terraform show -json ข้อมูลชุดเดียวกัน แต่ provider-agnostic และเสถียร”

terraform state show ข้างบนเป็น format ที่อ่านง่ายสำหรับคน terraform show -json คือ machine-readable contract ที่ tool อื่น (Sentinel, OPA/conftest, custom CI check) ต้อง parse — มัน document ไว้ชัดเจน มี version (format_version) และไม่เปลี่ยนรูปแบบระหว่างเวอร์ชัน provider เหมือน internal ของ raw state บางครั้งเป็น output จริง (ตัดทอน) จาก apply เดียวกัน

{
  "format_version": "1.0",
  "terraform_version": "1.16.4",
  "values": {
    "root_module": {
      "resources": [
        {
          "address": "local_file.config",
          "mode": "managed",
          "type": "local_file",
          "name": "config",
          "provider_name": "registry.terraform.io/hashicorp/local",
          "values": {
            "content": "listen=8080\ntrigger_id=v1\n",
            "id": "7551ae2164513c74b5c0665a6b28b6a40399686f"
          },
          "sensitive_values": { "sensitive_content": true },
          "depends_on": ["terraform_data.trigger"]
        }
      ]
    }
  }
}

drift-detection-and-import.mdx และ sensitive-data-and-team-workflows.mdx ต่างก็กลับมาใช้ show -json เพราะ proof ของ -detailed-exitcode และ sensitive_values map ทั้งคู่อยู่ใน structure นี้เป๊ะ ๆ

การดู state

หัวข้อที่มีชื่อว่า “การดู state”

Terraform มีคำสั่งสำหรับดูข้างใน state โดยไม่ต้องเปิดไฟล์ JSON เอง

Terminal window
# Human-readable dump of the entire current state
terraform show


# List every resource address currently tracked in state
terraform state list


# Show full attribute detail for one specific resource
terraform state show local_file.config


# Print the current state as JSON, from whatever backend is configured
terraform state pull > current.tfstate

terraform state list คือวิธีเร็วที่สุดในการตอบคำถามว่า “configuration นี้จัดการอะไรอยู่ตอนนี้” คำสั่งนี้ print address โดยไม่มีรายละเอียดอื่น output จริง

$ terraform state list
local_file.config
terraform_data.trigger

terraform state show <address> จะลงลึกไป address ใดตัวหนึ่ง output จริง

$ terraform state show local_file.config
# local_file.config:
resource "local_file" "config" {
    content              = <<-EOT
        listen=8080
        trigger_id=v1
    EOT
    content_sha1         = "7551ae2164513c74b5c0665a6b28b6a40399686f"
    filename             = "./generated/app.conf"
    id                   = "7551ae2164513c74b5c0665a6b28b6a40399686f"
}

terraform state pull คือช่องทางที่ remote backend serve state ออกมาจริง ๆ — แม้ใช้ local backend มันก็ยัง return current state เป็น JSON ทาง stdout เสมอ นี่คือเหตุผลที่ script ที่ทำงานกับ state (CI check, custom drift report) ควร pull แทนที่จะอ่านจาก path ไฟล์ตรง ๆ คำสั่งเดียวกันใช้ได้ไม่ว่า backend ไหนถูก configure ไว้

ทำไมการแก้ state ด้วยมือถึงพัง lineage กับ serial ถูกบังคับใช้จริง ไม่ใช่แค่ตกแต่ง

หัวข้อที่มีชื่อว่า “ทำไมการแก้ state ด้วยมือถึงพัง lineage กับ serial ถูกบังคับใช้จริง ไม่ใช่แค่ตกแต่ง”

terraform state push <file> อัพโหลด state file ในเครื่องไปแทนที่สิ่งที่ backend ถืออยู่ตอนนี้ — และมันบังคับตรวจ lineage กับ serial ก่อนจะยอมทำแบบนั้น เพื่อกันไม่ให้คุณเอา state เก่าหรือไม่เกี่ยวข้องไปทับ state ที่ใหม่กว่า พิสูจน์ เอา state จริงข้างบน เปลี่ยน lineage เป็น UUID สุ่ม แล้ว push กลับ

$ terraform state push tampered.tfstate
Failed to write state: cannot import state with lineage "00000000-0000-0000-0000-000000000000" over unrelated state with lineage "91789eb2-a206-8e38-2571-62323b581164"

state เดียวกัน แต่ตั้ง serial ให้ย้อนกลับแทน

$ terraform state push tampered2.tfstate
Failed to write state: cannot import state with serial 1 over newer state with serial 6

ทั้งสองคือ error จริงจาก Terraform 1.16.4 ไม่ได้จำลอง นี่คือเหตุผลที่การแก้ terraform.tfstate ด้วย text editor ตรง ๆ อันตราย แม้จะตั้งใจแก้แค่ field เดียว เว้นแต่คุณจะเพิ่ม serial ให้ถูกต้องด้วย (และไม่แตะ lineage เลย) consistency check ของ Terraform เองจะปฏิเสธการเขียนทันทีตอนคุณพยายาม push กลับ — และถ้าคุณข้าม check นี้ไปด้วยการเขียนทับ backend object ตรง ๆ (ข้าม state push ไปเลย เช่น copy ไฟล์ทับ S3 object ด้วยมือ) ก็ไม่มีอะไรหยุดคุณได้ ซึ่งนี่คือ failure mode ตัวจริง state เสียหายแบบเงียบ ไม่มี error เลย จะรู้ตัวอีกทีก็ตอน plan ครั้งถัดไป ที่ความเข้าใจของ Terraform ไม่ตรงกับสิ่งที่ deploy จริงอีกต่อไป terraform state mv, import, และ rm ถูกสร้างมาเพื่อไม่ให้คุณต้องเปิด JSON ด้วยมือเลย — มันอัพเดต serial ให้ถูกต้องในตัวเป็นส่วนหนึ่งของ operation เดียวกัน

cloud backend เก็บอะไรจริง ๆ

หัวข้อที่มีชื่อว่า “cloud backend เก็บอะไรจริง ๆ”

คอร์สนี้ใช้ local backend สำหรับ proof ทุกอันข้างบน (ไม่ต้องใช้ credential) แต่ production state บน AWS อยู่บน S3 backend ตาม documentation ของ S3 backend เอง

“The S3 backend stores state data in an S3 object at the path set by the key parameter in the S3 bucket indicated by the bucket parameter.” — developer.hashicorp.com/terraform/language/backend/s3

ดังนั้น state JSON ที่แสดงข้างบนคือสิ่งที่ไปอยู่ใน S3 object นั้นเป๊ะ ๆ — shape เดียวกันของ version/serial/lineage/resources ไม่มีอะไรเฉพาะ AWS เพิ่มเข้ามา lock เป็น object แยกต่างหาก S3 native locking (use_lockfile = true เพิ่มเข้ามาใน Terraform 1.10.0 — “The s3 backend now supports S3 native state locking” ตาม CHANGELOG ของ Terraform 1.10.0) เขียน object <key>.tflock คู่กับ state object เอง remote-backends-and-locking.mdx พูดถึง backend block เต็ม ๆ, migration, และ force-unlock

flowchart LR
  cfg["Terraform config (.tf files)"] --> apply["terraform apply"]
  apply --> aws["Real AWS resources"]
  aws -->|attributes written back| state["terraform.tfstate"]
  cfg -->|next run| plan["terraform plan"]
  state -->|read for comparison| plan
ทั้ง config และ resource จริงบน AWS ป้อนข้อมูลเข้า state file ที่ plan ครั้งถัดไปอ่าน

Mental Model

หัวข้อที่มีชื่อว่า “Mental Model”

state คือความจำเดียวของ Terraform เกี่ยวกับความจริง — ไม่ใช่ cache ที่ทิ้งได้ปลอดภัย และไม่ใช่ log ที่ append เพิ่มด้วยมือได้ปลอดภัย ทุกอย่างในบทนี้มาจากข้อเท็จจริงเดียว provider API ไม่รู้จัก Terraform เลย ทุกบิตของ “สร้างอะไรไปแล้ว หน้าตาเป็นยังไง” ต้องอยู่ที่ที่ Terraform ควบคุมได้เต็มที่ lineage กับ serial ไม่ใช่ metadata ให้คนอ่านเฉย ๆ — มันคือกลไกที่ทำให้ state push เป็น operation ที่ปลอดภัยและถูกตรวจสอบ แทนที่จะเป็นการเขียนทับแบบไม่ดูอะไร ปฏิบัติกับ state file เหมือนกับ transaction log ของ database คุณอ่านมันด้วย tool ที่สร้างมาเพื่ออ่าน (state show, show -json, state pull) และแก้มันด้วยคำสั่งที่สร้างมาเพื่อแก้ (state mv, import, rm) — ไม่ใช่ text editor เด็ดขาด

ข้อแลกเปลี่ยน

หัวข้อที่มีชื่อว่า “ข้อแลกเปลี่ยน”
ทางเลือกได้อะไรเสียอะไร
cache attribute ทุกตัวไว้ใน stateplan เทียบกับข้อมูล cache แทนที่จะ describe resource ทุกตัวใหม่จาก provider API — ได้ performance จริงเมื่อ scale ใหญ่attribute ทุกตัว รวม secret อยู่แบบ plaintext บน disk หรือใน backend object (พิสูจน์ข้างบน)
consistency check lineage/serial บน state pushstate เก่าหรือไม่เกี่ยวข้องเขียนทับ state ปัจจุบันแบบเงียบ ๆ ไม่ได้ (พิสูจน์ข้างบนสองครั้ง)ป้องกันแค่ทาง state push — การเขียนทับ backend object ตรง ๆ ข้าม check นี้ได้เลย ไม่มี error
terraform show -json เป็น machine format ที่เสถียรtool (policy check, CI, custom script) พึ่ง schema ที่ document ไว้ มี version แทนที่จะ parse output ที่อ่านง่ายสำหรับคนมี representation ของข้อมูลชุดเดียวกันสองแบบให้จำ raw terraform.tfstate กับ show -json ไม่ใช่ shape เดียวกัน

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

หัวข้อที่มีชื่อว่า “ความเข้าใจผิดที่พบบ่อย”
  • “state เก็บแค่สิ่งที่ใส่ใน output block” พิสูจน์ข้างบน attribute เต็มชุดของ local_file.config — รวมค่าที่มาจากการคำนวณที่ไม่เคย output เลย — ถูกเขียนลง resources[].instances[].attributes ไม่ว่าจะมี output block หรือไม่
  • “แก้ terraform.tfstate ด้วยมือได้ปลอดภัย ถ้าระวังพอ” พิสูจน์ข้างบน state push ปฏิเสธการเปลี่ยน lineage และ serial ที่ย้อนกลับด้วย error จริง ความอันตรายจริง ๆ อยู่ที่กรณีที่ error นั้นไม่ครอบคลุม — การเขียนทับ backend object ตรง ๆ ที่ไม่มี error หรือ warning ใด ๆ จะรู้ตัวก็ตอน plan ที่ไม่ตรงกับความจริงอีกต่อไป
  • “serial คือจำนวน resource หรือ version number ที่เราตั้งเองได้” มันคือตัวนับการเขียนภายในที่ Terraform เพิ่มเอง คุณไม่เคยตั้งมันเอง และการตั้งเป็นค่าที่ไม่ใช่ “สูงกว่าค่าปัจจุบัน” คือสิ่งที่ state push ปฏิเสธในพิสูจน์ข้างบน
  • “terraform show -json กับไฟล์ .tfstate ดิบ ๆ เป็น format เดียวกัน” พิสูจน์ข้างบน map values.root_module.resources[].values ของ show -json กับ map resources[].instances[].attributes ของ raw state เก็บข้อมูลชุดเดียวกัน แต่ document เป็นคนละ schema ที่ version แยกกัน (format_version กับ state version)

อ่านโค้ดที่ AI เขียน

หัวข้อที่มีชื่อว่า “อ่านโค้ดที่ AI เขียน”

ตอน review Terraform ที่ generate มาแล้วแตะ state ตรง ๆ เช็คสิ่งเหล่านี้

  • script ที่เปิด terraform.tfstate ด้วย sed/jq -i/text editor เพื่อ “แก้” ค่าเดียว ณ ที่นั้น แล้วหวังให้ apply ครั้งถัดไป pick up ไป — พิสูจน์ข้างบน อย่างดีก็โดน state push ปฏิเสธด้วย check lineage/serial อย่างแย่ backend object เสียหายแบบเงียบ ๆ ถ้า check ถูกข้ามไป
  • .gitignore ไม่มี *.tfstate* เลย หรือมีแค่ terraform.tfstate แต่ขาด terraform.tfstate.backup กับ *.tfstate.* (workspace variant)
  • โค้ดหรือ runbook ที่คิดว่า serial เป็นเลขที่ตั้งเองได้ปลอดภัย (“ตั้ง serial เป็น 1 เพื่อ reset”) — มันคือตัวนับการเขียนแบบ monotonic ที่ backend บังคับใช้ ไม่ใช่ field ให้เลือกเลขเอง
  • custom drift-checking script ที่อ่าน terraform.tfstate ตรง ๆ ด้วย local path ที่ hardcode ไว้ แทนที่จะใช้ terraform state pull ซึ่งพังทันทีที่โปรเจกต์เปลี่ยนไปใช้ remote backend
  • สับสน schema ของ terraform show -json กับ schema ของ raw state file ตอนเขียน parser — มันมี field ต่างกัน (values.root_module.resources กับ resources[].instances[].attributes) แม้จะอธิบาย resource ชุดเดียวกันก็ตาม

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

#!/usr/bin/env bash
# "quick fix" for a wrong instance_type recorded in state
sed -i '' 's/"t3.micro"/"t3.small"/' terraform.tfstate
terraform state push terraform.tfstate
เฉลย

มีปัญหาจริงสองอย่าง พิสูจน์ข้างบน อย่างแรก state push บังคับตรวจ lineage/serial — แต่ sed -i ตรงนี้ไม่ได้เปลี่ยนทั้งสอง field เลย push อาจสำเร็จได้จริง ๆ ซึ่งคือกับดัก Terraform เชื่อว่า instance_type เป็น t3.small ไปแล้ว ทั้งที่ AWS ยังรัน instance แบบ t3.micro อยู่ ไม่มีการเรียก AWS API มา verify เลย plan ครั้งถัดไปจะไม่แสดงการเปลี่ยนแปลงใด ๆ (state ตอนนี้ “เห็นด้วย” กับค่าที่แก้ไปแบบผิด ๆ แล้ว) drift ระหว่าง state ที่แก้กับ infrastructure จริงจะไม่ถูกจับได้เลยจนกว่าอย่างอื่นจะทำให้เห็น วิธีแก้ที่ถูกต้องเมื่อ “state ไม่ตรงกับความจริง” ไม่ใช่การแก้มือเด็ดขาด — คือ terraform apply (ถ้า config ควรชนะ), terraform plan -refresh-only (เพื่อดูว่าอะไรเปลี่ยน), หรือ terraform import/state rm (พูดถึงใน drift-detection-and-import.mdx) ทั้งหมดนี้ผ่านกลไก consistency ของ Terraform เอง ไม่ใช่การข้ามมันไป

ทำไม Terraform ถึงต้องมี state file แทนที่จะ query cloud provider API ทุกครั้ง
database password ถูกตั้งเป็น resource attribute แต่ไม่เคย print ด้วย terraform output ค่านั้นยังไปอยู่แบบ plaintext ที่ไหนได้ไหม
state file ที่แก้มือแบบนี้ ถูก push ด้วย terraform state push tampered.tfstate กับ backend ที่ตอนนี้อยู่ที่ serial 6, lineage 91789eb2-... จะเกิดอะไรขึ้น
{
  "serial": 1,
  "lineage": "00000000-0000-0000-0000-000000000000"
}
field dependencies บน state resource instance บันทึกอะไรจริง ๆ พิสูจน์จากตัวอย่าง local_file.config / terraform_data.trigger ข้างบน
terraform state list กับ terraform state show ต่างกันยังไง
ทำไม custom drift-checking script ที่ parse terraform.tfstate ตรง ๆ ด้วย local file path ถึงพังตอนโปรเจกต์เปลี่ยนไปใช้ remote backend