The Multi-Environment Problem

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

setup จริงของ infrastructure ทุกอันต้องมีอย่างน้อย dev, staging, prod เป็น environment ที่แยกจากกันและ isolate กัน แล้วการเอา logic เดียวกันของ Terraform มาใช้ซ้ำในทุก environment โดยไม่ปล่อยให้ configuration แต่ละอัน drift ออกจากกันเงียบ ๆ คือปัญหาที่ Terraform ไม่ได้แก้ให้อัตโนมัติ

environment มีมากกว่าที่คิด

ตัวอย่าง Terraform ง่าย ๆ ทั่วไปมักจัดการแค่ environment เดียว แต่ setup จริงไม่เคยเป็นแบบนั้น อย่างน้อยต้องมี

• dev ราคาถูก ทิ้งได้ พังได้อย่างปลอดภัย
• staging จำลอง prod ให้ใกล้เคียงที่สุด ใช้ดักปัญหาก่อนจะปล่อยจริง
• prod ตัวที่รับ traffic จริงและลูกค้าจริง

หลายทีมมี subdivision มากกว่านั้นอีก เช่น copy แยกต่อ Azure region, copy แยกต่อลูกค้าสำหรับ B2B deployment ขนาดใหญ่ หรือ preview environment อายุสั้นที่ spin up ต่อ feature branch แล้วถูกทำลายทิ้งเมื่อ pull request merge แต่ละอันมักต่างจากกันตรง ๆ อย่างเป็นรูปธรรม เช่น VM size เล็กกว่าใน dev, replica น้อยกว่าใน staging, ปิด autoscaling ใน dev เพื่อประหยัดเงิน และที่สำคัญ prod มักถูกวางไว้ใน resource group ของตัวเอง หรือแม้แต่ subscription ของตัวเอง แยกออกไปต่างหากจากที่เหลือทั้งหมด เพื่อให้ความผิดพลาดใน dev ไปไม่ถึงอะไรที่สำคัญ จุดหลังนี้เรียกว่า blast-radius isolation คือการจำกัดว่าความผิดพลาดจาก apply หรือ credential ที่หลุดออกไปจะไปได้ไกลแค่ไหน

ทางแก้แบบไร้เดียงสา: copy-paste directory ต่อ environment

สัญชาตญาณแรกที่แทบทุกคนใช้คือสร้าง environment เดียวให้ทำงานได้ก่อน แล้ว copy ทั้ง directory ไปเป็น environment ที่เหลือ

# Three near-identical copies, created once by hand
tree environments
environments
├── dev
│   └── main.tf
├── staging
│   └── main.tf
└── prod
    └── main.tf

วันแรก ทั้งสามไฟล์เหมือนกันทุกตัวอักษร ยกเว้นค่า hardcode ไม่กี่จุด เช่น VM size ตรงนี้ ชื่อ resource group ตรงนั้น ทุกอย่างใช้งานได้ และรู้สึกเร็วดี ไม่ต้องออกแบบ shared module ไม่ต้องคิด abstraction ให้ถูกต้อง แค่สาม folder ของโค้ด .tf ธรรมดา

# Day one: dev/main.tf, staging/main.tf, and prod/main.tf are all this rule, verbatim
resource "azurerm_network_security_rule" "allow_app_port" {
  name                        = "allow-app-port"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "8080"
  source_address_prefix       = "10.0.0.0/16"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.app.name
  network_security_group_name = azurerm_network_security_group.app.name
}

หกเดือนถัดมา security review flag ว่า rule นั้นใน prod หลวมเกินไป แล้วมีคนไปแก้ให้แน่นขึ้นตรงใน prod/main.tf โดยตรง

# Six months later: prod/main.tf was patched during a security review.
# staging/main.tf and dev/main.tf still say 10.0.0.0/16 — nobody remembered to port the fix.
resource "azurerm_network_security_rule" "allow_app_port" {
  name                        = "allow-app-port"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "8080"
  source_address_prefix       = "10.0.5.0/24"
  destination_address_prefix  = "*"
  resource_group_name         = azurerm_resource_group.app.name
  network_security_group_name = azurerm_network_security_group.app.name
}

ไม่มีใครทำอะไรร้ายหรือแม้แต่สะเพร่าตรงนี้เลย การแก้ rule ตรงที่ security review กำลังมองอยู่คือเรื่องสมเหตุสมผลในตอนนั้น แต่ตอนนี้สาม directory กลายเป็นสาม configuration ที่ต่างกันแบบเล็ก ๆ และไม่มีเอกสารบันทึกไว้เลยว่าต่างกันตรงไหน สั่ง diff ระหว่าง dev/ กับ prod/ หกเดือนต่อมาจะเจอความต่างเล็ก ๆ เป็นสิบจุด และไม่มีใครจำได้จากความทรงจำว่าจุดไหนตั้งใจให้ต่าง จุดไหนแค่ลืม port fix ตาม

ความตึงที่ module นี้จะพาไปดู

ปัญหาลึก ๆ คือการ copy-paste directory ทั้ง environment optimize เพื่อ isolation คือแต่ละ environment ไม่กระทบกันจริง ๆ เพราะเป็นไฟล์คนละชุดกันเลย แต่แลกมาด้วยการ reuse ที่หายไปทั้งหมด bug fix ทุกตัว, tag ที่เพิ่มเข้าไปเพื่อ track cost ทุกอัน, module version ที่ bump ทุกครั้ง ต้องไปทำซ้ำมือใน copy ทุกชุด และการทำซ้ำมือคือขั้นตอนแบบที่มักจะเงียบ ๆ หยุดเกิดขึ้นไปเอง

ที่เหลือของ module นี้คือการแก้ความตึงนั้น จะ reuse logic เดียวกันข้ามทุก environment ยังไง (ให้มีจุดเดียวสำหรับแก้ bug ไม่ใช่สามหรือห้าจุด) พร้อมกับยังคงเก็บ state, credential, และ blast radius ของแต่ละ environment ให้ isolate จากกันเต็มที่ Terraform เองมีคำตอบบางส่วนให้สองแบบ คือ workspace กับ directory-per-environment pattern และแต่ละแบบ ตามที่สองบทถัดไปจะแสดงให้เห็น แก้ปัญหาได้แค่ครึ่งเดียว แล้วเปิดช่องโหว่ให้อีกครึ่งที่เหลือ

flowchart LR
  origin["Working config, copied once"] -->|copy-paste| dev["dev/ (copy)"]
  origin -->|copy-paste| staging["staging/ (copy)"]
  origin -->|copy-paste| prod["prod/ (copy)"]
  prod -->|"NSG rule tightened here only"| prodDrift["prod/ (drifted)"]
  staging -->|"VM size bumped here only"| stagingDrift["staging/ (drifted)"]
  dev -->|"never touched again"| devDrift["dev/ (stale)"]

สาม directory environment ที่ copy-paste มา ค่อย ๆ diverge เงียบ ๆ เมื่อ fix แบบ ad hoc ลงแค่อันเดียว

ทั้งสอง azurerm_network_security_rule fence ข้างบนเป็น HCL จริงที่ valid — ยืนยันด้วย terraform fmt -check กับทั้งคู่ — drift ที่โชว์ระหว่างสองอันไม่ใช่ความต่างของ syntax เลย เป็นความต่างของค่า (source_address_prefix) เท่านั้น เป็นความต่างเล็ก ๆ ที่มองข้ามได้ง่ายแบบเป๊ะ ๆ ที่สะสมเงียบ ๆ ใน tree ที่ copy-paste มา

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

ตอนรีวิว environments/ tree ที่ AI สร้าง ให้เช็คสิ่งเหล่านี้:

• สาม (หรือมากกว่า) environment directory ที่เหมือนกันเป๊ะ byte-ต่อ-byte ยกเว้นค่าไม่กี่ตัวที่ hardcode ไว้ ไม่มี shared module หรือ shared config file ที่ไหนเลย — pattern copy-paste เป๊ะ ๆ ที่บทนี้อธิบาย และเป็นจุดเริ่มต้นที่ AI assistant มักสร้างเวลาถูกขอ “dev, staging, prod setup”
• ค่า hardcode (VM size, NSG rule prefix, tag) ที่ต่างกันระหว่าง environment directory โดยไม่มี comment อธิบายว่า ทำไม — แยกไม่ออกเลยระหว่าง drift โดยไม่ตั้งใจ กับตัวเลือกที่ตั้งใจให้ต่างกันตาม environment
• ไม่มีการพูดถึง Azure subscription หรือ resource group แยกต่อ environment เลยในตัวอย่าง multi-environment ที่ generate มา — argument เรื่อง blast-radius ของ Azure โดยเฉพาะต้องอาศัยการแยกนั้นจริง ๆ ไม่ใช่แค่แยก directory เฉย ๆ

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

# Generated "multi-environment setup" — three near-identical files
# environments/dev/main.tf, environments/staging/main.tf, environments/prod/main.tf
resource "azurerm_linux_virtual_machine" "app" {
name                = "app-vm"
size                = "Standard_B1s"
tags = {
  environment = "prod"
}
}

เฉลย

resource block นี้เหมือนกันเป๊ะ ถูก generate ออกมาให้ทั้งสาม directory — รวมทั้ง dev/main.tf และ staging/main.tf ที่ hardcode environment = "prod" ไว้ใน tags ด้วย นี่คือ artifact แบบ copy-paste ที่สมจริง block นี้ถูกเขียนครั้งเดียวสำหรับ prod แล้ว copy ไปอีกสอง directory โดยไม่มีใครอัปเดตค่าเดียวที่ควรต่างกันตาม environment cost report กับ resource filter ทุกตัวที่ key ด้วย tag นั้นตอนนี้ misattribute spend ของ dev กับ staging ไปเป็น prod เงียบ ๆ และไม่มีอะไรใน Terraform เองจับได้เลย — config นี้เป็น HCL ที่ valid สมบูรณ์แบบและ apply ผ่านสะอาดทั้งสามที่

Mental Model

การ copy-paste directory คือการ optimize เพื่อคุณสมบัติหนึ่ง (isolation) โดยแลกกับอีกอัน (single source of truth) — ไม่มีของฟรีตรงนี้ มีแค่ trade ที่คุณเลือกทำอย่างตั้งใจ หรือสะดุดเข้าไปโดยไม่รู้ตัว ทุกเทคนิคที่ module นี้จะพูดถึงต่อจากนี้ จริง ๆ ก็แค่จุดต่างกันบนเส้น isolation-versus-reuse เส้นเดียวกัน

Trade-offs

ทางเลือก	ได้อะไร	เสียอะไร
copy-paste directory ต่อ environment	isolation เต็มที่ตั้งแต่วันแรก ไม่ต้อง design หรือเรียนรู้ abstraction เลย	ทุก fix ต้องเอาไปใส่มือทุกที่ พิสูจน์ข้างบนว่า drift เงียบ ๆ ได้ภายในหกเดือน
shared config เดียวไม่มีการแยก environment เลย	DRY สูงสุด มีจุดเดียวที่แก้อะไรก็ได้	ไม่มี isolation เลย ความผิดพลาดใน “environment” หนึ่งกระทบทุกอันได้

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

• “drift ระหว่าง environment copy แปลว่ามีใครสักคนประมาท” พิสูจน์ข้างบน: การแก้ prod เป็นสิ่งที่สมเหตุสมผลและถูกต้องในตอนนั้น ปัญหาอยู่ที่โครงสร้าง — ไม่มีอะไรใน tree ที่ copy-paste มา propagate fix ไปเอง
• “พอ copy environment เสร็จแล้วใช้งานได้ ความเสี่ยงก็จบแล้ว” ความเสี่ยงสะสมทบกันไปทุกครั้งที่มีการแก้ต่อจากนั้น — ไม่ใช่ต้นทุนครั้งเดียวที่จ่ายตอน setup แต่เป็นภาษีต่อเนื่อง

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

setup จริงทุกอันต้องมีหลาย environment ที่ isolate กัน (อย่างน้อย dev, staging, prod มักมากกว่านั้น) แต่ทางแก้แบบไร้เดียงสาด้วยการ copy-paste directory ทั้งชุดต่อ environment optimize เพื่อ isolation โดยแลกกับ DRY reuse ทุก fix หรือ tweak ต้องเอาไปใส่มือใน copy ทุกชุด และเพราะการทำซ้ำนั้นเป็นมือ copy แต่ละชุดเลย drift ออกไปเป็น configuration ที่ต่างกันและไม่มีเอกสารบันทึกเมื่อเวลาผ่านไป พิสูจน์ข้างบนด้วย azurerm_network_security_rule fence จริงที่ format ถูกต้อง แต่ diverge กันแค่ค่าเดียว ที่เหลือของ module นี้คือการหาสมดุลระหว่าง reuse กับ isolation แทนที่จะเสียสละอย่างใดอย่างหนึ่งไป โดยใช้สอง isolation level ตามธรรมชาติของ Azure คือ resource group กับ subscription

การ copy-paste directory ของ environment ทั้งชุดต่อหนึ่ง environment มีปัญหาอะไรเป็นการเฉพาะ

Terraform ไม่ยอม apply configuration ที่มีอยู่มากกว่าหนึ่ง directory fix หรือ tweak ที่ทำใน copy หนึ่งไม่ถูก apply ไปยัง copy อื่นโดยอัตโนมัติ ทำให้ copy แต่ละชุด drift ออกไปเป็น configuration ที่ต่างกันและไม่มีเอกสารเมื่อเวลาผ่านไป azurerm provider ไม่อนุญาตให้ copy-paste directory ทำให้ setup แรกเริ่มช้ากว่าการเขียน shared module

สอง goal ที่ขัดแย้งกันซึ่งทุกวิธี multi-environment ต้องหาสมดุลคืออะไร

cost กับ performance การ reuse logic เดียวกันข้ามทุก environment (DRY) พร้อมกับเก็บ state, credential, และ blast radius ของแต่ละ environment ให้ isolate จากกันเต็มที่ การเลือกระหว่าง HCL กับภาษาโปรแกรมมิ่ง general-purpose local state เทียบกับ remote state

ทำไมปัญหา copy-paste-ต่อ-environment ถึงมีแนวโน้มแย่ลงเรื่อย ๆ ตามเวลา แทนที่จะคงที่

ไฟล์ state ของ Terraform โตขึ้นเองทุกวัน Azure เปลี่ยน default ของ resource เองเป็นระยะ การแก้แบบ ad hoc แต่ละครั้งที่ทำกับ copy เดียวสะสมทับกันไปเรื่อย ๆ และไม่มีอะไรบังคับให้ copy กลับมา sync กัน ความต่างที่ไม่มีเอกสารจึงสะสมมากขึ้นตามอายุของ setup Terraform เวอร์ชันใหม่ ๆ ใช้กับ configuration เวอร์ชันเก่าไม่ได้

blast-radius isolation ใน multi-environment setup หมายถึงอะไร

terraform apply รันเร็วแค่ไหน การจำกัดว่าความผิดพลาด, apply ที่พลาด, หรือ credential ที่หลุดออกไปใน environment หนึ่งจะไปถึงได้ไกลแค่ไหน มักทำโดยวาง environment ไว้คนละ resource group หรือ subscription ของ Azure ขนาดของไฟล์ state ของ Terraform จำนวน resource ที่ module เดียวสร้างได้

ตัวอย่าง "dev/staging/prod" ที่ generate มา มี azurerm_linux_virtual_machine block เดียวกันเป๊ะ copy เข้าไปทั้งสาม directory พร้อม tags = { environment = "prod" } hardcode ไว้ทุกชุด ผลที่เกิดขึ้นจริงคืออะไร พิสูจน์ข้างบน

ไม่มีอะไรเกิดขึ้น เพราะ Terraform แก้ tag ให้ตรงกับชื่อ directory เองอัตโนมัติ terraform apply ปฏิเสธไม่รันใน dev/staging เพราะ tag บอกว่า prod apply ผ่านสะอาดทุกที่ เพราะเป็น HCL ที่ valid แต่ resource ของ dev และ staging ทุกตัวตอนนี้ถูก mistagged เป็น prod — cost report กับ resource filter ที่ key ด้วย tag นั้น misattribute spend ไปเงียบ ๆ Terraform แจ้งเตือนตอน plan ทุกครั้งที่ค่า tag ไม่ตรงกับชื่อ directory

Submit

Mark as complete