Terraform Module
ภาคต่อจากตอนที่แล้ว Infrastructure as Code ‘IaC’
ความเดินตอนที่แล้ว เราได้รู้บริบทที่มา เหตุผล และประโยชน์กันแล้ว นอกจากนี้ยังกล่าวถึง ‘แม่พิมพ์ (module)’ ที่ใช้เป็นแม่แบบในการสร้างทรัพยากรบนคลาวน์
บทนี้เราดำดิ่งเพื่อหาคำตอบกันว่าแม่พิมพ์ โมดูลหรือ Terraform Module แตกต่างจากปกติอย่างไร? คืออะไร? ใช้งานอย่างไร?
Background
สิ่งแรกที่คนเขียน Terraform ต้องเจอคือ ‘resource’ เป็นการประกาศและตั้งค่าให้กับทรัพยากรที่เราอยากสร้างเช่น ชื่อ ขนาด จำนวน
#1 ตัวอย่างการสร้าง VPC และ Subnet โดย ‘Resource’
#2 ตัวอย่างการสร้าง VPC และ Subnet โดย ‘Module’
เห็นได้ว่าตัวอย่างที่ 2 การเลือกใช้งาน module ลดเวลาการทำงานได้เยอะ ไม่ซับซ้อนและเข้าใจง่าย
Terraform Module
คือกล่องสำหรับบรรจุ resource หลากหลายที่ทำงานร่วมกัน
อาจเรียกว่าการแพ็คเข้าด้วยกัน (Package) หรือทำให้ resource สามารถใช้งานซ้ำได้ (Reusable)
หลักการ
การเขียน Module มี 3 ข้อ
- Encapsulation — จัดกลุ่ม infrastructure ที่ต้องใช้งานด้วยกันเสมอ
- Privileges — จำกัดขอบเขตของสิทธิ์และความสามารถของ Module ให้ทำงานเฉพาะหน้าที่ที่มันจำเป็นต้องทำเท่านั้น
- Volatility — แยก long-lived infrastructure ออกจาก short-lived เช่น แยกโฟลเดอร์ควบคุมการสร้าง VPC (ที่เปลี่ยนแปลงไม่บ่อยออก) ออกจากโฟลเดอร์คุมการสร้าง EC2 ทั่วไป ป้องกันการกวนกันโดยไม่จำเป็นและความเสี่ยงที่อาจเกิดขึ้น
การใช้งาน
มีอยู่ 2 ทางเลือก
- เขียนขึ้นใหม่ — เรียนรู้วิธีการเขียน module ที่ประกอบไปด้วย resource ได้ที่นี่
- ใช้งาน module ที่มีอยู่ — เรียกว่า Terraform registry
ข้อสังเกต
จากประสบการณ์การใช้งานพบว่า
- Don’t reinvent the wheel — พยายามใช้งานสิ่งที่มี (และเราเข้าใจมัน) แนะนำเลือกใช้ official module
- Document is important !— ไม่ว่าจะเลือกใช้หรือเขียนใหม่ ควรให้ความสำคัญกับการเขียน document อธิบายการใช้งานและวัตถุประสงค์
- Directory structure — ออกแบบและแยกส่วนตามหลักการ Volatility ไว้ตั้งแต่เนิ่นๆ (การพยายามแยก state file ที่หลังเป็นเรื่องน่าปวดหัว) และคิดเผื่อการทำ automation
หวังว่าจะได้รับประโยชน์จากบทความนี้ ขอบคุณครับ