บทนำ: ทำไม IT Admin และ System Engineer ต้องเรียนรู้ Terraform ในปี 2026
ในอดีต IT Infrastructure ถูกจัดการด้วยมือเป็นหลัก ไม่ว่าจะเป็นการสร้าง Virtual Machine บน VMware vSphere, การตั้งค่า Firewall Rule บน Palo Alto, การสร้าง DNS Record บน Windows DNS Server, หรือการ Provision EC2 Instance บน AWS ทุกอย่างทำผ่าน GUI หรือ CLI ทีละ Step ด้วยมือ วิธีนี้มีปัญหาหลายอย่าง ไม่สามารถ Reproduce ได้ เพราะไม่มีใครจำได้ว่า Click อะไรบ้างตอนสร้าง Server เมื่อ 6 เดือนก่อน เกิด Configuration Drift เพราะ Server แต่ละตัวถูกแก้ไขต่างกันไปตามเวลา ไม่มี Version Control ไม่สามารถ Review Change ก่อน Apply ได้ ไม่สามารถ Scale ได้ เพราะการสร้าง Server 100 ตัวด้วยมือใช้เวลาหลายวัน และ Human Error สูง เพราะการ Click ผิดจุดเดียวอาจทำให้ Production Down
Terraform เป็นเครื่องมือ Infrastructure as Code (IaC) ที่พัฒนาโดย HashiCorp ช่วยแก้ปัญหาเหล่านี้ทั้งหมด โดยให้ IT Admin และ Engineer เขียน Infrastructure เป็น Code ในภาษา HCL (HashiCorp Configuration Language) จากนั้น Terraform จะอ่าน Code และ Provision Infrastructure ให้อัตโนมัติ ทุกอย่างถูกบันทึกใน Code ที่เก็บใน Git สามารถ Review, Version Control, Reproduce และ Scale ได้
หลายคนอาจคิดว่า Terraform เป็นเครื่องมือของ DevOps Engineer หรือ Developer เท่านั้น แต่ในปี 2026 Terraform กลายเป็นเครื่องมือที่ IT Admin, System Engineer, Network Engineer และ Security Engineer ต้องรู้จักและใช้งานเป็น เพราะ Terraform ไม่ได้จัดการแค่ Cloud Infrastructure แต่สามารถจัดการ On-premise Infrastructure ได้เช่นกัน ตั้งแต่ VMware VM, Active Directory User, DNS Record, F5 Load Balancer, Palo Alto Firewall ไปจนถึง Cisco Switch Configuration ทุกอย่างสามารถจัดการผ่าน Terraform ได้
ในบทความนี้จะอธิบาย Terraform จากมุมมองของ IT Operations ไม่ใช่ Developer โดยครอบคลุม HCL Basics, Terraform Providers สำหรับ IT, การจัดการ VM ด้วย vSphere Provider, การจัดการ Network Device, Cloud Infrastructure, State Management, Modules, Workspaces, CI/CD Integration, การเปรียบเทียบกับ Ansible และ Best Practices สำหรับ IT Team ในปี 2026
Terraform คืออะไร: เข้าใจ Infrastructure as Code จากมุมมอง IT Ops
Infrastructure as Code (IaC) คืออะไร
Infrastructure as Code คือแนวทางที่เปลี่ยนการจัดการ Infrastructure จากการ Manual Configuration (Click GUI, Type CLI) มาเป็นการเขียน Code ที่อธิบาย Desired State ของ Infrastructure จากนั้นใช้เครื่องมือ (เช่น Terraform) อ่าน Code และ Provision/Configure Infrastructure ให้ตรงกับที่ Code กำหนด
ข้อดีของ IaC ได้แก่ Reproducibility สามารถสร้าง Infrastructure ที่เหมือนกันทุกครั้ง ไม่มี Human Error จากการ Click ผิด Version Control ทุก Change ถูกบันทึกใน Git มี History ว่าใครเปลี่ยนอะไรเมื่อไหร่ Code Review ทุก Change สามารถถูก Review โดย Team Member ก่อน Apply Self-documenting Code เป็น Documentation ของ Infrastructure ในตัว ไม่ต้องเขียน Document แยก Scalability สร้าง Server 1 ตัวหรือ 100 ตัวใช้ Code เดียวกัน แค่เปลี่ยน Count Disaster Recovery สามารถ Rebuild Infrastructure ทั้งหมดจาก Code ได้ภายในไม่กี่นาที
Terraform ทำงานอย่างไร
Terraform ทำงานแบบ Declarative คือ IT Admin เขียน Code ที่อธิบาย Desired State ว่าต้องการ Infrastructure เป็นอย่างไร (เช่น ต้องการ VM 3 ตัว มี CPU 4 Core, RAM 8 GB แต่ละตัว) จากนั้น Terraform จะเปรียบเทียบ Desired State กับ Current State (สถานะปัจจุบันของ Infrastructure ที่เก็บใน State File) แล้วคำนวณว่าต้องทำอะไรบ้างเพื่อให้ Current State เปลี่ยนเป็น Desired State (สร้าง VM ใหม่ แก้ไข VM ที่มีอยู่ หรือลบ VM ที่ไม่ต้องการ)
กระบวนการทำงานของ Terraform มี 3 ขั้นตอนหลัก terraform init คือขั้นตอน Initialize ที่ Download Provider Plugin ที่จำเป็น (เช่น AWS Provider, VMware Provider) terraform plan คือขั้นตอน Preview ที่แสดงว่า Terraform จะทำอะไรบ้าง (Create, Modify, Destroy Resource อะไร) โดยไม่มีการเปลี่ยนแปลงจริง terraform apply คือขั้นตอน Execute ที่ Apply Change จริงตาม Plan
นอกจากนี้ยังมี terraform destroy สำหรับลบ Infrastructure ทั้งหมดที่ Terraform สร้าง (ใช้ด้วยความระวัง) terraform state สำหรับจัดการ State File terraform import สำหรับ Import Infrastructure ที่สร้างด้วยมือเข้ามาใน Terraform State
Terraform vs Manual Configuration: ตัวอย่างเปรียบเทียบ
สมมติต้องการสร้าง VM 5 ตัวบน VMware vSphere ด้วยวิธี Manual ต้อง Login vSphere Client, Right-click Cluster, Select New Virtual Machine, กรอก Name, เลือก Datastore, กำหนด CPU/RAM/Disk, เลือก Network, เลือก Template, Configure Guest OS Customization จากนั้น Click Finish ทำซ้ำ 5 ครั้ง ใช้เวลาประมาณ 30-60 นาที และมีโอกาสผิดพลาดสูง
ด้วย Terraform เขียน Code ครั้งเดียวที่อธิบาย VM Specification จากนั้น Set count = 5 Run terraform plan เพื่อ Preview แล้ว terraform apply Terraform จะสร้าง VM 5 ตัวพร้อมกัน ใช้เวลาประมาณ 5-10 นาที ไม่มี Human Error และ Code สามารถใช้ซ้ำได้
HCL Basics: พื้นฐานภาษา HashiCorp Configuration Language
Resources
Resource เป็น Building Block หลักของ Terraform Code แต่ละ Resource คือ Infrastructure Object ที่ Terraform จะ Create และ Manage เช่น VM, Network Interface, DNS Record, Firewall Rule Syntax ของ Resource คือ resource “type” “name” ตามด้วย Block ที่ประกอบด้วย Argument ต่างๆ เช่น resource “vsphere_virtual_machine” “web_server” ตามด้วย name = “web-01”, num_cpus = 4, memory = 8192 เป็นต้น
Resource Type ประกอบด้วย Provider Prefix (เช่น vsphere, aws, azurerm) และ Resource Name (เช่น virtual_machine, instance, resource_group) Resource Name (ชื่อหลัง Type) เป็น Local Name ที่ใช้ Reference ภายใน Terraform Code เท่านั้น ไม่เกี่ยวกับชื่อจริงบน Infrastructure
Data Sources
Data Source ใช้สำหรับ Query ข้อมูลจาก Infrastructure ที่มีอยู่แล้ว โดยไม่ Create หรือ Modify อะไร เช่น Query หา Datastore ที่มีพื้นที่ว่างมากที่สุดบน vSphere, Query หา AMI ID ล่าสุดบน AWS, Query หา Subnet ID ที่มีอยู่แล้วบน Azure Syntax คือ data “type” “name” ตามด้วย Block ที่มี Filter Argument เช่น data “vsphere_datastore” “main” ตามด้วย name = “datastore1” และ datacenter_id = data.vsphere_datacenter.dc.id
Data Source มีประโยชน์มากในการ Reference Infrastructure ที่ถูกสร้างนอก Terraform (เช่น Network ที่ Network Team สร้างด้วยมือ) โดยไม่ต้อง Import เข้ามาใน Terraform State
Variables
Variable ช่วยให้ Code Reusable โดยไม่ต้อง Hard-code ค่าลงใน Resource ตรงๆ แบ่งเป็น Input Variable ที่ประกาศด้วย variable “name” ตามด้วย type, description, default value เช่น variable “vm_count” ตามด้วย type = number, description = “Number of VMs to create”, default = 1 ใช้ Reference ด้วย var.vm_count
Input Variable สามารถกำหนดค่าได้หลายวิธี ตามลำดับ Precedence จากต่ำไปสูง คือ Default Value ใน Variable Block, terraform.tfvars File, Environment Variable (TF_VAR_name), Command Line Flag (-var “name=value”) และ -var-file Flag สำหรับ IT Team แนะนำให้ใช้ terraform.tfvars File สำหรับค่าที่แตกต่างกันในแต่ละ Environment (dev.tfvars, staging.tfvars, prod.tfvars)
Outputs
Output ใช้แสดงค่าหลังจาก Terraform Apply เสร็จ เช่น IP Address ของ VM ที่สร้าง, URL ของ Load Balancer, Connection String ของ Database ประกาศด้วย output “name” ตามด้วย value = expression เช่น output “vm_ip” ตามด้วย value = vsphere_virtual_machine.web_server.default_ip_address Output ยังใช้ส่งค่าระหว่าง Module ได้
Locals
Local Value เป็นตัวแปร Internal ที่ใช้ภายใน Configuration เท่านั้น เหมาะสำหรับ Expression ที่ซับซ้อนที่ถูกใช้หลายที่ ประกาศด้วย locals Block เช่น locals ตามด้วย common_tags = ที่มี environment = var.env, project = “web-platform”, managed_by = “terraform” จากนั้น Reference ด้วย local.common_tags ช่วยลด Duplication และทำให้ Code อ่านง่ายขึ้น
ไฟล์ Structure ที่แนะนำ
Terraform ไม่บังคับโครงสร้างไฟล์ แต่ Convention ที่นิยมคือ main.tf สำหรับ Resource หลัก, variables.tf สำหรับ Variable Declaration, outputs.tf สำหรับ Output Declaration, providers.tf สำหรับ Provider Configuration, terraform.tfvars สำหรับ Variable Values (ไม่ควร Commit ถ้ามี Sensitive Data), versions.tf สำหรับ Terraform และ Provider Version Constraint
Terraform Providers สำหรับ IT: ไม่ใช่แค่ Cloud
Cloud Providers
Provider ที่คนรู้จักมากที่สุดคือ Cloud Provider ได้แก่ AWS Provider (hashicorp/aws) สำหรับจัดการ EC2, VPC, S3, RDS, Lambda และ Service อื่นๆ กว่า 200 Resource Types Azure Provider (hashicorp/azurerm) สำหรับจัดการ Azure VM, VNet, Storage Account, AKS และอื่นๆ GCP Provider (hashicorp/google) สำหรับจัดการ Compute Engine, VPC, Cloud SQL, GKE และอื่นๆ Cloud Provider เหล่านี้เป็นจุดเริ่มต้นที่ดีสำหรับ IT Team ที่เริ่มใช้ Cloud
Virtualization Providers
สำหรับ IT Team ที่ใช้ On-premise Virtualization Terraform มี Provider สำหรับ VMware vSphere Provider (hashicorp/vsphere) เป็น Provider ที่สำคัญมากสำหรับ IT Team ที่ใช้ VMware สามารถจัดการ VM, Template, Folder, Resource Pool, Distributed Switch, Datastore Cluster และอื่นๆ Proxmox Provider (telmate/proxmox) สำหรับ IT Team ที่ใช้ Proxmox VE สามารถจัดการ VM, LXC Container, Storage และ Network Nutanix Provider (nutanix/nutanix) สำหรับ Nutanix AHV
Directory & Identity Providers
Active Directory Provider (hashicorp/ad) สำหรับจัดการ AD Computer Object, OU, GPO Link Azure AD Provider (hashicorp/azuread) สำหรับจัดการ Azure AD User, Group, Application Registration, Conditional Access Policy Okta Provider (okta/okta) สำหรับจัดการ Okta User, Group, Application, Policy
DNS Providers
DNS Provider (hashicorp/dns) สำหรับจัดการ DNS Record บน DNS Server ที่รองรับ RFC 2136 Dynamic DNS Update (รวมถึง Windows DNS Server) Cloudflare Provider (cloudflare/cloudflare) สำหรับจัดการ DNS Record, WAF Rule, Page Rule บน Cloudflare Route53 จัดการผ่าน AWS Provider
Network & Security Providers
Palo Alto Networks Provider (PaloAltoNetworks/panos) สำหรับจัดการ Firewall Rule, NAT Policy, Security Profile, Address Object บน Palo Alto Firewall Fortinet Provider (fortinetdev/fortios) สำหรับจัดการ FortiGate Firewall Policy, Address, VPN F5 BIG-IP Provider (F5Networks/bigip) สำหรับจัดการ Virtual Server, Pool, Member, Monitor, iRule บน F5 Load Balancer Cisco ACI Provider (CiscoDevNet/aci) สำหรับจัดการ Cisco ACI Fabric (Tenant, Bridge Domain, EPG, Contract) Cisco IOS/IOS-XE Provider (CiscoDevNet/iosxe) สำหรับจัดการ Cisco Switch/Router Configuration
Monitoring & ITSM Providers
Datadog Provider (DataDog/datadog) สำหรับจัดการ Monitor, Dashboard, Alert PagerDuty Provider (PagerDuty/pagerduty) สำหรับจัดการ Service, Escalation Policy, Schedule ServiceNow Provider สำหรับจัดการ CMDB Record, Catalog Item Grafana Provider (grafana/grafana) สำหรับจัดการ Dashboard, Data Source, Alert Rule
การจัดการ VM ด้วย VMware vSphere Provider
Setup vSphere Provider
การ Configure vSphere Provider เริ่มจากประกาศ Provider ใน providers.tf โดยกำหนด vsphere server address, user และ password ของ vCenter Server สำหรับ Production ไม่ควร Hard-code Credential ใน Code ควรใช้ Environment Variable (VSPHERE_USER, VSPHERE_PASSWORD) หรือ Terraform Cloud Variable Set หรือ HashiCorp Vault Provider
Query Existing Infrastructure ด้วย Data Sources
ก่อนสร้าง VM ต้อง Query ข้อมูลของ Infrastructure ที่มีอยู่ เช่น Datacenter, Cluster, Datastore, Network, Template ใช้ data “vsphere_datacenter” เพื่อ Query Datacenter, data “vsphere_compute_cluster” เพื่อ Query Cluster, data “vsphere_datastore” เพื่อ Query Datastore, data “vsphere_network” เพื่อ Query Port Group, data “vsphere_virtual_machine” เพื่อ Query Template ที่จะใช้ Clone
สร้าง VM จาก Template
การสร้าง VM ด้วย vSphere Provider ใช้ resource “vsphere_virtual_machine” ระบุ name, resource_pool_id, datastore_id, num_cpus, memory, guest_id, network_interface ที่กำหนด network_id, disk ที่กำหนด label, size, thin_provisioned และ clone block ที่ระบุ template_uuid และ customize block สำหรับ Guest OS Customization เช่น Linux Domain, Hostname, Network Interface Configuration (IPv4 Address, Netmask, Gateway), DNS Server
สามารถใช้ count หรือ for_each เพื่อสร้าง VM หลายตัว เช่น count = var.vm_count แล้วใช้ count.index ใน name และ IP Address เพื่อ Generate ค่าที่ไม่ซ้ำกัน เช่น name = “web-${format(“%02d”, count.index + 1)}” จะได้ web-01, web-02, web-03
Lifecycle Management
หลังจากสร้าง VM แล้ว สามารถ Modify VM ด้วย Terraform ได้ เช่น เพิ่ม CPU/RAM, เพิ่ม Disk, เปลี่ยน Network บาง Modification ต้อง Power Off VM ก่อน (เช่น เพิ่ม CPU ถ้าไม่ได้ Enable Hot-add) Terraform จะ Handle ให้อัตโนมัติ สามารถใช้ lifecycle block เพื่อควบคุม Behavior เช่น prevent_destroy = true เพื่อป้องกันไม่ให้ Terraform ลบ VM โดยไม่ตั้งใจ ignore_changes = [annotation] เพื่อไม่ให้ Terraform แก้ไข Annotation ที่ถูกเปลี่ยนจากภายนอก
การจัดการ Network Devices ด้วย Terraform
Palo Alto Firewall
Palo Alto Provider ช่วยให้จัดการ Firewall Policy ผ่าน Terraform ได้ ซึ่งเป็นประโยชน์มากสำหรับ Security Team ที่ต้องจัดการ Firewall Rule หลายร้อยตัว การ Configure Palo Alto Provider กำหนด hostname, username, password ของ Panorama หรือ Firewall จากนั้นสร้าง Resource เช่น panos_security_policy สำหรับ Firewall Rule, panos_address_object สำหรับ Address Object, panos_service_object สำหรับ Service Object, panos_nat_rule_group สำหรับ NAT Rule
ข้อดีของการใช้ Terraform กับ Palo Alto คือ ทุก Firewall Rule อยู่ใน Code ที่เก็บใน Git มี Version Control, สามารถ Review Firewall Rule Change ผ่าน Pull Request ก่อน Apply, สามารถ Deploy Rule เหมือนกันไปหลาย Firewall พร้อมกัน (Multi-site Deployment), มี Audit Trail ว่าใครเปลี่ยนอะไรเมื่อไหร่
Fortinet FortiGate
Fortinet Provider รองรับการจัดการ FortiGate Firewall ผ่าน Terraform สามารถจัดการ fortios_firewall_policy สำหรับ Firewall Policy, fortios_firewall_address สำหรับ Address Object, fortios_vpn_ipsec_phase1interface และ phase2interface สำหรับ IPsec VPN, fortios_system_interface สำหรับ Interface Configuration
F5 BIG-IP Load Balancer
F5 Provider ช่วยจัดการ Load Balancer Configuration ผ่าน Terraform สามารถจัดการ bigip_ltm_virtual_server สำหรับ Virtual Server, bigip_ltm_pool สำหรับ Server Pool, bigip_ltm_pool_attachment สำหรับ Pool Member, bigip_ltm_monitor สำหรับ Health Monitor, bigip_ltm_irule สำหรับ iRule สำหรับ IT Team ที่ใช้ F5 การจัดการ Virtual Server, Pool และ Member ผ่าน Terraform ช่วยลดเวลาในการ Provision Application Delivery มาก โดยเฉพาะเมื่อต้อง Deploy Application ใหม่ที่ต้อง Create Virtual Server, Pool, Monitor, SSL Profile พร้อมกัน
Cisco Network Devices
Cisco ACI Provider สำหรับ Data Center ที่ใช้ Cisco ACI Fabric สามารถจัดการ Tenant, VRF, Bridge Domain, Subnet, Application Profile, EPG, Contract และ Filter ผ่าน Terraform Cisco IOS-XE Provider สำหรับจัดการ Configuration บน Cisco Switch/Router ที่ Run IOS-XE สามารถจัดการ Interface, VLAN, OSPF, BGP, ACL ผ่าน Terraform
การจัดการ Cloud Infrastructure ด้วย Terraform
AWS Infrastructure
สำหรับ IT Team ที่ใช้ AWS Terraform สามารถจัดการ Infrastructure ทั้งหมดได้ ตัวอย่าง Infrastructure ที่ IT Team มักจัดการบน AWS ได้แก่ VPC และ Networking สร้าง VPC, Subnet (Public/Private), Internet Gateway, NAT Gateway, Route Table, Security Group, Network ACL ทั้งหมดผ่าน Terraform Code EC2 Instance สร้าง Server พร้อม AMI, Instance Type, Key Pair, Security Group, User Data Script สำหรับ Initial Configuration RDS Database สร้าง Database Instance พร้อม Engine, Version, Instance Class, Storage, Backup Configuration, Multi-AZ S3 Storage สร้าง Bucket พร้อม Versioning, Encryption, Lifecycle Policy, Access Policy IAM สร้าง User, Group, Role, Policy สำหรับ Access Control
Azure Infrastructure
สำหรับ IT Team ที่ใช้ Azure Terraform สามารถจัดการ Resource Group, Virtual Network, Subnet, NSG, Azure VM, Azure SQL, Storage Account, Azure AD User/Group, AKS Cluster และอื่นๆ Azure Provider มี Resource Type กว่า 700 ตัว ครอบคลุม Azure Service เกือบทั้งหมด
GCP Infrastructure
สำหรับ IT Team ที่ใช้ GCP Terraform สามารถจัดการ Project, VPC Network, Firewall Rule, Compute Instance, Cloud SQL, GKE Cluster, Cloud Storage Bucket, IAM Binding และอื่นๆ GCP Provider มีจุดเด่นที่ Documentation ดีมาก มี Example สำหรับทุก Resource
Multi-Cloud Management
หนึ่งในจุดแข็งที่สุดของ Terraform คือความสามารถในการจัดการ Multi-Cloud ใน Configuration เดียว สามารถ Declare Provider หลายตัว (AWS + Azure + GCP) ใน Project เดียว และสร้าง Resource ข้าม Cloud ได้ เช่น สร้าง VPN Connection ระหว่าง AWS VPC กับ Azure VNet ทั้งหมดใน Terraform Code เดียว ทำให้ IT Team ที่ใช้ Multi-Cloud สามารถจัดการ Infrastructure ทั้งหมดจากที่เดียวได้
State Management: หัวใจของ Terraform
State File คืออะไร
Terraform State File (terraform.tfstate) เป็นไฟล์ JSON ที่เก็บ Mapping ระหว่าง Terraform Resource ใน Code กับ Infrastructure จริง State File บอก Terraform ว่า Resource ไหนใน Code คือ Resource ไหนบน Infrastructure ถ้าไม่มี State File Terraform จะไม่รู้ว่า Infrastructure ที่มีอยู่ถูกสร้างโดย Terraform หรือไม่ และจะพยายามสร้างใหม่ซ้ำ
State File มีข้อมูล Sensitive (เช่น Password, Connection String) ดังนั้นต้อง Protect State File อย่างเหมาะสม ไม่ควร Commit State File เข้า Git (เพิ่ม terraform.tfstate ใน .gitignore)
Local State vs Remote State
Local State เก็บ State File บน Disk ของเครื่องที่ Run Terraform เหมาะสำหรับ Development หรือ Learning แต่ไม่เหมาะสำหรับ Team เพราะ Team Member แต่ละคนจะมี State File คนละ Copy ทำให้เกิด Conflict
Remote State เก็บ State File บน Remote Storage เช่น AWS S3, Azure Blob Storage, Google Cloud Storage, Terraform Cloud, HashiCorp Consul Remote State เหมาะสำหรับ Team เพราะทุกคนใช้ State File เดียวกัน มี Locking Mechanism ป้องกัน 2 คน Run terraform apply พร้อมกัน มี Encryption สำหรับ Sensitive Data และ มี Versioning สำหรับ Rollback
S3 Backend Configuration
วิธีที่นิยมที่สุดสำหรับ AWS User คือใช้ S3 Backend พร้อม DynamoDB สำหรับ State Locking Configure ใน backend block ภายใต้ terraform block โดยระบุ bucket name, key (path ของ State File ใน S3), region, encrypt = true สำหรับ Encryption at Rest และ dynamodb_table สำหรับ State Locking
ต้องสร้าง S3 Bucket และ DynamoDB Table ก่อน (สามารถสร้างด้วย Terraform เช่นกัน แต่ต้อง Bootstrap ด้วย Local State ก่อน แล้ว Migrate ไป S3 Backend ภายหลัง) S3 Bucket ควร Enable Versioning เพื่อ Protect State File จาก Accidental Delete หรือ Corruption และ Enable Server-Side Encryption
Terraform Cloud Backend
อีกทางเลือกที่ง่ายกว่า S3 Backend คือใช้ Terraform Cloud (Free สำหรับ Team ไม่เกิน 5 คน) Terraform Cloud เก็บ State File, ทำ Locking, Encryption และมี UI สำหรับดู State ได้ นอกจากนี้ยัง Run terraform plan/apply บน Cloud ทำให้ไม่ต้อง Run บนเครื่อง Local Configure ด้วย cloud block ภายใต้ terraform block โดยระบุ organization และ workspace name
Modules: การสร้าง Reusable Infrastructure Code
Module คืออะไร
Module คือ Collection ของ Terraform Configuration Files ที่อยู่ใน Directory เดียวกัน ใช้สำหรับ Package Infrastructure Pattern ที่ถูกใช้ซ้ำ เปรียบเสมือน Function ใน Programming Language ที่ Encapsulate Logic และ Reuse ได้ เช่น Module สำหรับสร้าง VM ที่ประกอบด้วย VM, Disk, Network Interface, DNS Record สามารถ Call Module นี้หลายครั้งเพื่อสร้าง VM หลายตัวที่มี Configuration แตกต่างกัน
Module Structure
Module ประกอบด้วย main.tf ที่มี Resource Definition, variables.tf ที่มี Input Variable ที่ Module รับ, outputs.tf ที่มี Output ที่ Module ส่งออก เก็บไว้ใน Directory แยก เช่น modules/vm, modules/network, modules/database
การ Call Module
Call Module ด้วย module block ระบุ source (Path ไปยัง Module Directory) และ Input Variable เช่น module “web_server” ตามด้วย source = “./modules/vm”, vm_name = “web-01”, num_cpus = 4, memory = 8192, network = “VLAN-100” Output ของ Module Reference ด้วย module.web_server.vm_ip
Terraform Registry
Terraform Registry (registry.terraform.io) เป็น Public Repository ของ Terraform Module ที่ Community สร้างไว้ มี Module สำหรับ AWS VPC, Azure Network, GCP Project, Kubernetes Cluster และอื่นๆ อีกมากมาย สามารถใช้ Module จาก Registry ได้ โดยระบุ source เป็น Registry Path เช่น source = “terraform-aws-modules/vpc/aws” Module จาก Registry เป็นจุดเริ่มต้นที่ดี แต่ควร Review Code ก่อนใช้ใน Production และ Pin Version เสมอ
Private Module Registry
สำหรับองค์กร สามารถสร้าง Private Module Registry ได้ผ่าน Terraform Cloud/Enterprise หรือเก็บ Module ใน Private Git Repository แล้ว Reference ด้วย Git URL Module ที่องค์กรสร้างเอง เช่น Module สำหรับสร้าง VM ตาม Standard ขององค์กร (CPU/RAM Size, Naming Convention, Tag, Backup Policy) ช่วยให้ทุกคนสร้าง VM ตาม Standard เดียวกัน
Workspaces: การจัดการ Multiple Environments
Workspace คืออะไร
Workspace ใน Terraform ช่วยให้ใช้ Code ชุดเดียวกันสำหรับหลาย Environment (dev, staging, production) โดยแต่ละ Workspace มี State File แยกกัน ทำให้ Resource ของแต่ละ Environment ไม่ปนกัน
CLI Workspaces
สร้าง Workspace ด้วย terraform workspace new dev, terraform workspace new staging, terraform workspace new prod สลับ Workspace ด้วย terraform workspace select dev ดู Workspace ทั้งหมดด้วย terraform workspace list ใน Code สามารถ Reference ชื่อ Workspace ด้วย terraform.workspace เช่น name = “web-${terraform.workspace}-01” จะได้ web-dev-01 ใน dev Workspace และ web-prod-01 ใน prod Workspace
Alternative: Directory-based Environments
อีกวิธีที่นิยมคือสร้าง Directory แยกสำหรับแต่ละ Environment เช่น environments/dev, environments/staging, environments/prod แต่ละ Directory มี Backend Configuration และ Variable Values (tfvars) ที่แตกต่างกัน แต่ Call Module เดียวกันจาก modules Directory กลาง วิธีนี้ชัดเจนกว่า Workspace เพราะเห็น Directory Structure แต่มี Code Duplication มากกว่า (Backend Configuration และ Module Call ซ้ำกัน)
สำหรับ IT Team แนะนำให้เริ่มจาก Directory-based Approach เพราะเข้าใจง่ายกว่า แล้วค่อย Migrate ไป Workspace ถ้าต้องการลด Duplication
Terraform Plan/Apply/Destroy Workflow
terraform init
ขั้นตอนแรกที่ต้อง Run ก่อนใช้ Terraform Project ใหม่หรือหลังจากเพิ่ม Provider/Module ใหม่ init จะ Download Provider Plugin จาก Terraform Registry, Initialize Backend (ถ้า Configure Remote Backend), Download Module จาก Source ที่ระบุ Provider Plugin จะถูกเก็บใน .terraform Directory (ไม่ควร Commit เข้า Git เพิ่มใน .gitignore)
terraform plan
ขั้นตอนที่สำคัญที่สุดสำหรับ Safety Plan จะเปรียบเทียบ Desired State (Code) กับ Current State (State File) และแสดงว่าต้องทำอะไรบ้าง Resource ที่จะถูก Create แสดงด้วย + สีเขียว Resource ที่จะถูก Modify แสดงด้วย ~ สีเหลือง Resource ที่จะถูก Destroy แสดงด้วย – สีแดง Resource ที่ต้อง Destroy แล้ว Create ใหม่ (Replace) แสดงด้วย -/+ สีแดง/เขียว
ควร Review Plan อย่างละเอียดก่อน Apply เสมอ โดยเฉพาะ Resource ที่ถูก Destroy หรือ Replace สามารถ Save Plan เป็น File ด้วย terraform plan -out=plan.tfplan แล้ว Apply จาก Plan File ด้วย terraform apply plan.tfplan เพื่อให้แน่ใจว่า Apply ตรงกับที่ Review
terraform apply
Apply Change ตาม Plan Terraform จะ Prompt ให้ Confirm ก่อน Apply (ยกเว้นใช้ -auto-approve Flag ซึ่งไม่แนะนำใน Production) Apply จะ Create, Modify หรือ Destroy Resource ตาม Plan และ Update State File หลัง Apply เสร็จ Terraform จะแสดง Output Values ที่ Define ไว้
terraform destroy
ลบ Infrastructure ทั้งหมดที่ Terraform จัดการ ใช้ด้วยความระวังมาก โดยเฉพาะใน Production ก่อน Destroy Terraform จะแสดง Plan ว่าจะลบอะไรบ้าง และ Prompt ให้ Confirm สามารถ Destroy Resource เฉพาะตัวด้วย -target Flag เช่น terraform destroy -target=aws_instance.web ข้อควรระวัง Destroy ใน Production ควรมี Approval Process (ใช้ Terraform Cloud Sentinel Policy หรือ Manual Approval ใน CI/CD Pipeline)
Import Existing Infrastructure
ทำไมต้อง Import
IT Team ส่วนใหญ่มี Infrastructure ที่สร้างด้วยมือมาก่อน (Legacy Infrastructure) การจะใช้ Terraform จัดการ Infrastructure เหล่านี้ ต้อง Import เข้ามาใน Terraform State ก่อน เพื่อให้ Terraform รู้ว่า Resource ไหนใน Code คือ Resource ไหนบน Infrastructure
วิธี Import
ขั้นตอนการ Import มี 2 ขั้นตอน ขั้นแรกเขียน Resource Block ใน Code ที่ตรงกับ Resource ที่ต้องการ Import เช่น resource “aws_instance” “existing_web” ตามด้วย Argument ที่ต้องการ จากนั้น Run terraform import aws_instance.existing_web i-0123456789abcdef0 โดยระบุ Resource Address ใน Code และ Resource ID บน Infrastructure
หลังจาก Import Terraform จะเพิ่ม Resource เข้า State File แต่ Code ยังอาจไม่ตรงกับ State Run terraform plan เพื่อดูว่ามี Difference อะไรบ้าง แล้วแก้ Code ให้ตรงกับ State จนกว่า terraform plan จะแสดง No changes
terraform import block (ใหม่ใน Terraform 1.5+)
ตั้งแต่ Terraform 1.5 เพิ่ม import block ที่ช่วยให้ Import ได้ง่ายขึ้น เขียน import block ใน Code โดยระบุ to (Resource Address) และ id (Resource ID) จากนั้น Run terraform plan -generate-config-out=generated.tf Terraform จะ Generate Resource Configuration ให้โดยอัตโนมัติ ลดงาน Manual ในการเขียน Resource Block ให้ตรงกับ Infrastructure ที่มีอยู่
CI/CD กับ Terraform
GitHub Actions
GitHub Actions เป็นวิธีที่นิยมที่สุดในการ Automate Terraform Workflow Typical Pipeline ประกอบด้วย On Pull Request Run terraform fmt -check (ตรวจ Code Formatting), terraform validate (ตรวจ Syntax), terraform plan (Preview Change แล้ว Post Comment บน PR) On Merge to Main Run terraform apply -auto-approve (Apply Change อัตโนมัติ)
สำหรับ Production ควรมี Manual Approval Step ก่อน Apply ใช้ GitHub Environments ที่กำหนด Required Reviewers เพื่อให้ Senior Engineer Approve ก่อน Apply
GitLab CI
GitLab CI ก็รองรับ Terraform Workflow เช่นกัน GitLab มี Built-in Terraform HTTP Backend สำหรับเก็บ State File และ Built-in Terraform Report ที่แสดง Plan Output บน Merge Request
Atlantis
Atlantis เป็น Open-source Tool ที่ออกแบบมาเฉพาะสำหรับ Terraform Pull Request Automation Atlantis จะ Run terraform plan อัตโนมัติเมื่อมี Pull Request และ Post Plan Output เป็น Comment บน PR Reviewer สามารถ Review Plan แล้ว Comment atlantis apply เพื่อ Apply Change Atlantis เหมาะสำหรับ Team ที่ต้องการ Simple Terraform Automation โดยไม่ต้อง Configure Complex CI/CD Pipeline
Terraform vs Ansible: เครื่องมือที่ Complementary ไม่ใช่ Competitor
Terraform: Provisioning Tool
Terraform เหมาะสำหรับ Provisioning Infrastructure คือการสร้าง Infrastructure Resource เช่น VM, Network, Storage, Database, Load Balancer Terraform ทำงานแบบ Declarative (บอกว่าต้องการอะไร ไม่ต้องบอกว่าทำอย่างไร) Terraform มี State File ที่ Track Infrastructure Resource ทำให้รู้ว่า Resource ไหนถูกสร้างโดย Terraform Terraform จัดการ Lifecycle ของ Resource (Create, Modify, Destroy) Terraform เหมาะสำหรับ Day 0 และ Day 1 Operation (สร้าง Infrastructure ใหม่)
Ansible: Configuration Management Tool
Ansible เหมาะสำหรับ Configuration Management คือการ Configure Software บน Server ที่สร้างแล้ว เช่น Install Package, Configure Service, Deploy Application, Patch OS Ansible ทำงานแบบ Procedural (ลำดับ Task) แม้จะมี Idempotent Module Ansible ไม่มี State File ไม่ Track Resource แต่ Execute Task ตาม Playbook ทุกครั้ง Ansible เหมาะสำหรับ Day 2 Operation (จัดการ Server ที่สร้างแล้ว)
ใช้ร่วมกัน: Terraform + Ansible Workflow
Best Practice คือใช้ Terraform และ Ansible ร่วมกัน Terraform สร้าง Infrastructure (VM, Network, Storage) จากนั้น Ansible Configure Server (Install Software, Configure Service, Deploy Application) ตัวอย่าง Workflow คือ Terraform สร้าง VM 5 ตัวบน vSphere จากนั้น Terraform Output IP Address ของ VM ทั้ง 5 ตัว Ansible ใช้ IP Address เหล่านั้นเป็น Inventory แล้ว Run Playbook เพื่อ Install Web Server, Deploy Application, Configure Monitoring Agent
สามารถ Integrate ได้หลายวิธี เช่น Terraform provisioner “local-exec” ที่ Run Ansible Playbook หลังจาก VM ถูกสร้าง (ไม่แนะนำสำหรับ Production เพราะ Provisioner มีข้อจำกัดหลายอย่าง) หรือใช้ CI/CD Pipeline ที่ Run Terraform ก่อน แล้ว Run Ansible หลังจาก Terraform เสร็จ หรือใช้ Terraform Output เป็น Ansible Dynamic Inventory
Drift Detection: การตรวจจับ Configuration Drift
Configuration Drift คืออะไร
Configuration Drift เกิดขึ้นเมื่อ Infrastructure จริงไม่ตรงกับ Code ใน Terraform เช่น มีคนเข้าไปแก้ไข VM Configuration ผ่าน GUI โดยไม่ผ่าน Terraform (เช่น เพิ่ม RAM ผ่าน vSphere Client) ทำให้ State File ไม่ตรงกับ Infrastructure จริง
การ Detect Drift
วิธีง่ายที่สุดคือ Run terraform plan เป็นประจำ ถ้ามี Drift Terraform จะแสดงว่ามี Change ที่ต้อง Apply เพื่อให้ Infrastructure กลับมาตรงกับ Code สามารถ Schedule terraform plan ให้ Run ทุกวัน (เช่น ผ่าน CI/CD Pipeline) แล้วส่ง Notification ถ้า Detect Drift Terraform Cloud มี Feature Drift Detection ที่ Run terraform plan อัตโนมัติเป็นระยะ และ Notify เมื่อ Detect Drift
การจัดการ Drift
เมื่อ Detect Drift มี 2 ทางเลือก คือ Apply ให้ Infrastructure กลับมาตรงกับ Code (Terraform จะ Revert Change ที่ทำด้วยมือ) หรือ Update Code ให้ตรงกับ Infrastructure จริง (ถ้า Change ที่ทำด้วยมือเป็นสิ่งที่ต้องการ) สำหรับ Production ควร Enforce Policy ว่าทุก Change ต้องผ่าน Terraform เท่านั้น ห้าม Manual Change
Policy as Code: Sentinel และ OPA
Sentinel (Terraform Cloud/Enterprise)
Sentinel เป็น Policy as Code Framework ของ HashiCorp ที่ช่วยกำหนด Policy สำหรับ Terraform Plan เช่น ห้ามสร้าง VM ที่มี CPU มากกว่า 16 Core (Cost Control), ทุก AWS S3 Bucket ต้อง Enable Encryption, ทุก Resource ต้องมี Tag “owner” และ “project”, ห้าม Destroy Resource ใน Production Workspace, VM ต้องใช้ Approved AMI/Template เท่านั้น Sentinel Policy จะ Evaluate ทุกครั้งที่ Run terraform plan ถ้า Plan ไม่ผ่าน Policy จะ Block ไม่ให้ Apply
Open Policy Agent (OPA)
OPA เป็น Open-source Alternative ของ Sentinel ใช้ภาษา Rego ในการเขียน Policy สามารถใช้ร่วมกับ Terraform ผ่าน conftest หรือ Terraform Cloud Run Tasks OPA เหมาะสำหรับองค์กรที่ไม่ได้ใช้ Terraform Cloud/Enterprise แต่ต้องการ Policy Enforcement
สำหรับ IT Team Policy as Code ช่วย Enforce Standard โดยอัตโนมัติ ไม่ต้องพึ่ง Manual Review อย่างเดียว เช่น ถ้ามี Policy ว่าทุก VM ต้องมี Backup Tag ถ้า Engineer ลืมใส่ Tag Sentinel/OPA จะ Block ไม่ให้ Apply จนกว่าจะเพิ่ม Tag
Terraform Cloud/Enterprise Features
Remote Execution
Terraform Cloud Run terraform plan/apply บน Cloud Infrastructure แทน Local Machine ข้อดีคือ Environment สำหรับ Run Terraform สม่ำเสมอ (ไม่ขึ้นกับ OS/Tool Version ของ Engineer แต่ละคน), Credential ถูกเก็บบน Terraform Cloud ไม่อยู่บน Local Machine, Log และ Output ถูกเก็บบน Terraform Cloud สามารถ Review ย้อนหลังได้
Private Registry
Terraform Cloud มี Private Module Registry สำหรับเก็บ Module ที่องค์กรสร้างเอง ช่วยให้ Team ใช้ Module ร่วมกันได้ง่าย มี Version Control สำหรับ Module
Cost Estimation
Terraform Cloud สามารถ Estimate Cost ของ Infrastructure ที่จะ Provision ก่อน Apply ช่วยให้ IT Manager เห็นค่าใช้จ่ายก่อนตัดสินใจ Approve
Variable Sets
Variable Set ช่วยให้กำหนด Variable ที่ใช้ร่วมกันระหว่าง Workspace เช่น Cloud Credential, Common Tags, Organization-wide Settings ไม่ต้อง Configure ซ้ำใน Workspace แต่ละตัว
Run Tasks
Run Tasks ช่วยให้ Integrate External Tool เข้ากับ Terraform Workflow เช่น Run Security Scan (Snyk, Checkov) ก่อน Apply, Run Cost Estimation (Infracost) ก่อน Apply, Run Compliance Check (OPA) ก่อน Apply ถ้า External Tool แจ้งว่ามีปัญหา สามารถ Block Apply ได้
Best Practices สำหรับ IT Teams
Code Organization
แบ่ง Code ตาม Environment และ Component ใช้ Module สำหรับ Pattern ที่ใช้ซ้ำ ใช้ Naming Convention ที่ชัดเจน (เช่น [env]-[app]-[component]) ใช้ Tag/Label บนทุก Resource สำหรับ Cost Tracking, Owner Identification และ Automation แยก State File ตาม Component (ไม่ควรเก็บ Infrastructure ทั้งหมดใน State File เดียว เพราะถ้า State File เสียจะกระทบทุกอย่าง)
State File Management
ใช้ Remote Backend เสมอสำหรับ Team Work Enable State Locking เพื่อ Prevent Concurrent Modification Enable Encryption สำหรับ State File (At Rest และ In Transit) Backup State File เป็นประจำ ใช้ Separate State File สำหรับ Component ที่แยกกัน (เช่น Network State, Compute State, Database State) อย่าแก้ไข State File ด้วยมือ ใช้ terraform state command เท่านั้น
Security
ไม่ Hard-code Credential ใน Code ใช้ Environment Variable, Terraform Cloud Variables หรือ Vault Provider อย่า Commit terraform.tfstate และ terraform.tfvars (ที่มี Sensitive Data) เข้า Git ใช้ Sensitive Variable (sensitive = true) สำหรับ Variable ที่เป็น Secret ใช้ OIDC/Workload Identity Federation สำหรับ CI/CD Pipeline แทน Static Credential Enable MFA สำหรับ Terraform Cloud Account Implement Least Privilege สำหรับ Cloud Credential ที่ Terraform ใช้
Version Control
Pin Terraform Version ด้วย required_version ใน terraform block เช่น required_version = “>= 1.5.0, < 2.0.0" Pin Provider Version ด้วย required_providers block เช่น version = "~> 2.5″ (อนุญาต 2.5.x แต่ไม่อนุญาต 2.6.0) ใช้ .terraform.lock.hcl สำหรับ Lock Provider Version (ควร Commit เข้า Git) Upgrade Provider Version อย่างระมัดระวัง อ่าน Changelog ก่อน Upgrade เสมอ
Workflow
ใช้ Git Branch สำหรับทุก Change (Feature Branch Workflow) ทำ Code Review ผ่าน Pull Request ก่อน Merge Run terraform plan อัตโนมัติบน PR ด้วย CI/CD ใช้ Manual Approval สำหรับ Production Apply Document ทุก Module ด้วย README และ Example ทดสอบ Module ด้วย Terratest หรือ terraform test (ใหม่ใน Terraform 1.6) ทำ Regular terraform plan เพื่อ Detect Drift
Migration Strategy
สำหรับ IT Team ที่เริ่มใช้ Terraform กับ Infrastructure ที่มีอยู่ แนะนำให้เริ่มจาก Infrastructure ใหม่ ใช้ Terraform สำหรับ Project ใหม่ทุก Project ไม่ต้อง Import Legacy Infrastructure ทั้งหมดในตอนแรก จากนั้น Import Infrastructure ที่สำคัญ เช่น Network Infrastructure, Core VM, Database ทำเป็น Phase ไม่ต้อง Import ทุกอย่างพร้อมกัน สร้าง Module สำหรับ Pattern ที่ใช้บ่อย เช่น Module สร้าง VM ตาม Standard ขององค์กร Train Team ให้ทุกคนสามารถ Read และ Review Terraform Code ได้ แม้จะไม่ได้เขียนเอง สุดท้าย Enforce Policy ว่า Infrastructure ใหม่ทุกอย่างต้องผ่าน Terraform ห้าม Manual Creation
สรุป: Terraform เปลี่ยนวิธีจัดการ IT Infrastructure ในปี 2026
Terraform ไม่ใช่แค่เครื่องมือสำหรับ Cloud หรือ DevOps อีกต่อไป ในปี 2026 Terraform กลายเป็นเครื่องมือมาตรฐานสำหรับ IT Team ทุกระดับ ตั้งแต่การจัดการ VMware VM, Active Directory, DNS, Firewall, Load Balancer ไปจนถึง Multi-Cloud Infrastructure ทุกอย่างสามารถเขียนเป็น Code เก็บใน Git Review ผ่าน Pull Request และ Apply อัตโนมัติผ่าน CI/CD Pipeline
สำหรับ IT Admin และ System Engineer ในไทย Terraform เป็น Skill ที่จำเป็นต้องเรียนรู้ ไม่ใช่ Optional อีกต่อไป องค์กรที่ใช้ IaC จะมี Consistency สูงกว่า (ทุก Server สร้างจาก Code เดียวกัน), Speed เร็วกว่า (สร้าง Infrastructure ภายในนาที ไม่ใช่ชั่วโมง), Safety ปลอดภัยกว่า (ทุก Change ถูก Review ก่อน Apply), Auditability ตรวจสอบได้ (ทุก Change มี Git History) และ Scalability ขยายได้ง่าย (เปลี่ยน Count จาก 1 เป็น 100)
Key Takeaway สำหรับ IT Team คือเริ่มจากเรียน HCL Basics แล้วลอง Provision VM บน Lab ด้วย vSphere Provider หรือสร้าง EC2 Instance บน AWS Free Tier จากนั้นค่อยๆ ขยายไปจัดการ Network, DNS, Firewall สร้าง Module สำหรับ Standard Pattern ขององค์กร Set up Remote Backend สำหรับ State File Integrate กับ CI/CD Pipeline สำหรับ Automated Plan/Apply และ Enforce Policy ว่าทุก Infrastructure Change ต้องผ่าน Terraform Terraform ไม่ได้มาแทน IT Admin แต่ Terraform ทำให้ IT Admin ทำงานได้เร็วขึ้น ผิดพลาดน้อยลง และ Scale ได้มากขึ้น
