Input Variables

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

input variable คือ parameter ที่มีชื่อและมี type ชัดเจน ทำให้ config เดียวกันสร้าง infrastructure ต่างกันได้ตามคนเรียกและค่าที่ส่งเข้ามา

ประกาศ variable block

variable block มีสี่ส่วนที่ควรรู้ไว้ให้แม่น type กำหนดรูปร่างของค่าที่ยอมรับได้ default เป็นค่า fallback เวลาไม่มีใครส่งค่ามา description ไว้บอกความตั้งใจให้คนอ่านคนถัดไป และ sensitive ซ่อนค่าจาก CLI output ส่วนใหญ่

variable "environment" {
  type        = string
  description = "Deployment environment name, e.g. dev, staging, prod"
  default     = "dev"
}

variable "instance_count" {
  type        = number
  description = "Number of EC2 instances to launch"
  default     = 2
}

variable "enable_monitoring" {
  type        = bool
  description = "Whether to enable detailed CloudWatch monitoring"
  default     = true
}

variable "allowed_ports" {
  type        = list(number)
  description = "TCP ports allowed inbound on the security group"
  default     = [22, 443]
}

variable "resource_tags" {
  type        = map(string)
  description = "Tags applied to every resource in this configuration"
  default = {
    project = "payments"
    team    = "platform"
  }
}

variable "db_config" {
  type = object({
    engine         = string
    instance_class = string
    allocated_gb   = number
  })
  description = "Structured configuration for the RDS instance"
  default = {
    engine         = "postgres"
    instance_class = "db.t3.micro"
    allocated_gb   = 20
  }
}

variable "db_password" {
  type        = string
  description = "Master password for the RDS instance"
  sensitive   = true
}

object({...}) ควรพูดถึงแยกไว้ต่างหาก เป็น structure ที่มี type และรูปร่างตายตัว ทุก key ที่ list ไว้ต้อง required (เว้นแต่จะใส่ default ผ่าน optional()) และ Terraform ปฏิเสธค่าที่ caller ส่งมาผิดรูปร่างตั้งแต่ตอน plan ก่อนที่จะไปเรียก AWS API เลยด้วยซ้ำ

sensitive = true บน db_password มีผลแค่กับการ แสดงผล เท่านั้น Terraform จะซ่อนค่าใน output ของ plan/apply และใน CLI ให้เป็น (sensitive value) แต่ไม่ได้เข้ารหัสหรือตัดค่าออกจาก state file — module เรื่อง state management พูดไปแล้วว่า state เก็บทุก attribute ของทุก resource ที่ manage อยู่เป็น plain text ในไฟล์ JSON รวมถึงค่าที่มาจาก sensitive variable ด้วย ให้มอง sensitive = true เป็นแค่การป้องกันตอนแสดงผลบน terminal กับ CI log ไม่ใช่ตัวแทนของ remote backend ที่ควบคุม access ได้ดีอยู่แล้ว

ตรวจสอบ variable ด้วย validation block

default หรือ type constraint เช็คได้แค่รูปร่างของค่า ไม่ได้เช็คว่าค่านั้นสมเหตุสมผลไหม validation block เพิ่ม condition แบบ custom กับ error_message เฉพาะเจาะจง ทำให้ caller ได้ feedback ทันทีตอน plan แทนที่จะเจอ error งง ๆ จากลึก ๆ ใน AWS provider

variable "instance_type" {
  type        = string
  description = "EC2 instance type, must be from the approved t3/m6i families"

  validation {
    condition     = can(regex("^(t3|m6i)\\.(micro|small|medium|large|xlarge)$", var.instance_type))
    error_message = "instance_type must be a t3 or m6i size, e.g. t3.micro or m6i.large."
  }
}

variable "environment" {
  type        = string
  description = "Deployment environment name"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment must be one of: dev, staging, prod."
  }
}

ถ้าไม่มี validation block แรก การส่ง instance_type = "x1.enormous" จะผ่าน terraform plan ไปเฉย ๆ แล้วไปพังตอน Terraform เรียก EC2 API จริง ๆ เพื่อสร้าง instance — feedback loop ช้ากว่ามาก และ error message ก็เฉพาะเจาะจงน้อยกว่า “instance_type must be a t3 or m6i size” มาก can() ที่ wrap ไว้ทำหน้าที่แปลง error จาก regex() ให้กลายเป็น false แทนที่จะ error ตรง ๆ ซึ่งตรงกับสิ่งที่ condition expression ต้องการพอดี เพราะต้อง evaluate ออกมาเป็น true หรือ false เสมอ ห้าม raise error

ตั้งค่า variable และใครชนะ

Terraform ยอมให้ตั้งค่า variable ตัวเดียวกันจากหลายที่พร้อมกัน แล้วแก้ conflict ด้วยลำดับความสำคัญที่ตายตัว เรียงจากสำคัญที่สุด (ชนะ) ไปน้อยที่สุด:

-var และ -var-file บน command line ตามลำดับที่ใส่ — วิธีที่ explicit ที่สุดและชั่วคราวที่สุด
ไฟล์ *.auto.tfvars / *.auto.tfvars.json ที่ auto-load จาก working directory ตามลำดับตัวอักษรของชื่อไฟล์
terraform.tfvars / terraform.tfvars.json ที่ auto-load ถ้ามีไฟล์นี้อยู่
environment variable TF_VAR_<name> — มีประโยชน์กับ CI pipeline และกับค่าที่ไม่อยากให้อยู่ในไฟล์เลย
default ของ variable เอง — ใช้ก็ต่อเมื่อไม่มีอะไรข้างบนส่งค่ามาเลย

# Highest precedence: an explicit CLI flag for this one run
terraform apply -var="instance_type=m6i.large"

# Or point at a specific tfvars file
terraform apply -var-file="prod.tfvars"

# Environment variable equivalent of setting instance_type
export TF_VAR_instance_type="t3.medium"
terraform apply

ถ้า instance_type ถูกตั้งไว้ใน terraform.tfvars, ตั้งอีกทีใน prod.auto.tfvars, แล้วตั้งอีกทีผ่าน -var บน command line ค่าจาก -var จะชนะ Terraform ไม่ได้ merge ค่าแบบ scalar ข้ามแหล่งกัน แต่เลือกแหล่งที่ priority สูงสุดที่มีค่าอยู่เท่านั้น collection type อย่าง map กับ object เป็นข้อยกเว้นที่ควรจำไว้สำหรับบทหลัง ๆ — เครื่องมือบางตัว merge ค่าที่ nested กันแทนที่จะ override ทั้งก้อน แต่สำหรับแหล่งข้อมูลปกติข้างบนนี้ ค่าที่ประกาศไว้ในแหล่งที่ priority สูงกว่าจะแทนที่ค่าจากแหล่งที่ priority ต่ำกว่าไปเลยสำหรับ variable ตัวนั้น

flowchart LR
  a["-var / -var-file (CLI flag)"] --> r["Resolved value of var.instance_type"]
  b["*.auto.tfvars (alphabetical)"] --> r
  c["terraform.tfvars"] --> r
  d["TF_VAR_instance_type (env var)"] --> r
  e["default in the variable block"] --> r
  r --> res["aws_instance.web"]

Multiple value sources resolve to one value per variable, by precedence

🏗️ The one-line takeaway

variable block ประกาศ input ที่มี type และชื่อ พร้อม default ที่เป็น optional และ sensitive = true ซ่อนค่าจาก CLI output เท่านั้น — ค่ายังถูกเก็บเป็น plain text ใน state อยู่ดี validation block เพิ่ม condition กับ error_message แบบ custom ทำให้ input ที่ผิดพังเร็วและชัดเจนตอน plan แทนที่จะพังลึก ๆ ใน provider call เวลา variable ตัวเดียวกันได้ค่าจากหลายที่ Terraform แก้ด้วยลำดับความสำคัญตายตัว: -var/-var-file ชนะ *.auto.tfvars ซึ่งชนะ terraform.tfvars ซึ่งชนะ environment variable TF_VAR_* ซึ่งชนะ default ของ variable เอง