Home » Terraform Infrastructure as Code สำหรับ Cloud AWS
ไม่มีหมวดหมู่

Terraform Infrastructure as Code สำหรับ Cloud AWS

March 17, 2026
0 Views

ในยุคดิจิทัลที่ทุกองค์กรต่างมุ่งหน้าสู่ Cloud Computing การจัดการโครงสร้างพื้นฐาน (Infrastructure) ให้มีประสิทธิภาพ รวดเร็ว และแม่นยำ กลายเป็นหัวใจสำคัญในการขับเคลื่อนธุรกิจครับ การตั้งค่าเซิร์ฟเวอร์, เครือข่าย, ฐานข้อมูล และบริการอื่น ๆ ด้วยตนเองทีละขั้นตอน ไม่เพียงแต่ใช้เวลานานเท่านั้น แต่ยังเต็มไปด้วยความผิดพลาดที่อาจเกิดขึ้นได้ง่าย และกลายเป็นฝันร้ายของทีม Operations ครับ

แต่จะเกิดอะไรขึ้นถ้าคุณสามารถจัดการโครงสร้างพื้นฐานทั้งหมดได้ด้วยโค้ด? เหมือนกับการเขียนโปรแกรมซอฟต์แวร์ทั่วไป? นี่แหละครับคือแนวคิดของ Infrastructure as Code (IaC) และ Terraform คือหนึ่งในเครื่องมือ IaC ที่ทรงพลังที่สุด ที่จะเข้ามาช่วยให้คุณปลดล็อกศักยภาพของ Cloud AWS ได้อย่างเต็มที่ บทความนี้ SiamLancard.com จะพาคุณดำดิ่งสู่โลกของ Terraform และ AWS ตั้งแต่พื้นฐานไปจนถึงเทคนิคขั้นสูง เพื่อให้คุณสามารถสร้าง จัดการ และปรับปรุงโครงสร้างพื้นฐานบนคลาวด์ได้อย่างมืออาชีพครับ พร้อมแล้วหรือยังครับ? ถ้าพร้อมแล้ว เรามาเริ่มกันเลย!

สารบัญ

Infrastructure as Code (IaC) คืออะไรครับ?

Infrastructure as Code (IaC) คือหลักการในการจัดการและจัดเตรียมโครงสร้างพื้นฐานด้านไอที (เช่น เครือข่าย, เซิร์ฟเวอร์, ฐานข้อมูล, แอปพลิเคชัน) โดยใช้ไฟล์คำสั่ง (Code) แทนการกำหนดค่าด้วยตนเองผ่าน GUI หรือการทำ Script ด้วยมือครับ แนวคิดนี้ช่วยให้โครงสร้างพื้นฐานสามารถถูกกำหนด, จัดเก็บในระบบควบคุมเวอร์ชัน (Version Control System) เช่น Git, และนำไปปรับใช้ซ้ำได้เหมือนกับโค้ดซอฟต์แวร์ทั่วไปเลยครับ

ประโยชน์หลักของ IaC ได้แก่:

  • ความสอดคล้องและลดข้อผิดพลาด: โครงสร้างพื้นฐานทุกครั้งที่ถูกสร้างขึ้นจะเหมือนกัน 100% ลดความเสี่ยงจาก human error ครับ
  • ความเร็วและความคล่องตัว: สามารถสร้างและปรับใช้โครงสร้างพื้นฐานใหม่ได้อย่างรวดเร็วและเป็นอัตโนมัติ ช่วยให้ทีมสามารถทดลองและปรับเปลี่ยนได้อย่างคล่องตัว
  • การควบคุมเวอร์ชัน: การเปลี่ยนแปลงใดๆ กับโครงสร้างพื้นฐานจะถูกบันทึกไว้ในระบบควบคุมเวอร์ชัน ทำให้สามารถตรวจสอบย้อนกลับ (Rollback) หรือเปรียบเทียบการเปลี่ยนแปลงได้ง่าย
  • การทำงานร่วมกัน: ทีมสามารถทำงานร่วมกันในการจัดการโครงสร้างพื้นฐานผ่านโค้ดได้อย่างมีประสิทธิภาพ
  • ประหยัดค่าใช้จ่าย: ลดเวลาและแรงงานในการจัดการโครงสร้างพื้นฐาน รวมถึงลดโอกาสเกิด downtime จากความผิดพลาดครับ

ทำไมต้อง Terraform? ข้อดีของการใช้ Terraform สำหรับ AWS ครับ

ในบรรดาเครื่องมือ IaC มากมาย Terraform โดดเด่นขึ้นมาด้วยเหตุผลหลายประการ โดยเฉพาะอย่างยิ่งเมื่อทำงานกับ Cloud AWS ครับ

  • Multi-Cloud & Hybrid Cloud Support: Terraform ไม่ได้จำกัดอยู่แค่ AWS ครับ แต่ยังรองรับ Cloud Providers ชั้นนำอื่นๆ เช่น Azure, Google Cloud Platform (GCP), Alibaba Cloud รวมถึง On-premises Infrastructure และ SaaS Providers ต่างๆ อีกด้วย ทำให้เป็นเครื่องมือที่ยอดเยี่ยมสำหรับองค์กรที่มีกลยุทธ์แบบ Multi-Cloud หรือ Hybrid Cloud ครับ
  • Declarative Syntax: Terraform ใช้ภาษา HCL (HashiCorp Configuration Language) ที่เป็นแบบ Declarative ซึ่งหมายความว่าคุณเพียงแค่ระบุว่า “ต้องการอะไร” (Desired State) โดยไม่ต้องบอกว่า “ต้องทำอย่างไร” (Imperative Steps) Terraform จะจัดการขั้นตอนการสร้าง, อัปเดต หรือลบ Resource ต่างๆ ให้เองอย่างชาญฉลาดครับ
  • Open-Source และ Community ขนาดใหญ่: การเป็น Open-Source ทำให้ Terraform มีการพัฒนาอย่างต่อเนื่องจาก HashiCorp และมี Community ผู้ใช้งานขนาดใหญ่ทั่วโลกคอยสนับสนุน มี Modules, Plugins และ Solutions มากมายที่ถูกสร้างและแบ่งปัน ทำให้คุณสามารถหาความช่วยเหลือและตัวอย่างการใช้งานได้ง่ายครับ
  • State Management: Terraform เก็บสถานะของโครงสร้างพื้นฐานที่ถูกสร้างขึ้นในไฟล์ที่เรียกว่า “Terraform State File” ซึ่งช่วยให้ Terraform ทราบว่า Resource ใดถูกสร้างขึ้นแล้ว และ Resource ใดที่ต้องมีการเปลี่ยนแปลงเมื่อมีการรันคำสั่งครับ การจัดการ State File อย่างมีประสิทธิภาพเป็นสิ่งสำคัญมากครับ
  • Dependency Graph: Terraform สามารถวิเคราะห์ความสัมพันธ์ (Dependencies) ระหว่าง Resource ต่างๆ ได้อย่างแม่นยำ ทำให้มั่นใจได้ว่า Resource จะถูกสร้างขึ้นตามลำดับที่ถูกต้อง และถูกลบออกในลำดับที่ปลอดภัยครับ
  • Plan ก่อน Apply: คำสั่ง terraform plan ช่วยให้คุณเห็นภาพรวมของการเปลี่ยนแปลงที่จะเกิดขึ้นกับโครงสร้างพื้นฐานก่อนที่จะมีการปรับใช้จริง ทำให้คุณสามารถตรวจสอบและยืนยันการเปลี่ยนแปลงได้อย่างมั่นใจ ลดความเสี่ยงที่จะเกิดความผิดพลาดที่ไม่คาดคิดครับ

Terraform vs. AWS CloudFormation: เลือกอะไรดีครับ?

เมื่อพูดถึง IaC บน AWS สองเครื่องมือหลักที่มักถูกนำมาเปรียบเทียบกันคือ Terraform และ AWS CloudFormation ครับ ทั้งสองมีจุดแข็งและจุดอ่อนที่แตกต่างกัน ดังนี้ครับ

คุณสมบัติ Terraform AWS CloudFormation
Cloud Support Multi-Cloud (AWS, Azure, GCP, On-prem, etc.) AWS-specific (บริการทั้งหมดของ AWS)
ภาษาที่ใช้ HCL (HashiCorp Configuration Language) หรือ JSON YAML หรือ JSON
State Management จัดการโดย Terraform (ต้องมีการกำหนดค่า Remote Backend เช่น S3) จัดการโดย AWS เอง (ใน CloudFormation Service)
การเรียนรู้ HCL ค่อนข้างอ่านง่าย, คอนเซ็ปต์เป็นสากล ภาษา YAML/JSON ค่อนข้างมาตรฐาน, แต่มีคอนเซ็ปต์เฉพาะของ CloudFormation เช่น Stack, Change Set
ฟังก์ชันการทำงาน มี Providers ที่หลากหลาย, รองรับ External Data Sources, Provisioners ผสานรวมกับ AWS Services ได้อย่างสมบูรณ์, มี StackSets สำหรับ Multi-Account/Region
การขยายขีดความสามารถ สร้าง Custom Providers ได้, มี Community Module จำนวนมาก มี Custom Resources ผ่าน AWS Lambda, Registry Modules
การควบคุมเวอร์ชัน ไฟล์โค้ด (.tf) จัดการใน Git ไฟล์ Template (.yaml/.json) จัดการใน Git
การแก้ไขปัญหา Error Message ชัดเจน, Community Support เยอะ Error Message บางครั้งซับซ้อน, ต้องอาศัย AWS Console ในการ Debug

เมื่อไหร่ควรเลือก Terraform?

  • คุณมีกลยุทธ์ Multi-Cloud หรือ Hybrid Cloud ครับ
  • คุณต้องการเครื่องมือเดียวที่สามารถจัดการ Infrastructure ได้ทั้งบน Cloud และ On-premises ครับ
  • คุณต้องการความยืดหยุ่นในการขยายขีดความสามารถด้วย Custom Providers หรือ Modules ครับ
  • ทีมของคุณคุ้นเคยกับ HCL หรือต้องการเรียนรู้ภาษาที่ไม่จำเพาะเจาะจงกับ Cloud รายใดรายหนึ่งครับ

เมื่อไหร่ควรเลือก CloudFormation?

  • คุณใช้ AWS เพียงอย่างเดียว และไม่มีแผนจะใช้ Cloud อื่นๆ ครับ
  • คุณต้องการการผสานรวมที่ลึกซึ้งกับ AWS Services ทุกประเภทโดยไม่ต้องตั้งค่าเพิ่มเติมครับ
  • คุณต้องการให้ AWS เป็นผู้จัดการ State File ให้ทั้งหมดครับ
  • ทีมของคุณคุ้นเคยกับ YAML/JSON และ AWS Ecosystem เป็นอย่างดีครับ

โดยสรุปแล้ว ทั้ง Terraform และ CloudFormation เป็นเครื่องมือ IaC ที่ยอดเยี่ยมครับ การเลือกว่าจะใช้เครื่องมือใดขึ้นอยู่กับความต้องการและบริบทขององค์กรคุณเป็นหลักครับ สำหรับบทความนี้ เราจะเน้นไปที่ Terraform เป็นหลักครับ

แนวคิดหลัก (Core Concepts) ของ Terraform ที่คุณต้องรู้ครับ

ก่อนที่เราจะเริ่มเขียนโค้ด Terraform เรามาทำความเข้าใจแนวคิดพื้นฐานและคำศัพท์สำคัญที่มักจะเจอในการใช้งาน Terraform กันก่อนครับ

Provider

Provider คือปลั๊กอินที่ Terraform ใช้เพื่อโต้ตอบกับ API ของ Cloud หรือ Service ต่างๆ ครับ เช่น aws provider ใช้สำหรับจัดการ Resource บน AWS, azurerm สำหรับ Azure, google สำหรับ GCP ครับ Provider จะทำหน้าที่แปลคำสั่งในไฟล์ Terraform configuration ของคุณให้เป็น API Call ที่ Cloud Service นั้นๆ เข้าใจครับ


# กำหนด AWS Provider และ Region ที่ต้องการใช้งาน
provider "aws" {
  region = "ap-southeast-1" # เช่น สิงคโปร์
}

Resource

Resource คือส่วนประกอบพื้นฐานของ Infrastructure ที่ Terraform สามารถสร้าง, จัดการ, และลบได้ครับ ตัวอย่างเช่น EC2 instance, S3 bucket, VPC, Security Group บน AWS หรือ Virtual Machine บน Azure ครับ แต่ละ Resource จะมี Type และ Argument ที่แตกต่างกันไปตาม Provider นั้นๆ ครับ


# สร้าง S3 Bucket
resource "aws_s3_bucket" "my_first_bucket" {
  bucket = "siamlancard-my-unique-bucket-12345" # ชื่อ Bucket ต้องไม่ซ้ำกันทั่วโลก
  acl    = "private"

  tags = {
    Name        = "MyFirstTerraformBucket"
    Environment = "Dev"
  }
}

Data Source

Data Source ช่วยให้ Terraform สามารถ “อ่าน” ข้อมูลเกี่ยวกับ Resource ที่มีอยู่แล้ว หรือข้อมูลจากแหล่งภายนอก (เช่น AMI ID ล่าสุด, ID ของ VPC ที่มีอยู่) โดยไม่ต้องสร้าง Resource นั้นขึ้นมาใหม่ครับ มีประโยชน์มากเมื่อคุณต้องการอ้างอิงถึง Resource ที่ไม่ได้สร้างโดย Terraform หรือ Resource ที่ถูกจัดการโดยทีมอื่นครับ


# ดึง AMI ID ล่าสุดของ Ubuntu 20.04 LTS สำหรับ region ที่กำหนด
data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

output "ubuntu_ami_id" {
  value = data.aws_ami.ubuntu.id
}

Variables (Input/Output)

  • Input Variables: ใช้สำหรับส่งค่าเข้าสู่ Terraform configuration ของคุณ ทำให้โค้ดมีความยืดหยุ่นและสามารถนำกลับมาใช้ใหม่ได้ง่ายขึ้นครับ เช่น กำหนด Region, Instance Type, หรือ Environment Name ครับ

    
variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = var.instance_type # ใช้ค่าจาก variable
  # ...
}
  • Output Variables: ใช้สำหรับแสดงข้อมูลสำคัญเกี่ยวกับ Infrastructure ที่ถูกสร้างขึ้นออกมาเมื่อ Terraform ทำงานเสร็จสิ้นครับ เช่น Public IP ของ EC2 instance, Endpoint ของ Database หรือ ARN ของ S3 bucket ครับ

    
output "ec2_public_ip" {
  description = "The public IP address of the EC2 instance"
  value       = aws_instance.web_server.public_ip
}

Modules

Module คือ Terraform configuration ที่นำกลับมาใช้ใหม่ได้ ซึ่งถูกจัดระเบียบและห่อหุ้ม Resource หลายๆ ตัวเข้าไว้ด้วยกันครับ ช่วยให้โค้ดของคุณเป็นระเบียบ, ลดความซ้ำซ้อน, และเพิ่มความสามารถในการนำกลับมาใช้ใหม่ (Reusability) ครับ คุณสามารถสร้าง Modules ของตัวเอง หรือใช้ Modules ที่มีอยู่ใน Terraform Registry ได้ครับ


# เรียกใช้งาน Module ที่สร้าง VPC
module "vpc" {
  source = "./modules/vpc" # อ้างอิงถึง path ของ Module
  
  vpc_cidr         = "10.0.0.0/16"
  public_subnets   = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets  = ["10.0.10.0/24", "10.0.11.0/24"]
  
  tags = {
    Project = "MyWebApp"
  }
}

State File

Terraform State File (terraform.tfstate) เป็นไฟล์ JSON ที่ Terraform ใช้บันทึกสถานะปัจจุบันของโครงสร้างพื้นฐานที่ Terraform ได้สร้างและจัดการไว้ครับ ไฟล์นี้มีความสำคัญอย่างยิ่ง เพราะมันคือแผนที่ที่ Terraform ใช้ในการเปรียบเทียบกับ Configuration ของคุณ เพื่อดูว่าต้องมีการเปลี่ยนแปลงอะไรบ้าง หากไฟล์ State หายไปหรือเสียหาย Terraform จะไม่สามารถจัดการ Resource ที่สร้างไปแล้วได้อย่างถูกต้องครับ

Backend

Backend คือวิธีการที่ Terraform ใช้ในการจัดเก็บและจัดการ State File ครับ โดยค่าเริ่มต้น Terraform จะเก็บ State File ไว้ในเครื่อง Local ที่คุณรันคำสั่ง แต่ในการทำงานเป็นทีมหรือใน Production Environment การใช้ Remote Backend เช่น Amazon S3, Azure Blob Storage หรือ HashiCorp Consul เป็นสิ่งจำเป็นอย่างยิ่ง เพื่อให้ State File สามารถเข้าถึงได้จากหลายคนอย่างปลอดภัย และรองรับการล็อก (State Locking) เพื่อป้องกันการเขียนทับกันครับ


# กำหนด S3 เป็น Remote Backend สำหรับ State File
terraform {
  backend "s3" {
    bucket         = "siamlancard-terraform-state" # ชื่อ Bucket ต้องไม่ซ้ำกัน
    key            = "my-app/dev/terraform.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "siamlancard-terraform-lock" # ใช้สำหรับ State Locking
  }
}

Workspace

Terraform Workspaces ช่วยให้คุณจัดการ State File หลายชุดสำหรับ Environment ที่แตกต่างกัน (เช่น dev, staging, prod) โดยใช้ Configuration เดียวกันครับ แทนที่จะต้องคัดลอกโฟลเดอร์ Configuration ทั้งหมด คุณสามารถสลับ Workspace เพื่อรัน Terraform ใน Environment ที่ต้องการได้ครับ


terraform workspace new dev
terraform workspace new staging
terraform workspace select dev
terraform apply

เริ่มต้นใช้งาน Terraform สำหรับ AWS: เตรียมพร้อมก่อนลุยครับ

ก่อนที่เราจะเริ่มเขียนโค้ด Terraform เพื่อสร้าง Infrastructure บน AWS เราต้องมีการเตรียมความพร้อมเบื้องต้นก่อนครับ

ติดตั้ง AWS CLI และกำหนดค่า Credentials

Terraform จะใช้ AWS CLI ในการตรวจสอบสิทธิ์และโต้ตอบกับ AWS API ครับ ดังนั้นคุณต้องติดตั้ง AWS CLI และกำหนดค่า AWS Credentials ให้เรียบร้อยก่อนครับ

  1. ติดตั้ง AWS CLI: ทำตามคำแนะนำบนเว็บไซต์ AWS สำหรับระบบปฏิบัติการของคุณครับ

    อ่านเพิ่มเติมเกี่ยวกับการติดตั้ง AWS CLI

  2. กำหนดค่า AWS Credentials: หลังจากติดตั้งแล้ว ให้รันคำสั่ง aws configure และป้อนข้อมูล Access Key ID, Secret Access Key, Default Region และ Default Output Format ของคุณครับ ควรใช้ IAM User ที่มีสิทธิ์เพียงพอในการจัดการ Resource ที่คุณต้องการสร้างครับ (แนะนำให้ใช้ Least Privilege Principle ครับ)

    
aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: ap-southeast-1
Default output format [None]: json

    หรือคุณสามารถตั้งค่า Environment Variables หรือใช้ AWS Profiles ได้ครับ

ติดตั้ง Terraform

การติดตั้ง Terraform ค่อนข้างตรงไปตรงมาครับ

  1. ดาวน์โหลด Terraform: ไปที่เว็บไซต์ Terraform Downloads และดาวน์โหลดเวอร์ชันที่เหมาะสมกับระบบปฏิบัติการของคุณครับ
  2. แตกไฟล์และย้ายไปยัง PATH: แตกไฟล์ ZIP ที่ดาวน์โหลดมา และย้ายไฟล์ที่ได้ (executable file ชื่อ terraform) ไปยังไดเรกทอรีที่อยู่ใน PATH ของระบบของคุณครับ (เช่น /usr/local/bin สำหรับ Linux/macOS หรือในโฟลเดอร์ที่คุณกำหนดใน Environment Variables สำหรับ Windows)
  3. ตรวจสอบการติดตั้ง: เปิด Terminal/Command Prompt และรันคำสั่งเพื่อตรวจสอบเวอร์ชันของ Terraform ครับ

    
terraform --version

    ถ้าเห็นเวอร์ชันของ Terraform แสดงว่าติดตั้งสำเร็จแล้วครับ

โปรเจกต์ Terraform แรกของคุณ: โครงสร้างไฟล์ครับ

การจัดโครงสร้างโปรเจกต์ Terraform ที่ดีจะช่วยให้การจัดการโค้ดเป็นระเบียบและเข้าใจง่ายขึ้นครับ สำหรับโปรเจกต์เริ่มต้น เราจะใช้โครงสร้างง่ายๆ ก่อนครับ


my-terraform-project/
├── main.tf           # ไฟล์หลักสำหรับ Resource ที่จะสร้าง
├── variables.tf      # ไฟล์สำหรับ Input Variables
├── outputs.tf        # ไฟล์สำหรับ Output Variables
├── providers.tf      # ไฟล์สำหรับกำหนด Provider
└── .terraformignore  # (Optional) คล้าย .gitignore สำหรับ Terraform

ในความเป็นจริง คุณสามารถรวมทุกอย่างไว้ในไฟล์ main.tf ไฟล์เดียวก็ได้ครับ แต่การแยกไฟล์ตามวัตถุประสงค์จะช่วยให้โค้ดของคุณอ่านและจัดการได้ง่ายขึ้นเมื่อโปรเจกต์ใหญ่ขึ้นครับ

สร้าง Infrastructure พื้นฐานบน AWS ด้วย Terraform ครับ

ได้เวลาลงมือสร้าง Infrastructure บน AWS ด้วย Terraform กันแล้วครับ เราจะมาสร้าง VPC, Subnets, Internet Gateway, Security Group และ EC2 Instance กันครับ

กำหนด AWS Provider

เริ่มต้นด้วยการกำหนด AWS Provider ในไฟล์ providers.tf ครับ


# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0" # กำหนดเวอร์ชันของ AWS provider
    }
  }
}

provider "aws" {
  region = "ap-southeast-1" # กำหนด AWS Region ที่ต้องการ (เช่น สิงคโปร์)
}

สร้าง Amazon VPC

ต่อไป เราจะสร้าง Virtual Private Cloud (VPC) ซึ่งเป็นเครือข่ายส่วนตัวบน AWS สำหรับ Resource ของเราครับ เพิ่มโค้ดนี้ในไฟล์ main.tf


# main.tf
resource "aws_vpc" "main_vpc" {
  cidr_block = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "SiamLancard-Terraform-VPC"
  }
}

สร้าง Subnets และ Internet Gateway

ใน VPC ของเรา เราจะสร้าง Public Subnet สองโซน (เพื่อความทนทาน) และ Internet Gateway เพื่อให้ Resource ใน Public Subnet สามารถเข้าถึงอินเทอร์เน็ตได้ครับ


# main.tf (ต่อจาก VPC)

# สร้าง Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main_vpc.id

  tags = {
    Name = "SiamLancard-Terraform-IGW"
  }
}

# สร้าง Public Subnet 1
resource "aws_subnet" "public_subnet_1" {
  vpc_id                  = aws_vpc.main_vpc.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-southeast-1a" # เปลี่ยน AZ ตาม Region ของคุณ
  map_public_ip_on_launch = true # กำหนดให้ EC2 ใน Subnet นี้ได้รับ Public IP อัตโนมัติ

  tags = {
    Name = "SiamLancard-Public-Subnet-1"
  }
}

# สร้าง Public Subnet 2
resource "aws_subnet" "public_subnet_2" {
  vpc_id                  = aws_vpc.main_vpc.id
  cidr_block              = "10.0.2.0/24"
  availability_zone       = "ap-southeast-1b" # เปลี่ยน AZ ตาม Region ของคุณ
  map_public_ip_on_launch = true

  tags = {
    Name = "SiamLancard-Public-Subnet-2"
  }
}

# สร้าง Route Table สำหรับ Public Subnets
resource "aws_route_table" "public_rt" {
  vpc_id = aws_vpc.main_vpc.id

  route {
    cidr_block = "0.0.0.0/0" # Traffic ทั้งหมดออกไปยัง Internet Gateway
    gateway_id = aws_internet_gateway.igw.id
  }

  tags = {
    Name = "SiamLancard-Public-Route-Table"
  }
}

# ผูก Public Subnet 1 เข้ากับ Route Table
resource "aws_route_table_association" "public_rt_association_1" {
  subnet_id      = aws_subnet.public_subnet_1.id
  route_table_id = aws_route_table.public_rt.id
}

# ผูก Public Subnet 2 เข้ากับ Route Table
resource "aws_route_table_association" "public_rt_association_2" {
  subnet_id      = aws_subnet.public_subnet_2.id
  route_table_id = aws_route_table.public_rt.id
}

สร้าง Security Group

Security Group ทำหน้าที่เป็น Firewall สำหรับ EC2 Instance ของเราครับ เราจะสร้าง Security Group ที่อนุญาตให้ SSH (Port 22) และ HTTP (Port 80) เข้ามาได้จากทุกที่ครับ


# main.tf (ต่อจาก Subnets)

resource "aws_security_group" "web_sg" {
  name        = "siamlancard-web-sg"
  description = "Allow HTTP and SSH inbound traffic"
  vpc_id      = aws_vpc.main_vpc.id

  ingress {
    description      = "SSH from VPC"
    from_port        = 22
    to_port          = 22
    protocol         = "tcp"
    cidr_blocks      = ["0.0.0.0/0"] # อนุญาต SSH จากทุกที่ (เพื่อความง่ายในการทดสอบ)
  }

  ingress {
    description      = "HTTP from Internet"
    from_port        = 80
    to_port          = 80
    protocol         = "tcp"
    cidr_blocks      = ["0.0.0.0/0"] # อนุญาต HTTP จากทุกที่
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1" # อนุญาต Outbound Traffic ทั้งหมด
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "SiamLancard-Web-Security-Group"
  }
}

สร้าง Amazon EC2 Instance

สุดท้าย เราจะสร้าง EC2 Instance ใน Public Subnet ของเราครับ เราจะใช้ Data Source เพื่อดึง AMI ID ล่าสุดของ Ubuntu ครับ

สร้างไฟล์ variables.tf เพื่อกำหนด EC2 Instance type และ Key Pair Name ครับ


# variables.tf
variable "instance_type" {
  description = "The EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "key_name" {
  description = "The name of the EC2 Key Pair to use"
  type        = string
  # คุณต้องสร้าง Key Pair ใน AWS Console ก่อน แล้วนำชื่อมาใส่ตรงนี้
  # เช่น default = "my-ssh-key" 
  # หรือระบุค่าเมื่อรัน terraform apply ด้วย -var="key_name=my-ssh-key"
}

แล้วเพิ่มโค้ด EC2 ใน main.tf ครับ


# main.tf (ต่อจาก Security Group)

# ดึง AMI ID ล่าสุดของ Ubuntu Server 22.04 LTS (Jammy Jellyfish)
data "aws_ami" "ubuntu_2204" {
  most_recent = true
  owners      = ["099720109477"] # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "web_server" {
  ami                         = data.aws_ami.ubuntu_2204.id
  instance_type               = var.instance_type
  subnet_id                   = aws_subnet.public_subnet_1.id # เลือก Public Subnet 1
  vpc_security_group_ids      = [aws_security_group.web_sg.id]
  key_name                    = var.key_name # ใช้ Key Pair ที่กำหนดใน variables.tf
  associate_public_ip_address = true # สำคัญสำหรับ EC2 ใน Public Subnet

  # User data เพื่อติดตั้ง Nginx เมื่อ Instance เริ่มทำงาน
  user_data = <<-EOF
              #!/bin/bash
              sudo apt update -y
              sudo apt install -y nginx
              sudo systemctl start nginx
              sudo systemctl enable nginx
              echo "
Hello from Terraform on SiamLancard AWS!
" | sudo tee /var/www/html/index.nginx-debian.html
              EOF

  tags = {
    Name = "SiamLancard-Terraform-WebServer"
  }
}

สร้างไฟล์ outputs.tf เพื่อแสดง Public IP ของ EC2 Instance ครับ


# outputs.tf
output "web_server_public_ip" {
  description = "Public IP address of the web server"
  value       = aws_instance.web_server.public_ip
}

output "web_server_public_dns" {
  description = "Public DNS of the web server"
  value       = aws_instance.web_server.public_dns
}

คำสั่ง Terraform พื้นฐานที่ต้องใช้ครับ: init, plan, apply, destroy

เมื่อเราเขียนโค้ด Terraform เสร็จแล้ว ก็ถึงเวลาที่จะนำไปปรับใช้จริงครับ

  1. terraform init:

    คำสั่งนี้ใช้สำหรับเริ่มต้นไดเรกทอรีการทำงานของ Terraform ครับ มันจะดาวน์โหลด Provider ที่จำเป็น (ในที่นี้คือ aws provider) และทำการเตรียมพร้อม Backend (หากมีการกำหนดค่า Remote Backend) ครับ คุณต้องรันคำสั่งนี้เสมอเมื่อเริ่มโปรเจกต์ใหม่ หรือเมื่อมีการเพิ่ม/อัปเดต Provider หรือ Modules ครับ

    
cd my-terraform-project
terraform init

    คุณควรเห็นข้อความประมาณว่า “Terraform has been successfully initialized!” ครับ

  2. terraform plan:

    คำสั่งนี้จะทำการเปรียบเทียบ Configuration ของคุณกับสถานะปัจจุบันของ Infrastructure (ที่บันทึกไว้ใน State File และบน Cloud จริง) และแสดงให้เห็นว่า Terraform จะทำอะไรบ้างครับ มันจะแสดงรายการ Resource ที่จะถูกสร้าง (+), อัปเดต (~), หรือลบ (-) โดยไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้นจริงบน Cloud ครับ เป็นขั้นตอนที่สำคัญมากในการตรวจสอบความถูกต้องก่อนที่จะ Apply ครับ

    
terraform plan -var="key_name=ชื่อ_key_pair_ของคุณ"

    หมายเหตุ: แทนที่ ชื่อ_key_pair_ของคุณ ด้วยชื่อ Key Pair ที่คุณสร้างใน AWS Console ครับ

  3. terraform apply:

    เมื่อคุณพอใจกับผลลัพธ์ของ terraform plan แล้ว คำสั่ง terraform apply จะทำการปรับใช้การเปลี่ยนแปลงที่วางแผนไว้กับ Infrastructure จริงบน AWS ครับ Terraform จะขอการยืนยันก่อนที่จะดำเนินการครับ

    
terraform apply -var="key_name=ชื่อ_key_pair_ของคุณ"

    พิมพ์ yes เมื่อถูกถามเพื่อยืนยันการสร้าง Resource ครับ หลังจากนั้น Terraform จะเริ่มสร้าง Resource ต่างๆ และแสดง Output Variables ที่เรากำหนดไว้ครับ

    เมื่อทุกอย่างเสร็จสิ้น คุณควรจะสามารถเข้าถึง Public IP หรือ DNS ของ EC2 Instance ที่ได้จาก Output Variable ในเว็บเบราว์เซอร์ของคุณ และเห็นข้อความ “Hello from Terraform on SiamLancard AWS!” ครับ

  4. terraform destroy:

    เมื่อคุณต้องการลบ Infrastructure ที่สร้างขึ้นทั้งหมด หรือส่วนใดส่วนหนึ่ง คำสั่ง terraform destroy จะช่วยคุณได้ครับ มันจะเปรียบเทียบ State File กับ Configuration ของคุณ และลบ Resource ที่ถูกกำหนดไว้ใน Configuration ครับ ระมัดระวังในการใช้คำสั่งนี้ใน Production Environment ครับ

    
terraform destroy -var="key_name=ชื่อ_key_pair_ของคุณ"

    พิมพ์ yes เมื่อถูกถามเพื่อยืนยันการลบ Resource ครับ

ยกระดับการใช้งาน Terraform: เทคนิคขั้นสูงสำหรับมืออาชีพครับ

หลังจากที่คุณคุ้นเคยกับการใช้งาน Terraform พื้นฐานแล้ว เรามาดูเทคนิคขั้นสูงที่จะช่วยให้คุณจัดการ Infrastructure ที่ซับซ้อนขึ้นได้อย่างมีประสิทธิภาพและยืดหยุ่นมากขึ้นครับ

การสร้างและใช้งาน Terraform Modules: ลดความซ้ำซ้อน เพิ่มความยืดหยุ่นครับ

Module คือ Terraform configuration ที่สามารถนำกลับมาใช้ใหม่ได้ ช่วยให้คุณจัดระเบียบโค้ด, ลดความซ้ำซ้อน, และสร้างส่วนประกอบของ Infrastructure ที่เป็นมาตรฐานได้ครับ

โครงสร้าง Module

สมมติว่าคุณต้องการสร้าง VPC ที่มี Subnets และ Internet Gateway บ่อยๆ คุณสามารถสร้าง Module สำหรับ VPC ได้ดังนี้ครับ


my-terraform-project/
├── main.tf           # เรียกใช้ module
├── variables.tf      # input variables สำหรับ root module
├── outputs.tf        # output variables จาก root module
├── providers.tf      # provider สำหรับ root module
└── modules/
    └── vpc/
        ├── main.tf           # Resource สำหรับ VPC module
        ├── variables.tf      # Input variables สำหรับ VPC module
        └── outputs.tf        # Output variables สำหรับ VPC module

ตัวอย่าง modules/vpc/main.tf:


# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = merge(
    var.tags,
    { Name = var.name }
  )
}

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id
  tags = merge(
    var.tags,
    { Name = "${var.name}-igw" }
  )
}

# ตัวอย่างการสร้าง Public Subnet จาก List ของ CIDR
resource "aws_subnet" "public" {
  for_each                = toset(var.public_subnets)
  vpc_id                  = aws_vpc.this.id
  cidr_block              = each.value
  availability_zone       = "${var.region}${index(var.public_subnets, each.value) == 0 ? "a" : "b"}" # ง่ายๆ สำหรับ 2 AZs
  map_public_ip_on_launch = true

  tags = merge(
    var.tags,
    { Name = "${var.name}-public-subnet-${index(var.public_subnets, each.value) + 1}" }
  )
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.this.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.this.id
  }
  tags = merge(
    var.tags,
    { Name = "${var.name}-public-rt" }
  )
}

resource "aws_route_table_association" "public" {
  for_each       = aws_subnet.public
  subnet_id      = each.value.id
  route_table_id = aws_route_table.public.id
}

ตัวอย่าง modules/vpc/variables.tf:


# modules/vpc/variables.tf
variable "name" {
  description = "Name for the VPC and related resources"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
}

variable "public_subnets" {
  description = "List of public subnet CIDR blocks"
  type        = list(string)
}

variable "region" {
  description = "AWS region for the VPC"
  type        = string
}

variable "tags" {
  description = "A map of tags to apply to all resources"
  type        = map(string)
  default     = {}
}

ตัวอย่าง modules/vpc/outputs.tf:


# modules/vpc/outputs.tf
output "vpc_id" {
  description = "The ID of the VPC"
  value       = aws_vpc.this.id
}

output "public_subnet_ids" {
  description = "A list of public subnet IDs"
  value       = [for s in aws_subnet.public : s.id]
}

ตัวอย่างการใช้งาน Module ใน Root Configuration (main.tf)


# main.tf
module "my_network" {
  source = "./modules/vpc" # อ้างอิงถึง path ของ Module

  name           = "SiamLancard-WebApp"
  vpc_cidr       = "10.0.0.0/16"
  public_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  region         = "ap-southeast-1" # ส่งค่า region เข้าไปใน module

  tags = {
    Project     = "SiamLancard"
    Environment = "Dev"
  }
}

# สามารถอ้างอิง Output จาก Module ได้
output "my_vpc_id" {
  value = module.my_network.vpc_id
}

output "my_public_subnets" {
  value = module.my_network.public_subnet_ids
}

# สามารถใช้ VPC ID จาก Module ไปสร้าง EC2 ต่อได้
resource "aws_security_group" "web_sg_module" {
  name        = "siamlancard-web-sg-from-module"
  description = "Allow HTTP and SSH inbound traffic"
  vpc_id      = module.my_network.vpc_id # ใช้ VPC ID จาก Module output
  # ... (ingress/egress rules เหมือนเดิม)
}

การใช้ Modules ช่วยให้โค้ดของคุณ Modular และ Scalable มากขึ้นครับ

การจัดการ Terraform State File อย่างมีประสิทธิภาพและปลอดภัยครับ

State File (.tfstate) คือหัวใจของการทำงานของ Terraform ครับ การจัดการ State File อย่างถูกต้องเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะในสภาพแวดล้อมการทำงานเป็นทีม

Local State vs. Remote State

  • Local State: โดยค่าเริ่มต้น Terraform จะเก็บไฟล์ terraform.tfstate ไว้ในไดเรกทอรีเดียวกับไฟล์ Configuration ของคุณครับ เหมาะสำหรับการทดลองหรือโปรเจกต์ส่วนตัวขนาดเล็ก แต่ไม่เหมาะกับการทำงานเป็นทีม เพราะอาจเกิดปัญหา State ไม่ตรงกัน หรือการเขียนทับกันได้ครับ
  • Remote State: เป็นแนวทางที่แนะนำสำหรับ Production และการทำงานเป็นทีมครับ Remote State จะเก็บ State File ไว้ในบริการจัดเก็บข้อมูลภายนอก เช่น Amazon S3, Azure Blob Storage, HashiCorp Consul หรือ Terraform Cloud ครับ ประโยชน์หลักคือ:

    • การทำงานร่วมกัน: สมาชิกในทีมทุกคนสามารถเข้าถึง State File ล่าสุดได้
    • ความทนทาน: State File ไม่ได้ผูกติดกับเครื่องใดเครื่องหนึ่ง หากเครื่องพัง State ก็ยังปลอดภัย
    • State Locking: Remote Backend ส่วนใหญ่รองรับการล็อก State เพื่อป้องกันไม่ให้ผู้ใช้หลายคนพยายามแก้ไข Infrastructure เดียวกันพร้อมกัน ซึ่งจะป้องกันความขัดแย้งและข้อมูลเสียหายครับ

การใช้ S3 Backend สำหรับ Remote State

Amazon S3 เป็นตัวเลือกที่นิยมมากสำหรับ Remote Backend เนื่องจากมีความทนทานสูง, ความพร้อมใช้งานสูง, และสามารถผสานรวมกับการล็อก State ได้ดีครับ

ขั้นตอน:

  1. สร้าง S3 Bucket: คุณต้องสร้าง S3 Bucket สำหรับเก็บ State File และ DynamoDB Table สำหรับ State Locking ล่วงหน้า (ด้วยมือหรือด้วย Terraform แยกต่างหาก) ครับ

    
# main.tf (ในโปรเจกต์แยกต่างหาก หรือทำด้วยมือ)
resource "aws_s3_bucket" "terraform_state_bucket" {
  bucket = "your-unique-siamlancard-terraform-state-bucket" # ต้องไม่ซ้ำกันทั่วโลก
  acl    = "private"
  versioning {
    enabled = true # เปิด Versioning เพื่อป้องกันการลบหรือเขียนทับโดยไม่ตั้งใจ
  }
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
  tags = {
    Name = "Terraform State Bucket"
  }
}

resource "aws_dynamodb_table" "terraform_locks" {
  name         = "your-unique-siamlancard-terraform-lock-table" # ต้องไม่ซ้ำกัน
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  tags = {
    Name = "Terraform Lock Table"
  }
}
  2. กำหนดค่า Backend ใน providers.tf หรือไฟล์แยกต่างหาก:

    
# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "your-unique-siamlancard-terraform-state-bucket"
    key            = "path/to/your/environment/terraform.tfstate" # กำหนด path สำหรับ State File
    region         = "ap-southeast-1"
    encrypt        = true # เข้ารหัส State File บน S3
    dynamodb_table = "your-unique-siamlancard-terraform-lock-table" # ใช้ DynamoDB สำหรับ State Locking
  }
}
  3. รัน terraform init อีกครั้ง: หลังจากที่คุณกำหนดค่า Backend แล้ว ให้รัน terraform init ครับ Terraform จะตรวจพบการเปลี่ยนแปลงและเสนอให้ย้าย Local State ไปยัง Remote Backend ครับ

    
terraform init

การใช้ Remote State ช่วยเพิ่มความปลอดภัย, ความน่าเชื่อถือ, และความสามารถในการทำงานร่วมกันของทีมได้อย่างมากครับ

การใช้ Input และ Output Variables: กำหนดค่าและดึงข้อมูลครับ

เราได้เห็นตัวอย่างพื้นฐานของ Variables ไปแล้ว แต่ในโปรเจกต์ที่ซับซ้อน Variables มีบทบาทสำคัญในการทำให้ Configuration มีความยืดหยุ่นและนำกลับมาใช้ใหม่ได้ครับ

  • Input Variables (variables.tf):

    คุณสามารถกำหนด Type ของ Variable ได้ (string, number, bool, list, map, object, set) และสามารถให้ค่า Default ได้ หากไม่มีการระบุค่าเมื่อรัน terraform apply ครับ

    
variable "environment" {
  description = "The name of the environment (e.g., dev, staging, prod)"
  type        = string
  default     = "dev"
}

variable "ami_id_map" {
  description = "A map of AMI IDs by region"
  type        = map(string)
  default = {
    "ap-southeast-1" = "ami-0abcdef1234567890" # ตัวอย่าง AMI ID
    "us-east-1"      = "ami-0123456789abcdef0"
  }
}

resource "aws_instance" "app_server" {
  ami           = var.ami_id_map[var.region] # อ้างอิงจาก map และ region variable
  instance_type = "t2.micro"
  tags = {
    Environment = var.environment
  }
}

    คุณสามารถส่งค่า Variable ได้หลายวิธี:

    • -var="key=value" ในคำสั่ง terraform apply
    • ไฟล์ .tfvars (เช่น dev.tfvars, prod.tfvars)
    • Environment Variables (TF_VAR_key=value)

    อ่านเพิ่มเติมเกี่ยวกับการจัดการ Variables ใน Terraform

  • Output Variables (outputs.tf):

    ใช้เพื่อแสดงข้อมูลที่เป็นประโยชน์หลังจาก Terraform apply เสร็จสิ้น คุณสามารถใช้ Output Variables เพื่อเชื่อมโยง Infrastructure ที่สร้างโดย Terraform เข้ากับระบบอื่นๆ ได้ครับ

    
output "vpc_id" {
  description = "The ID of the main VPC"
  value       = aws_vpc.main_vpc.id
}

output "web_server_endpoint" {
  description = "The public endpoint of the web server"
  value       = "http://${aws_instance.web_server.public_ip}"
}

การใช้ Data Sources: ดึงข้อมูลจาก Existing Resources ครับ

นอกจากตัวอย่างการดึง AMI ID แล้ว Data Sources ยังมีประโยชน์มากในการอ้างอิงถึง Resource ที่มีอยู่แล้วบน AWS ซึ่งอาจจะไม่ได้ถูกสร้างโดย Terraform ของคุณเองครับ เช่น

  • ดึง VPC ID ที่มีอยู่เพื่อสร้าง Subnet ภายใน
  • ดึง ID ของ Route Table ที่มีอยู่
  • ดึงข้อมูลจาก S3 Bucket ที่มีอยู่

# ดึงข้อมูลของ VPC ที่มีอยู่ด้วย Tag
data "aws_vpc" "existing_vpc" {
  tags = {
    Name = "MyExistingProdVPC"
  }
}

# ดึงข้อมูล Subnet ที่มีอยู่ใน VPC นั้น
data "aws_subnet" "existing_private_subnet" {
  vpc_id   = data.aws_vpc.existing_vpc.id
  filter {
    name   = "tag:Name"
    values = ["MyExistingPrivateSubnet"]
  }
}

output "existing_vpc_id" {
  value = data.aws_vpc.existing_vpc.id
}

output "existing_private_subnet_id" {
  value = data.aws_subnet.existing_private_subnet.id
}

Data Sources ช่วยลดความจำเป็นในการ hardcode ID หรือ ARN และเพิ่มความยืดหยุ่นในการทำงานกับ Infrastructure ที่มีการจัดการหลายรูปแบบครับ

Provisioners: การรัน Script บน Resource ที่สร้างขึ้นครับ (ข้อควรระวัง)

Provisioners ช่วยให้คุณสามารถรัน Script หรือคำสั่งบน Local Machine หรือบน Remote Server (EC2 Instance) ที่เพิ่งสร้างขึ้นมาได้ครับ Provisioners มักถูกใช้สำหรับ Bootstrap, การติดตั้งซอฟต์แวร์ หรือการกำหนดค่าเริ่มต้นบางอย่างครับ

ประเภทของ Provisioners:

  • file Provisioner: คัดลอกไฟล์จาก Local Machine ไปยัง Remote Resource

    
resource "aws_instance" "web_server" {
  # ...
  provisioner "file" {
    source      = "scripts/install_nginx.sh"
    destination = "/tmp/install_nginx.sh"
  }
  # ...
}
  • remote-exec Provisioner: รัน Script บน Remote Resource ผ่าน SSH หรือ WinRM

    
resource "aws_instance" "web_server" {
  # ...
  provisioner "remote-exec" {
    inline = [
      "sudo chmod +x /tmp/install_nginx.sh",
      "sudo /tmp/install_nginx.sh",
    ]
  }

  connection {
    type        = "ssh"
    user        = "ubuntu" # หรือ ec2-user, centos
    private_key = file("~/.ssh/your-key.pem")
    host        = self.public_ip
  }
  # ...
}
  • local-exec Provisioner: รัน Script บน Local Machine ที่รัน Terraform

    
resource "aws_s3_bucket" "example" {
  bucket = "my-unique-bucket-name"
}

provisioner "local-exec" {
  command = "echo 'Bucket ${aws_s3_bucket.example.id} created successfully!' > creation_log.txt"
}

ข้อควรระวังในการใช้ Provisioners:

แม้ Provisioners จะมีประโยชน์ แต่ ควรใช้เมื่อจำเป็นเท่านั้นครับ โดยทั่วไปแล้ว การใช้ User Data (สำหรับ EC2), AMI ที่ถูกสร้างมาล่วงหน้า (Golden AMI), หรือ Configuration Management Tools เช่น Ansible, Chef, Puppet, SaltStack หรือ AWS Systems Manager จะเป็นวิธีที่ดีกว่าและมีความน่าเชื่อถือสูงกว่าในการกำหนดค่า Resource หลังจากที่ถูกสร้างขึ้นครับ Provisioners อาจทำให้ Infrastructure ไม่เป็น Idempotent และเพิ่มความซับซ้อนในการจัดการ State ครับ

Terraform Workspaces: จัดการหลาย Environments ในโปรเจกต์เดียวครับ

Workspaces ช่วยให้คุณสามารถใช้ Terraform Configuration เดียวกันเพื่อจัดการ Infrastructure สำหรับ Environment ที่แตกต่างกัน เช่น Development, Staging, และ Production โดยแต่ละ Workspace จะมี State File ของตัวเองครับ


# สร้าง Workspace สำหรับ Development
terraform workspace new dev

# สร้าง Workspace สำหรับ Staging
terraform workspace new staging

# สร้าง Workspace สำหรับ Production
terraform workspace new prod

# สลับไปใช้ Workspace 'dev'
terraform workspace select dev

# ตรวจสอบ Workspace ปัจจุบัน
terraform workspace show

# ลบ Workspace (ต้องมั่นใจว่าไม่มี Resource เหลืออยู่)
terraform workspace delete staging

เมื่อคุณอยู่ใน Workspace ใดๆ การรัน terraform apply จะส่งผลต่อ State File ของ Workspace นั้นๆ ครับ คุณสามารถใช้ terraform.workspace เป็น Variable ใน Configuration ของคุณเพื่อปรับแต่ง Resource ตาม Environment ได้ครับ


resource "aws_s3_bucket" "my_app_bucket" {
  bucket = "my-app-${terraform.workspace}-bucket-12345" # ชื่อ Bucket จะเปลี่ยนไปตาม Workspace
  acl    = "private"

  tags = {
    Environment = terraform.workspace
  }
}

ข้อควรระวัง: สำหรับโปรเจกต์ขนาดใหญ่ที่ต้องการการแยก Environment ที่เข้มงวด มักแนะนำให้แยก Configuration File หรือแม้กระทั่งแยก Git Repository สำหรับแต่ละ Environment ไปเลยครับ แต่ Workspaces ก็เป็นทางเลือกที่ดีสำหรับโปรเจกต์ขนาดเล็กถึงกลาง หรือเมื่อต้องการทดสอบ Feature ใหม่ๆ ใน Environment แยกย่อยครับ

แนวทางปฏิบัติที่ดีที่สุด (Best Practices) สำหรับ Terraform ครับ

เพื่อให้การใช้ Terraform มีประสิทธิภาพ, ปลอดภัย, และยั่งยืนในระยะยาว นี่คือแนวทางปฏิบัติที่ดีที่สุดที่แนะนำครับ

  1. ใช้ Version Control System (VCS) เสมอ: เก็บโค้ด Terraform ของคุณไว้ใน Git (หรือ VCS อื่นๆ) เสมอครับ เพื่อให้สามารถติดตามการเปลี่ยนแปลง, ทำงานร่วมกัน, และย้อนกลับเวอร์ชันได้ครับ
  2. ใช้ Remote State และ State Locking: อย่าเก็บ State File ไว้บน Local Machine ในสภาพแวดล้อมการทำงานเป็นทีมหรือ Production ครับ ใช้ Remote Backend (เช่น S3 + DynamoDB) และมั่นใจว่ามีการทำ State Locking ครับ
  3. แบ่ง Infrastructure เป็น Modules ขนาดเล็ก: สร้าง Modules ที่มีขอบเขตชัดเจนและสามารถนำกลับมาใช้ใหม่ได้ครับ เช่น Module สำหรับ VPC, Module สำหรับ EC2 Instance, Module สำหรับ Database ครับ ทำให้โค้ดอ่านง่าย, ลดความซ้ำซ้อน, และจัดการได้ง่ายขึ้นครับ
  4. แยก Environment อย่างชัดเจน: ไม่ว่าจะใช้ Workspaces, แยกโฟลเดอร์, หรือแยก Repository ควรมีวิธีการที่ชัดเจนในการจัดการ Dev, Staging, และ Production Environment เพื่อป้องกันความผิดพลาดครับ
  5. ใช้ Input Variables อย่างเหมาะสม: หลีกเลี่ยงการ Hardcode ค่าที่อาจเปลี่ยนแปลงได้ หรือค่าที่แตกต่างกันไปในแต่ละ Environment ใช้ Input Variables เพื่อให้ Configuration มีความยืดหยุ่นครับ
  6. ใช้ Data Sources สำหรับ Existing Resources: แทนที่จะ Hardcode ID ของ Resource ที่มีอยู่แล้ว ให้ใช้ Data Sources เพื่อดึงข้อมูลเหล่านั้นครับ
  7. ตรวจสอบ terraform plan เสมอ: ก่อนรัน terraform apply ทุกครั้ง ให้รัน terraform plan เพื่อตรวจสอบการเปลี่ยนแปลงที่จะเกิดขึ้นครับ
  8. ใช้ Naming Conventions ที่สอดคล้องกัน: กำหนดรูปแบบการตั้งชื่อ Resource และ Tagging ที่ชัดเจนและสอดคล้องกันทั่วทั้งองค์กร เพื่อให้ง่ายต่อการระบุและจัดการ Resource ครับ
  9. ใช้ Tagging อย่างสม่ำเสมอ: Tagging เป็นสิ่งสำคัญสำหรับ Cost Allocation, การจัดการ Resource, และ Security Policy บน AWS ครับ กำหนด Tagging Strategy ที่ชัดเจนครับ
  10. ใช้ Least Privilege Principle สำหรับ AWS Credentials: กำหนดสิทธิ์ของ IAM User/Role ที่ Terraform ใช้ให้น้อยที่สุดเท่าที่จำเป็นในการสร้าง/จัดการ Resource นั้นๆ ครับ
  11. หลีกเลี่ยงการใช้ Provisioners มากเกินไป: หากเป็นไปได้ ให้ใช้ User Data, Golden AMIs หรือ Configuration Management Tools ที่เหมาะสมกว่าในการกำหนดค่า Resource หลังการสร้างครับ
  12. ใช้ terraform fmt และ terraform validate: สั่ง terraform fmt เพื่อจัดรูปแบบโค้ดให้เป็นมาตรฐาน และ terraform validate เพื่อตรวจสอบความถูกต้องของ Syntax ก่อน Commit โค้ดครับ
  13. อัปเดต Terraform และ Providers อย่างสม่ำเสมอ: ติดตามและอัปเดต Terraform CLI และ Providers เป็นเวอร์ชันล่าสุด เพื่อเข้าถึง Feature ใหม่ๆ และแก้ไข Bug ที่พบครับ

ความปลอดภัยในการใช้ Terraform สำหรับ AWS ครับ

การจัดการ Infrastructure ด้วยโค้ดต้องคำนึงถึงความปลอดภัยอย่างยิ่งครับ เพราะโค้ดที่ผิดพลาดเพียงเล็กน้อยอาจส่งผลกระทบต่อความปลอดภัยของระบบทั้งหมดได้ นี่คือประเด็นสำคัญที่ควรพิจารณาครับ

  1. Least Privilege Principle:

    ให้สิทธิ์ (Permissions) แก่ IAM User/Role ที่ Terraform ใช้ในการโต้ตอบกับ AWS API เท่าที่จำเป็นเท่านั้นครับ เช่น หาก Terraform Configuration ของคุณสร้างแค่ EC2 Instance ก็ไม่ควรมีสิทธิ์ในการลบ S3 Bucket ครับ

  2. การจัดการ Sensitive Data:

    อย่าเก็บข้อมูลที่ละเอียดอ่อน เช่น รหัสผ่าน, API Keys, หรือ Private Keys ไว้ในไฟล์ Terraform Configuration หรือใน Version Control System แบบ Plaintext ครับ ใช้เครื่องมือที่เหมาะสมในการจัดการ Sensitive Data เช่น:

Related Articles
จัดส่งรวดเร็วส่งด่วนทั่วประเทศ
รับประกันสินค้าเคลมง่าย มีใบรับประกัน
ผ่อนชำระได้บัตรเครดิต 0% สูงสุด 10 เดือน
สะสมแต้ม รับส่วนลดส่วนลดและคะแนนสะสม

ติดต่อเรา | LINE: @siamlancard

Facebook | YouTube | LINE OA

เว็บในเครือ: SiamCafe.net | iCafeForex.com | Siam2R.com | XMSignal.com

© 2026 SiamLancard — จำหน่ายการ์ดแลน อุปกรณ์ Server และเครื่องพิมพ์ใบเสร็จ

SiamLancard
Logo
Free Forex EA Download — XM Signal · EA Forex ฟรี
iCafeForex.com - สอนเทรด Forex | SiamCafe.net
Shopping cart