Resource บางตัวใน HCL มี nested block ที่ซ้ำ ๆ กันหลายชุด เช่น ingress rule ใน security group, statement ใน IAM policy, หรือ environment variables ใน Lambda function การเขียน nested block เดิมซ้ำหลายครั้งทำให้ config ยาวและแก้ไขยาก Dynamic block ช่วยแก้ปัญหานี้โดยให้สร้าง nested block แบบ programmat
การสร้าง infrastructure ในโลกจริง มักมีเงื่อนไข เช่น dev environment ไม่ต้องการ bastion host, staging ใช้ database ขนาดเล็กกว่า prod, หรือบาง region ต้องการ replica HCL มีเครื่องมือสามอย่างที่ทำงานร่วมกันเพื่อรองรับเคสเหล่านี้: conditional expression, count และ for_each บทความนี้จะอธิบายแต่ละเครื่อง
Built-in functions เป็นหนึ่งในเครื่องมือที่ทำให้ HCL มีความยืดหยุ่นสูง ใช้ช่วย transform, คำนวณ, หรือจัดการข้อมูลใน configuration โดยไม่ต้องเขียน custom code ภายนอก ทำให้ config สั้นลงและอ่านง่ายขึ้น บทความนี้แบ่ง functions ที่ใช้บ่อยออกเป็น 5 กลุ่ม: String, Collection, Numeric, Encoding และ Filesys
แม้ remote backend จะมี versioning และ locking แต่อุบัติเหตุยังเกิดได้เสมอ เช่น state rm ผิด resource, migration ล้มเหลวกลางทาง, หรือ bucket ถูกลบโดยไม่ตั้งใจ การมีแผน backup และ recovery ที่ชัดเจนจึงเป็นเรื่องจำเป็น ไม่ใช่ของหรูหรา บทความนี้จะครอบคลุม 3 ประเด็น: วิธี backup state อย่างสม่ำเสมอ, การ
เมื่อทีมขนาดใหญ่ใช้ remote backend ร่วมกัน ความเสี่ยงที่สำคัญที่สุดคือการที่สองคน apply พร้อมกันบน state เดียวกัน state file อาจเสียหาย หรือสร้าง resource ซ้ำในระบบ cloud จริง state locking เป็นกลไกที่ป้องกันปัญหานี้ โดยให้เฉพาะ process เดียวสามารถแก้ไข state ในช่วงเวลาหนึ่ง บทความนี้จะอธิบายหลักการ
เมื่อโปรเจกต์ infrastructure เริ่มขยายใหญ่ ทีมหลายคนต้องแตะ state file ร่วมกัน การใช้ local state ย่อมจบไม่ได้ดี จึงต้องย้ายไปใช้ remote backend ที่ทำหน้าที่เป็นศูนย์กลางเก็บ state file บทความนี้จะเน้นสองตัวเลือกยอดนิยม คือ S3 (บวก DynamoDB lock) สำหรับทีมที่ใช้ AWS เป็นหลัก และ Terraform Cloud ที่เ
State file เป็นหัวใจของ Terraform เพราะเป็นที่เดียวที่เก็บข้อมูลเชื่อมโยงระหว่าง configuration ที่คุณเขียนกับ resource จริงในโลก cloud หากไฟล์นี้หายหรือเสียหาย tool จะไม่รู้จัก resource ใด ๆ และอาจพยายาม recreate ทั้งหมด ทำให้ผู้ใช้งานเจอ downtime หรือ data loss บทความนี้อธิบายว่า state file เก็บอะไ
โปรเจกต์ infrastructure ส่วนใหญ่ต้องรองรับหลาย environment เช่น dev, stage และ prod ในขณะเดียวกัน แต่ละ environment ก็ไม่ควรแชร์ state file เดียวกัน มิฉะนั้นการ apply ใน dev อาจกระทบ prod โดยไม่ตั้งใจ Workspace เป็นกลไกที่ช่วยแยก state ภายใน backend เดียวกันโดยไม่ต้อง copy code ทั้งชุด บทความนี้จะอธ
หลังจากเข้าใจวิธีสร้าง module ด้วยตัวเองแล้ว อีกด้านหนึ่งที่สำคัญไม่แพ้กันคือการใช้ module ที่คนอื่นเขียนไว้แล้วผ่าน Registry สาธารณะ การเลือกใช้ module สำเร็จรูปจะช่วยประหยัดเวลาได้มาก ไม่ต้องเขียน resource พื้นฐานซ้ำ เช่น VPC, RDS หรือ Kubernetes cluster เพราะ module เหล่านี้ถูกทดสอบและใช้งานในโปร
การสร้าง Terraform module ขึ้นมาใหม่จาก scratch อาจดูเหมือนเรื่องง่าย แต่ในทางปฏิบัติ module ที่ใช้งานได้จริงต้องมีโครงสร้างที่ชัดเจน มี interface ที่ออกแบบไว้ล่วงหน้า และมีเอกสารอธิบายการใช้งาน หากโครงสร้างไม่ดีตั้งแต่แรก การนำ module ไปใช้ต่อระหว่างโปรเจกต์จะเจอปัญหาเรื่องชื่อตัวแปรไม่สอดคล้อง, ไม
