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

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

March 16, 2026
0 Views

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

สารบัญ

1. ยกระดับการจัดการ Cloud AWS ด้วย Terraform: Infrastructure as Code แห่งอนาคต

ในโลกของการพัฒนาซอฟต์แวร์สมัยใหม่ ความเร็วและความสามารถในการปรับขนาด (scalability) เป็นปัจจัยสำคัญที่ทำให้ธุรกิจอยู่รอดและเติบโตได้ครับ การพึ่งพาการจัดการโครงสร้างพื้นฐานด้วยมือ (manual configuration) ไม่ว่าจะเป็นการคลิกผ่าน AWS Console หรือการรันสคริปต์แบบครั้งเดียวจบนั้น กลายเป็นข้อจำกัดที่ทำให้เกิดปัญหามากมายตามมา ไม่ว่าจะเป็น:

  • ความผิดพลาดของมนุษย์ (Human Error): การตั้งค่าที่ซับซ้อนย่อมมีโอกาสผิดพลาดได้ง่ายครับ
  • ความไม่สอดคล้องกัน (Inconsistency): การทำซ้ำด้วยมือยากที่จะให้ผลลัพธ์ที่เหมือนเดิมทุกครั้ง โดยเฉพาะในสภาพแวดล้อมที่แตกต่างกัน (เช่น Dev, Staging, Production)
  • ใช้เวลานานและไม่มีประสิทธิภาพ: การจัดเตรียมโครงสร้างพื้นฐานใหม่ๆ หรือการปรับเปลี่ยนโครงสร้างเดิมเป็นงานที่ใช้เวลามากครับ
  • ขาดการบันทึกและตรวจสอบ: ยากที่จะรู้ว่าใครทำอะไรไปเมื่อไหร่ และยากต่อการย้อนกลับ (rollback) หากเกิดปัญหา
  • ความท้าทายในการทำงานร่วมกัน: เมื่อมีหลายทีมหรือหลายคนเข้ามาจัดการโครงสร้างพื้นฐานพร้อมกัน ก็ยิ่งเพิ่มความซับซ้อนครับ

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

2. Terraform คืออะไร? ทำไมต้องใช้ IaC?

Terraform เป็นเครื่องมือ Open Source ที่พัฒนาโดย HashiCorp เพื่อใช้ในการจัดเตรียมโครงสร้างพื้นฐาน (Infrastructure Provisioning) ด้วยแนวคิด Infrastructure as Code (IaC) ครับ Terraform ใช้ภาษาที่เรียกว่า HashiCorp Configuration Language (HCL) ซึ่งเป็นภาษาเชิงประกาศ (declarative language) ที่ออกแบบมาให้อ่านง่ายและเข้าใจได้ไม่ยากครับ

หัวใจสำคัญของการทำงานของ Terraform คือการที่มันช่วยให้คุณสามารถ “บอก” Terraform ว่าคุณต้องการโครงสร้างพื้นฐานแบบไหน เช่น คุณต้องการ EC2 Instance กี่ตัว, S3 Bucket ชื่ออะไร, VPC มี Subnet กี่อัน และมี Security Group อย่างไรบ้าง โดยไม่ต้องบอกว่า “ทำอย่างไร” ครับ Terraform จะรับหน้าที่ในการคำนวณและดำเนินการสร้าง ปรับเปลี่ยน หรือลบ Resource ต่างๆ บน Cloud Provider ตามที่คุณระบุไว้ในโค้ดโดยอัตโนมัติครับ

ประโยชน์ของการใช้ Infrastructure as Code (IaC)

การนำ IaC มาใช้ ไม่ว่าจะเป็นกับ Terraform หรือเครื่องมืออื่นๆ ก็นำมาซึ่งประโยชน์มหาศาลดังนี้ครับ:

  • ความสอดคล้องและทำซ้ำได้ (Consistency and Repeatability): โค้ด IaC ทำให้แน่ใจได้ว่าโครงสร้างพื้นฐานของคุณจะถูกสร้างขึ้นมาเหมือนเดิมทุกครั้ง ไม่ว่าจะกี่ครั้งก็ตาม ลดโอกาสเกิดความผิดพลาดจากการตั้งค่าด้วยมือครับ
  • ความรวดเร็วและประสิทธิภาพ (Speed and Efficiency): คุณสามารถจัดเตรียมโครงสร้างพื้นฐานที่ซับซ้อนได้ภายในไม่กี่นาที แทนที่จะใช้เวลาเป็นชั่วโมงหรือวันครับ
  • การควบคุมเวอร์ชัน (Version Control): โค้ด IaC สามารถเก็บไว้ใน Git ทำให้คุณสามารถติดตามการเปลี่ยนแปลง ย้อนกลับเวอร์ชัน (rollback) และทำงานร่วมกันในทีมได้อย่างมีระเบียบครับ
  • ลดต้นทุน (Cost Reduction): การจัดการ Resource ที่แม่นยำและรวดเร็วช่วยให้คุณสามารถสร้างและลบ Resource ได้ตามต้องการ ลดการทิ้ง Resource ที่ไม่ได้ใช้งาน ทำให้ประหยัดค่าใช้จ่ายครับ
  • การทำงานร่วมกันที่ดีขึ้น (Improved Collaboration): ทุกคนในทีมสามารถเห็นและเข้าใจโครงสร้างพื้นฐานผ่านโค้ดชุดเดียวกัน ลดความกำกวมในการสื่อสารครับ
  • การกู้คืนจากภัยพิบัติ (Disaster Recovery): หากเกิดเหตุการณ์ที่ไม่คาดฝัน คุณสามารถสร้างโครงสร้างพื้นฐานขึ้นมาใหม่ได้อย่างรวดเร็วจากโค้ด IaC ครับ
  • การปฏิบัติตามกฎระเบียบ (Compliance): โค้ดช่วยให้คุณสามารถบังคับใช้มาตรฐานความปลอดภัยและการปฏิบัติตามกฎระเบียบได้อย่างสม่ำเสมอครับ

3. ทำไม Terraform ถึงโดดเด่นสำหรับการจัดการ AWS?

แม้ว่าจะมีเครื่องมือ IaC อื่นๆ มากมาย แต่ Terraform ก็เป็นตัวเลือกอันดับต้นๆ สำหรับการจัดการ AWS ด้วยเหตุผลหลายประการครับ:

  • รองรับ Multi-Cloud: Terraform ไม่ได้จำกัดอยู่แค่ AWS เท่านั้นครับ แต่ยังรองรับ Cloud Providers ชั้นนำอื่นๆ เช่น Azure, Google Cloud Platform (GCP) และรวมถึง On-Premises Solutions ด้วย ทำให้คุณสามารถใช้เครื่องมือตัวเดียวในการจัดการโครงสร้างพื้นฐานข้ามแพลตฟอร์มได้ ซึ่งเป็นข้อได้เปรียบที่สำคัญเมื่อเทียบกับเครื่องมือเฉพาะของ Cloud เช่น AWS CloudFormation ครับ
  • AWS Provider ที่ครอบคลุม: HashiCorp และชุมชนได้พัฒนา AWS Provider ที่สมบูรณ์แบบและอัปเดตอย่างต่อเนื่อง ทำให้ Terraform สามารถจัดการ Resource เกือบทุกประเภทบน AWS ได้อย่างละเอียดและแม่นยำ ตั้งแต่ EC2, S3, RDS, Lambda ไปจนถึงบริการที่ซับซ้อนขึ้นอย่าง ECS, EKS หรือแม้แต่ AWS Organizations ครับ
  • การจัดการ State File ที่ทรงพลัง: Terraform มีกลไกในการจัดการ State File ที่เป็นหัวใจสำคัญของการทำงาน ซึ่งจะบันทึกสถานะปัจจุบันของโครงสร้างพื้นฐานที่ Terraform ได้สร้างขึ้น การจัดการ State File อย่างถูกวิธี (โดยเฉพาะการใช้ Remote State เช่น S3 Bucket + DynamoDB) ช่วยให้การทำงานร่วมกันของทีมเป็นไปอย่างราบรื่นและป้องกันปัญหาความขัดแย้งครับ
  • การออกแบบแบบ Modular: Terraform สนับสนุนแนวคิด Module ซึ่งช่วยให้คุณสามารถจัดระเบียบโค้ด IaC ให้เป็นบล็อกที่นำกลับมาใช้ซ้ำได้ ทำให้โค้ดสะอาดขึ้น เข้าใจง่ายขึ้น และง่ายต่อการบำรุงรักษาครับ คุณสามารถสร้าง Module สำหรับ VPC, EC2 หรือ RDS ที่คุณใช้งานบ่อยๆ แล้วเรียกใช้ในโปรเจกต์ต่างๆ ได้ทันทีครับ
  • ชุมชนขนาดใหญ่และ Ecosystem ที่แข็งแกร่ง: Terraform มีชุมชนผู้ใช้งานขนาดใหญ่ทั่วโลก ทำให้ง่ายต่อการหาข้อมูล ตัวอย่างโค้ด หรือขอความช่วยเหลือเมื่อเกิดปัญหา นอกจากนี้ยังมีเครื่องมือเสริมและปลั๊กอินมากมายที่ช่วยเพิ่มประสิทธิภาพในการใช้งานครับ
  • ภาษา HCL ที่เรียนรู้และใช้งานง่าย: HashiCorp Configuration Language (HCL) ถูกออกแบบมาให้อ่านและเขียนได้ง่าย แม้จะไม่ใช่โปรแกรมเมอร์มืออาชีพก็สามารถเรียนรู้และเข้าใจได้ไม่ยากครับ

4. หัวใจหลักของ Terraform: Core Concepts ที่ควรรู้

ก่อนที่เราจะลงมือเขียนโค้ดจริง มาทำความเข้าใจกับแนวคิดหลักๆ ของ Terraform กันก่อนนะครับ การเข้าใจสิ่งเหล่านี้จะช่วยให้คุณสามารถใช้งาน Terraform ได้อย่างมีประสิทธิภาพ:

Provider

Provider คือปลั๊กอินที่ Terraform ใช้เพื่อโต้ตอบกับ API ของ Cloud Provider หรือบริการอื่นๆ ครับ เช่น AWS Provider จะอนุญาตให้ Terraform สร้างและจัดการ Resource บน AWS ได้ครับ คุณต้องประกาศ Provider ที่จะใช้ในไฟล์คอนฟิกูเรชันเสมอครับ

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

provider "aws" {
  region = "ap-southeast-1" # กำหนด AWS Region ที่ต้องการ
}

Resource

Resource คือองค์ประกอบของโครงสร้างพื้นฐานที่คุณต้องการสร้างหรือจัดการครับ เช่น EC2 Instance, S3 Bucket, RDS Database, VPC, Subnet, Security Group เป็นต้น แต่ละ Resource จะมี Type (เช่น aws_instance, aws_s3_bucket) และ Name (ชื่อที่คุณกำหนดให้ Resource นั้นๆ ใน Terraform) ครับ

resource "aws_instance" "web_server" { # Type: aws_instance, Name: web_server
  ami           = "ami-0abcdef1234567890" # Amazon Machine Image ID
  instance_type = "t2.micro"             # ชนิดของ Instance
  tags = {
    Name = "MyWebServer"
  }
}

Data Source

Data Source อนุญาตให้ Terraform ดึงข้อมูลจาก Cloud Provider หรือบริการอื่นๆ ที่มีอยู่แล้วครับ แทนที่จะสร้าง Resource ใหม่ คุณสามารถใช้ Data Source เพื่ออ้างอิงถึง Resource ที่มีอยู่ เช่น การดึง AMI ล่าสุด, การค้นหา VPC ที่มีอยู่ หรือการดึงข้อมูลจาก S3 Bucket ครับ

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id # อ้างอิง AMI ID จาก Data Source
  instance_type = "t2.micro"
}

Variables

Variables (ตัวแปร) ช่วยให้โค้ดของคุณมีความยืดหยุ่นและนำกลับมาใช้ซ้ำได้ครับ คุณสามารถกำหนดค่าต่างๆ ที่อาจมีการเปลี่ยนแปลงได้ เช่น Region, Instance Type, ชื่อ S3 Bucket เป็น Variable แทนการ Hardcode ไว้ในโค้ดครับ ช่วยให้คุณสามารถใช้โค้ดชุดเดียวกันในการจัดเตรียมสภาพแวดล้อมที่แตกต่างกันได้ง่ายขึ้นครับ

variable "aws_region" {
  description = "The AWS region to deploy resources in."
  type        = string
  default     = "ap-southeast-1"
}

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

provider "aws" {
  region = var.aws_region # ใช้ตัวแปร
}

resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = var.instance_type # ใช้ตัวแปร
}

Outputs

Outputs คือค่าที่ Terraform จะแสดงผลออกมาหลังจากที่โครงสร้างพื้นฐานถูกสร้างเสร็จเรียบร้อยแล้วครับ เช่น IP Address ของ EC2 Instance, ชื่อของ S3 Bucket หรือ Endpoint ของ Database สิ่งเหล่านี้มีประโยชน์มากในการเชื่อมโยง Resource ต่างๆ เข้าด้วยกัน หรือเพื่อใช้เป็นข้อมูลสำหรับการตั้งค่าในขั้นตอนถัดไปครับ

resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t2.micro"
  tags = {
    Name = "MyWebServer"
  }
}

output "web_server_public_ip" {
  description = "The public IP address of the web server."
  value       = aws_instance.web_server.public_ip # ดึง Public IP จาก Resource ที่สร้าง
}

Modules

Modules คือชุดของ Terraform Configurations ที่ถูกจัดกลุ่มเข้าด้วยกันเพื่อวัตถุประสงค์เฉพาะและสามารถนำกลับมาใช้ซ้ำได้ครับ คุณสามารถสร้าง Module ที่ซับซ้อน เช่น Module สำหรับสร้าง VPC ที่สมบูรณ์แบบ หรือ Module สำหรับ Deploy Application Stack ทั้งหมด แล้วเรียกใช้ Module นั้นๆ ในโปรเจกต์ต่างๆ ได้อย่างง่ายดาย ทำให้โค้ดของคุณเป็นระเบียบและจัดการได้ง่ายขึ้นครับ

# main.tf ในโปรเจกต์หลัก
module "vpc" {
  source = "./modules/vpc" # อ้างอิงไปยังโฟลเดอร์ Module
  vpc_cidr_block = "10.0.0.0/16"
  public_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"]
}

module "web_app" {
  source = "./modules/web_app"
  vpc_id = module.vpc.vpc_id # ส่งค่า Output จาก Module VPC ไปยัง Module Web App
  subnet_id = module.vpc.public_subnet_ids[0]
}

State File

State File เป็นไฟล์ที่สำคัญที่สุดของ Terraform ครับ มันคือไฟล์ JSON ที่ Terraform ใช้บันทึกสถานะปัจจุบันของโครงสร้างพื้นฐานที่มันได้สร้างหรือจัดการไว้บน Cloud Provider ครับ State File จะเก็บข้อมูล Mapping ระหว่าง Resource ที่คุณกำหนดในโค้ด (Desired State) กับ Resource จริงๆ บน Cloud (Actual State) ครับ เมื่อคุณรัน terraform plan หรือ terraform apply Terraform จะเปรียบเทียบ Desired State ในโค้ดกับ Actual State ที่บันทึกไว้ใน State File เพื่อตัดสินใจว่าจะต้องสร้าง, อัปเดต หรือลบ Resource ใดบ้างครับ

การจัดการ State File อย่างถูกต้องเป็นสิ่งสำคัญอย่างยิ่ง โดยเฉพาะในการทำงานเป็นทีม ควรใช้ Remote State ที่เก็บ State File ไว้บน Cloud Storage เช่น S3 Bucket ของ AWS พร้อมกับการล็อก State เพื่อป้องกันการแก้ไขพร้อมกันครับ

Backend

Backend คือการกำหนดว่า Terraform ควรเก็บ State File ไว้ที่ใดครับ โดยค่าเริ่มต้น Terraform จะเก็บ State File ในเครื่องของคุณ (Local State) ซึ่งไม่เหมาะกับการทำงานเป็นทีมครับ Backend เช่น S3, Azure Storage Account, Google Cloud Storage หรือ Terraform Cloud ช่วยให้คุณสามารถเก็บ State File ไว้ในที่ที่ปลอดภัย สามารถเข้าถึงได้จากหลายคน และรองรับการล็อก State ได้ครับ

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket-12345" # ชื่อ S3 Bucket สำหรับเก็บ State
    key            = "dev/network/terraform.tfstate"   # Path ใน S3 Bucket
    region         = "ap-southeast-1"
    encrypt        = true                             # เข้ารหัส State File
    dynamodb_table = "my-terraform-state-lock"        # DynamoDB Table สำหรับล็อก State
  }
}

5. เริ่มต้นใช้งาน Terraform กับ AWS: Step-by-Step พร้อมตัวอย่างโค้ดจริง

มาถึงขั้นตอนที่เราจะลงมือปฏิบัติจริงกันแล้วครับ ในส่วนนี้ เราจะเริ่มต้นด้วยการตั้งค่าสภาพแวดล้อม และสร้าง Resource พื้นฐานบน AWS ด้วย Terraform ครับ

5.1. สิ่งที่ต้องเตรียม (Prerequisites)

ก่อนอื่น คุณต้องติดตั้งเครื่องมือที่จำเป็นและตั้งค่า AWS Credentials ครับ

  1. ติดตั้ง AWS CLI: ใช้สำหรับจัดการ AWS Services จาก Command Line และใช้ในการตั้งค่า AWS Credentials ครับ คุณสามารถดาวน์โหลดได้จาก เว็บไซต์ AWS ครับ
  2. ติดตั้ง Terraform: ดาวน์โหลด Terraform ได้จาก เว็บไซต์ HashiCorp ครับ เลือกเวอร์ชันที่เหมาะสมกับระบบปฏิบัติการของคุณครับ
  3. ตั้งค่า AWS Credentials: Terraform จำเป็นต้องมีสิทธิ์ในการสร้างและจัดการ Resource บน AWS ครับ วิธีที่ปลอดภัยและแนะนำคือการสร้าง IAM User ที่มีสิทธิ์เท่าที่จำเป็น (least privilege) แล้วสร้าง Access Key ID และ Secret Access Key เพื่อใช้ในการยืนยันตัวตนครับ คุณสามารถตั้งค่า Credentials ได้หลายวิธี แต่ที่นิยมคือใช้ AWS CLI เพื่อสร้าง Named Profile ครับ 
    aws configure --profile my-terraform-user
AWS Access Key ID [None]: AKIA...
AWS Secret Access Key [None]: abcdef...
Default region name [None]: ap-southeast-1
Default output format [None]: json

    หรือตั้งค่า Environment Variables:

    export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="abcdef..."
export AWS_DEFAULT_REGION="ap-southeast-1"

    สำหรับบทความนี้ เราจะใช้ Named Profile ที่ชื่อ my-terraform-user ครับ

5.2. โปรเจกต์แรก: สร้าง EC2 Instance บน AWS

เราจะมาสร้าง EC2 Instance แบบง่ายๆ กันครับ สร้างโฟลเดอร์สำหรับโปรเจกต์ของคุณ เช่น my-first-terraform-project และสร้างไฟล์ main.tf, variables.tf, outputs.tf ภายในโฟลเดอร์นั้นครับ

ไฟล์: main.tf

ในไฟล์นี้ เราจะกำหนด Provider, Data Source เพื่อค้นหา AMI ล่าสุด และ Resource สำหรับ EC2 Instance ครับ

# กำหนดเวอร์ชันของ Terraform และ Provider
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  required_version = "~> 1.0" # กำหนดเวอร์ชันของ Terraform CLI
}

# กำหนด AWS Provider และ Region
provider "aws" {
  region  = var.aws_region
  profile = "my-terraform-user" # ใช้ Named Profile ที่ตั้งค่าไว้
}

# Data Source สำหรับค้นหา Ubuntu 20.04 AMI ล่าสุด
data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"] # Canonical
}

# Resource สำหรับ EC2 Instance
resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id # ใช้ AMI ID จาก Data Source
  instance_type = var.instance_type
  key_name      = var.key_pair_name # กำหนดชื่อ Key Pair ที่มีอยู่แล้วบน AWS
  tags = {
    Name        = "MyTerraformWebServer"
    Environment = "Development"
  }
}

# Resource สำหรับ Security Group เพื่ออนุญาต SSH (Port 22)
resource "aws_security_group" "web_sg" {
  name        = "web_server_security_group"
  description = "Allow SSH inbound traffic"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # อนุญาตจากทุกที่ (ไม่แนะนำสำหรับ Production)
  }
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1" # All protocols
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "WebSecurityGroup"
  }
}

# ผูก Security Group เข้ากับ EC2 Instance
resource "aws_network_interface_sg_attachment" "web_sg_attachment" {
  security_group_id    = aws_security_group.web_sg.id
  network_interface_id = aws_instance.web_server.primary_network_interface_id
}

ไฟล์: variables.tf

กำหนดตัวแปรที่ใช้ใน main.tf ครับ

variable "aws_region" {
  description = "The AWS region to deploy resources in."
  type        = string
  default     = "ap-southeast-1"
}

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

variable "key_pair_name" {
  description = "The name of an existing EC2 Key Pair to use for SSH access."
  type        = string
  # คุณต้องเปลี่ยนค่า default เป็นชื่อ Key Pair ที่คุณมีบน AWS
  # หรือสามารถลบ default ออก แล้ว Terraform จะถามเมื่อรัน terraform plan/apply
  default     = "my-ssh-key" 
}

ไฟล์: outputs.tf

แสดงผลลัพธ์ที่สำคัญหลังจากสร้าง EC2 Instance ครับ

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

output "instance_private_ip" {
  description = "The private IP address of the EC2 instance."
  value       = aws_instance.web_server.private_ip
}

output "instance_id" {
  description = "The ID of the EC2 instance."
  value       = aws_instance.web_server.id
}

ขั้นตอนการใช้งาน:

เปิด Terminal/Command Prompt ไปยังโฟลเดอร์โปรเจกต์ของคุณ และรันคำสั่งเหล่านี้ครับ

  1. terraform init:

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

    terraform init

    ผลลัพธ์ควรจะแสดงว่า Terraform ได้เริ่มต้นการทำงานและดาวน์โหลด Provider สำเร็จครับ

  2. terraform plan:

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

    terraform plan

    คุณจะเห็นรายละเอียดว่า Terraform จะสร้าง EC2 Instance, Security Group และ Network Interface SG Attachment ครับ

    หากคุณไม่ได้กำหนด key_pair_name ใน variables.tf หรือไม่มีค่า Default, Terraform จะถามให้คุณป้อนค่าตอนนี้ครับ

    var.key_pair_name
  The name of an existing EC2 Key Pair to use for SSH access.

  Enter a value: my-ssh-key-name # ใส่ชื่อ Key Pair ของคุณ
  3. terraform apply:

    เมื่อคุณพอใจกับแผนที่ terraform plan แสดงแล้ว คุณสามารถรันคำสั่ง terraform apply เพื่อให้ Terraform ดำเนินการตามแผนที่วางไว้ครับ คำสั่งนี้จะสร้าง ปรับเปลี่ยน หรือลบ Resource บน AWS ตามที่คุณระบุไว้ในโค้ด และจะอัปเดต State File ด้วยสถานะล่าสุดครับ

    terraform apply

    Terraform จะแสดงแผนอีกครั้งและขอให้คุณยืนยันด้วยการพิมพ์ yes ครับ

    Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

    หลังจากนั้น Terraform จะใช้เวลาสักครู่ในการสร้าง Resource ครับ เมื่อเสร็จสิ้น คุณจะเห็น Output ที่คุณกำหนดไว้ เช่น Public IP Address ของ EC2 Instance ครับ

    คุณสามารถเข้าไปตรวจสอบใน AWS Console (EC2 Dashboard) เพื่อยืนยันว่า Instance ของคุณถูกสร้างขึ้นมาแล้วครับ

  4. terraform destroy:

    เมื่อคุณต้องการลบโครงสร้างพื้นฐานทั้งหมดที่สร้างด้วย Terraform (เช่น หลังจากทดสอบเสร็จ) คุณสามารถใช้คำสั่ง terraform destroy ครับ คำสั่งนี้จะลบ Resource ทั้งหมดที่ถูกติดตามใน State File ครับ โปรดใช้ด้วยความระมัดระวัง เพราะมันจะลบทุกอย่าง! ครับ

    terraform destroy

    Terraform จะแสดงรายการ Resource ที่จะถูกลบ และขอให้คุณยืนยันด้วยการพิมพ์ yes เช่นเคยครับ

5.3. สร้าง S3 Bucket พร้อม Policy

มาลองสร้าง S3 Bucket และกำหนด Bucket Policy เพื่อควบคุมการเข้าถึงกันบ้างครับ สร้างไฟล์ใหม่ s3.tf ในโฟลเดอร์เดียวกันครับ

# s3.tf
resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-siamlancard-bucket-12345" # ต้องเป็นชื่อที่ไม่ซ้ำกันทั่วโลก
  tags = {
    Name        = "MyTerraformS3Bucket"
    Environment = "Development"
  }
}

# บังคับใช้การบล็อก Public Access ทั้งหมดสำหรับ Bucket นี้
resource "aws_s3_bucket_public_access_block" "my_bucket_public_access_block" {
  bucket = aws_s3_bucket.my_bucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# ตัวอย่าง Bucket Policy (จำกัดการเข้าถึง)
# ในตัวอย่างนี้จะไม่อนุญาตให้ Public เข้าถึงได้ (เนื่องจาก public_access_block ด้านบน)
# แต่คุณสามารถปรับเปลี่ยนเพื่ออนุญาตการเข้าถึงจาก IAM User/Role ที่กำหนดได้
resource "aws_s3_bucket_policy" "my_bucket_policy" {
  bucket = aws_s3_bucket.my_bucket.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect    = "Deny",
        Principal = "*",
        Action    = "s3:GetObject",
        Resource  = "${aws_s3_bucket.my_bucket.arn}/*",
        Condition = {
          Bool = {
            "aws:SecureTransport" = "false"
          }
        }
      }
    ]
  })
}

รัน terraform plan และ terraform apply อีกครั้งเพื่อสร้าง S3 Bucket ครับ

5.4. สร้าง VPC และ Subnet พื้นฐาน

การสร้างเครือข่าย VPC เป็นพื้นฐานสำคัญในการ Deploy Application ครับ เราจะสร้าง VPC, Internet Gateway, Route Table และ Public Subnet ครับ สร้างไฟล์ใหม่ vpc.tf

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

  tags = {
    Name = "main-vpc"
  }
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "main-igw"
  }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.gw.id
  }

  tags = {
    Name = "public-route-table"
  }
}

resource "aws_subnet" "public_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "${var.aws_region}a" # e.g., ap-southeast-1a
  map_public_ip_on_launch = true # EC2 instances in this subnet get public IPs

  tags = {
    Name = "public-subnet-a"
  }
}

resource "aws_route_table_association" "public_a_association" {
  subnet_id      = aws_subnet.public_a.id
  route_table_id = aws_route_table.public.id
}

รัน terraform plan และ terraform apply อีกครั้งเพื่อสร้าง VPC และ Subnet ครับ คุณสามารถใช้ Output เพื่อดึง ID ของ VPC หรือ Subnet ไปใช้ใน Resource อื่นๆ ได้ด้วยครับ

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

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

ปัญหาของ Local State

โดยค่าเริ่มต้น Terraform จะเก็บ State File ชื่อ terraform.tfstate ไว้ในไดเรกทอรีโปรเจกต์ของคุณ (Local State) ซึ่งมีข้อเสียดังนี้ครับ:

  • ไม่เหมาะกับการทำงานเป็นทีม: เมื่อมีหลายคนทำงานในโปรเจกต์เดียวกัน แต่ละคนจะมี Local State ของตัวเอง ซึ่งทำให้เกิดความไม่สอดคล้องกันและโอกาสเกิดการเขียนทับ (overwrite) ได้ง่าย
  • เสี่ยงต่อข้อมูลสูญหาย: หากเครื่องของคุณเสียหาย State File ก็จะหายไปด้วย ทำให้ Terraform ไม่สามารถติดตาม Resource ที่คุณสร้างไว้ได้อีกต่อไป
  • ไม่รองรับการล็อก (Locking): Local State ไม่สามารถป้องกันไม่ให้หลายคนรัน terraform apply พร้อมกัน ซึ่งอาจทำให้เกิดความเสียหายได้

การใช้ S3 Bucket และ DynamoDB สำหรับ Remote State

วิธีที่ดีที่สุดในการจัดการ State File สำหรับโปรเจกต์ที่ใช้งานจริงและทำงานเป็นทีมคือการใช้ Remote State ครับ และสำหรับ AWS การใช้ S3 Bucket ร่วมกับ DynamoDB เป็นวิธีที่นิยมและมีประสิทธิภาพสูงสุดครับ

  • S3 Bucket: ใช้สำหรับจัดเก็บ State File ครับ S3 มีความทนทานสูง (durability) และพร้อมใช้งานสูง (availability) ทำให้ State File ของคุณปลอดภัยจากการสูญหาย
  • DynamoDB: ใช้สำหรับ State Locking ครับ เมื่อมีผู้ใช้คนหนึ่งกำลังรัน terraform apply, DynamoDB Table จะทำหน้าที่ล็อก State File นั้นไว้ ทำให้ผู้ใช้คนอื่นไม่สามารถรันคำสั่งที่เปลี่ยนแปลง State ได้พร้อมกัน ป้องกันการเกิดความขัดแย้งและข้อมูลเสียหายครับ

ขั้นตอนการตั้งค่า Remote State บน AWS

  1. สร้าง S3 Bucket: สร้าง S3 Bucket ที่จะใช้เก็บ State File ครับ ชื่อ Bucket ต้องไม่ซ้ำกันทั่วโลกครับ
  2. สร้าง DynamoDB Table: สร้าง DynamoDB Table ที่จะใช้สำหรับ State Locking ครับ Table นี้ควรมี Partition Key ชื่อ LockID (เป็น String Type) ครับ

คุณสามารถสร้าง S3 Bucket และ DynamoDB Table ด้วยมือผ่าน AWS Console หรือจะใช้ Terraform สร้างตัวมันเองก่อนก็ได้ครับ (ซึ่งเป็นแนวทางปฏิบัติทั่วไปสำหรับการสร้าง Infrastructure พื้นฐาน)

ตัวอย่างโค้ด Backend Configuration (ใน main.tf)

เพิ่ม block backend "s3" ภายใน terraform { ... } block ในไฟล์ main.tf ของคุณครับ

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

  # กำหนด Remote State Backend เป็น S3
  backend "s3" {
    bucket         = "my-terraform-state-siamlancard-2023" # ชื่อ S3 Bucket ของคุณ (ต้องไม่ซ้ำกัน)
    key            = "environments/dev/my-first-project.tfstate" # Path ของ State File ภายใน Bucket
    region         = "ap-southeast-1"
    encrypt        = true                             # เข้ารหัส State File
    dynamodb_table = "terraform-state-lock-siamlancard" # ชื่อ DynamoDB Table สำหรับล็อก State
  }
}

# ... (ส่วน provider และ resource อื่นๆ) ...

หลังจากเพิ่ม Backend Configuration แล้ว คุณต้องรัน terraform init อีกครั้งครับ Terraform จะตรวจพบว่าคุณได้ตั้งค่า Backend ใหม่ และจะถามว่าคุณต้องการย้าย State File จาก Local ไปยัง Remote State หรือไม่ครับ

terraform init

# ... (ข้อความอื่นๆ) ...

Successfully configured the S3 backend! Terraform will now
persist and retrieve its state from this configuration. If
you wish to revert this change, run "terraform init --backend=false".

If you have existing state that you'd like to move to the new remote backend,
run "terraform init -migrate-state".

หากคุณมี State File เก่าอยู่ในเครื่อง ให้รัน terraform init -migrate-state เพื่อย้าย State ไปยัง S3 ครับ

ข้อควรระวัง: การตั้งค่า Backend ควรทำในโปรเจกต์หลัก (Root Module) เท่านั้น ไม่ควรตั้งค่า Backend ใน Sub-Modules ครับ

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

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

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

แนวคิดของ Module

Module คือคอนเทนเนอร์สำหรับ Terraform Configurations หลายๆ รายการ ที่ถูกจัดกลุ่มเข้าด้วยกันเป็นหน่วยเดียวเพื่อวัตถุประสงค์เฉพาะครับ ทุกๆ โปรเจกต์ Terraform ที่คุณเขียนเป็น Root Module อยู่แล้วครับ แต่คุณสามารถสร้าง Sub-Modules ที่สามารถเรียกใช้จาก Root Module หรือจาก Module อื่นๆ ได้ครับ

ประโยชน์ของการใช้ Module

  • การนำกลับมาใช้ซ้ำ (Reusability): คุณสามารถสร้าง Module สำหรับ Resource ที่ใช้บ่อยๆ (เช่น VPC, EC2, RDS) แล้วนำไปใช้ในหลายๆ โปรเจกต์หรือหลายๆ สภาพแวดล้อมได้ครับ
  • การจัดระเบียบโค้ด (Code Organization): Modules ช่วยให้โค้ดของคุณเป็นระเบียบ เข้าใจง่าย และจัดการได้ง่ายขึ้น
  • การทำงานร่วมกัน (Collaboration): ทีมงานสามารถพัฒนาและบำรุงรักษา Modules แยกกันได้ ทำให้การทำงานร่วมกันมีประสิทธิภาพมากขึ้น
  • ลดความซับซ้อน (Reduced Complexity): Modules ช่วยให้คุณสามารถสร้างโครงสร้างพื้นฐานที่ซับซ้อนได้ด้วยการเขียนโค้ดที่กระชับและเข้าใจง่ายขึ้น

โครงสร้างของ Module

Module โดยทั่วไปจะอยู่ในโฟลเดอร์แยกต่างหาก และมีโครงสร้างคล้ายกับ Root Module ทั่วไปครับ

my-project/
  main.tf
  variables.tf
  outputs.tf
  modules/
    vpc/
      main.tf
      variables.tf
      outputs.tf
    ec2-instance/
      main.tf
      variables.tf
      outputs.tf

ตัวอย่างการสร้างและเรียกใช้ Module (Module สำหรับ VPC)

สมมติว่าเราต้องการสร้าง Module สำหรับ VPC ครับ

1. สร้างไฟล์ใน modules/vpc/

ไฟล์: modules/vpc/main.tf

# modules/vpc/main.tf
resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr_block
  instance_tenancy     = "default"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = merge(
    { Name = var.vpc_name },
    var.tags
  )
}

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

resource "aws_subnet" "public" {
  count             = length(var.public_subnet_cidrs)
  vpc_id            = aws_vpc.this.id
  cidr_block        = var.public_subnet_cidrs[count.index]
  availability_zone = "${var.aws_region}${element(["a", "b", "c"], count.index)}" # Adjust AZs as needed
  map_public_ip_on_launch = true
  tags = merge(
    { Name = "${var.vpc_name}-public-subnet-${element(["a", "b", "c"], count.index)}" },
    var.tags
  )
}

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(
    { Name = "${var.vpc_name}-public-rt" },
    var.tags
  )
}

resource "aws_route_table_association" "public" {
  count          = length(aws_subnet.public)
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

ไฟล์: modules/vpc/variables.tf

# modules/vpc/variables.tf
variable "vpc_name" {
  description = "Name for the VPC."
  type        = string
}

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

variable "public_subnet_cidrs" {
  description = "List of CIDR blocks for public subnets."
  type        = list(string)
}

variable "aws_region" {
  description = "The AWS region where resources will be deployed."
  type        = string
}

variable "tags" {
  description = "A map of tags to add 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 = "List of IDs of the public subnets."
  value       = aws_subnet.public.*.id
}

2. เรียกใช้ Module ใน Root Module (main.tf ของโปรเจกต์หลัก)

# main.tf (ในโฟลเดอร์โปรเจกต์หลัก)
provider "aws" {
  region = "ap-southeast-1"
  profile = "my-terraform-user"
}

module "my_new_vpc" {
  source              = "./modules/vpc" # อ้างอิงโฟลเดอร์ของ Module
  vpc_name            = "MyWebAppVPC"
  vpc_cidr_block      = "10.10.0.0/16"
  public_subnet_cidrs = ["10.10.1.0/24", "10.10.2.0/24"]
  aws_region          = "ap-southeast-1"
  tags = {
    Project = "SiamLancardWebApp"
  }
}

# ตอนนี้คุณสามารถใช้ Output จาก module.my_new_vpc เพื่อสร้าง Resource อื่นๆ ได้
resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890" # Replace with actual AMI ID
  instance_type = "t2.micro"
  subnet_id     = module.my_new_vpc.public_subnet_ids[0] # ใช้ Subnet จาก VPC Module
  tags = {
    Name = "WebInstance"
  }
}

ด้วยวิธีนี้ คุณสามารถสร้าง VPC ที่ซับซ้อนขึ้นได้ง่ายๆ โดยการเรียกใช้ Module และกำหนดค่าตัวแปรไม่กี่ตัวครับ

8. การจัดการตัวแปร (Variables) และ Sensitive Data

การจัดการตัวแปรอย่างมีประสิทธิภาพเป็นสิ่งสำคัญในการสร้างโค้ด IaC ที่ยืดหยุ่นและนำกลับมาใช้ซ้ำได้ ส่วนการจัดการข้อมูลที่ละเอียดอ่อน (Sensitive Data) เช่น รหัสผ่าน หรือ API Keys ก็เป็นเรื่องของความปลอดภัยที่ต้องให้ความสำคัญสูงสุดครับ

ประเภทของ Variables

Terraform รองรับ Variable Types พื้นฐานต่างๆ:

  • string: ข้อความ
  • number: ตัวเลข
  • bool: ค่า True/False
  • list(TYPE): รายการของค่า Type ที่กำหนด (เช่น list(string))
  • map(TYPE): คีย์-ค่า คู่กันของ Type ที่กำหนด (เช่น map(string))
  • object(...): โครงสร้างข้อมูลที่ซับซ้อนขึ้น
  • any: ประเภทใดก็ได้ (ใช้เมื่อไม่แน่ใจ)

การกำหนดค่า Variable

คุณสามารถกำหนดค่าให้กับ Variable ได้หลายวิธี โดยมีลำดับความสำคัญ (Precedence) ที่แตกต่างกันครับ:

  1. Command Line Flags: ใช้ -var="key=value" เมื่อรัน terraform plan หรือ terraform apply 
    terraform apply -var="instance_type=t3.micro"
  2. Variable Definition Files (.tfvars): สร้างไฟล์ terraform.tfvars หรือ *.auto.tfvars ในไดเรกทอรีโปรเจกต์ Terraform จะโหลดไฟล์เหล่านี้โดยอัตโนมัติครับ

    ตัวอย่าง terraform.tfvars:

    instance_type = "t3.micro"
aws_region    = "ap-southeast-1"
  3. Environment Variables: ใช้ตัวแปรสภาพแวดล้อมที่ขึ้นต้นด้วย TF_VAR_ (เช่น TF_VAR_instance_type=t3.medium)
  4. Default Values: ค่า default ที่กำหนดไว้ใน variable block (ถ้าไม่มีการระบุค่าจากแหล่งอื่น)
  5. Prompting: ถ้าไม่มีค่าใดๆ ถูกกำหนด Terraform จะถามให้ผู้ใช้ป้อนค่าเมื่อรัน terraform plan หรือ terraform apply

การจัดการ Sensitive Data

การ Hardcode รหัสผ่าน, API Keys หรือข้อมูลที่ละเอียดอ่อนอื่นๆ ลงในโค้ด Terraform หรือในไฟล์ .tfvars เป็นแนวทางปฏิบัติที่ไม่ปลอดภัยอย่างยิ่งครับ เนื่องจากข้อมูลเหล่านี้จะถูกเก็บใน State File และอาจถูกเปิดเผยได้ง่ายใน Version Control System ครับ

แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการ Sensitive Data บน AWS คือการใช้บริการที่ออกแบบมาเพื่อการนี้โดยเฉพาะ:

  1. AWS Secrets Manager:

    บริการที่ช่วยให้คุณสามารถจัดเก็บและเรียกใช้ข้อมูลลับได้อย่างปลอดภัยครับ คุณสามารถเก็บรหัสผ่าน, API Keys, Database Credentials และอื่นๆ ได้ Terraform สามารถดึงข้อมูลจาก Secrets Manager มาใช้ในโค้ดได้โดยใช้ Data Source aws_secretsmanager_secret_version

    data "aws_secretsmanager_secret_version" "db_credentials" {
  secret_id = "my/database/credentials"
}

resource "aws_db_instance" "my_db" {
  # ...
  password = jsondecode(data.aws_secretsmanager_secret_version.db_credentials.secret_string).password
}
  2. AWS Systems Manager Parameter Store (SSM Parameter Store):

    เป็นอีกหนึ่งบริการที่ใช้จัดเก็บ Configuration Data และข้อมูลลับ คุณสามารถจัดเก็บพารามิเตอร์ได้หลายประเภท รวมถึง SecureString ที่เข้ารหัสข้อมูลครับ Terraform สามารถดึงค่าจาก SSM Parameter Store ได้โดยใช้ Data Source aws_ssm_parameter

    data "aws_ssm_parameter" "api_key" {
  name             = "/my-app/prod/api-key"
  with_decryption = true # จำเป็นสำหรับ SecureString
}

resource "aws_lambda_function" "my_lambda" {
  # ...
  environment {
    variables = {
      API_KEY = data.aws_ssm_parameter.api_key.value
    }
  }
}

โดยสรุปคือ อย่าเก็บข้อมูลลับไว้ในไฟล์โค้ด Terraform หรือ State File โดยตรงครับ ใช้บริการเฉพาะทางอย่าง Secrets Manager หรือ Parameter Store ที่ AWS จัดเตรียมไว้ให้ เพื่อความปลอดภัยสูงสุดครับ

9. เปรียบเทียบ Terraform vs. AWS CloudFormation: เลือกอะไรดี?

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

ตารางเปรียบเทียบ: Terraform vs. AWS CloudFormation

คุณสมบัติ Terraform (HashiCorp) AWS CloudFormation (Amazon Web Services)
Cloud Support Multi-Cloud: รองรับ Cloud Providers หลากหลาย (AWS, Azure, GCP, VMware, On-Premises) และบริการอื่นๆ อีกมากมายผ่าน Providers AWS-Specific: รองรับเฉพาะ AWS Services เท่านั้น
ภาษาที่ใช้ (IaC Language) HashiCorp Configuration Language (HCL): ภาษาเชิงประกาศ (Declarative) ที่ออกแบบมาให้อ่านง่ายและเข้าใจได้ไม่ยาก รองรับ JSON ด้วย YAML/JSON: ใช้ YAML หรือ JSON ในการเขียน Template
การจัดการ State File State File (.tfstate): Terraform จะสร้างและจัดการ State File เพื่อบันทึกสถานะของ Resource ที่สร้างขึ้น รองรับ Local และ Remote State (เช่น S3 + DynamoDB สำหรับ AWS) พร้อม State Locking Stack Status: CloudFormation จะจัดการสถานะของ Stack โดยตรงภายใน AWS Service เอง ไม่จำเป็นต้องจัดการ State File ด้วยตัวเอง
ความสามารถในการนำกลับมาใช้ซ้ำ (Reusability) Modules: มีแนวคิด Modules ที่แข็งแกร่งและยืดหยุ่นสูง ช่วยให้สร้างบล็อกโค้ดที่นำกลับมาใช้ซ้ำได้ง่าย ทั้งภายในโปรเจกต์และจาก Terraform Registry Nested Stacks / Macros: รองรับ Nested Stacks สำหรับการจัดระเบียบและนำกลับมาใช้ซ้ำ และ Macros สำหรับการขยาย Template
การเปลี่ยนแปลงนอกแผน (Drift Detection) สามารถตรวจจับ Drift ได้ด้วยคำสั่ง terraform plan (เทียบ State กับ Actual Infrastructure) และ terraform refresh (อัปเดต State จาก Actual Infrastructure) มีฟังก์ชัน Drift Detection ในตัวที่สามารถระบุ Resource ที่ถูกเปลี่ยนแปลงนอก CloudFormation ได้
การจัดการ Resource ที่มีอยู่แล้ว มีคำสั่ง terraform import เพื่อนำ Resource ที่มีอยู่แล้วบน Cloud เข้ามาอยู่ภายใต้การจัดการของ Terraform ได้ มีฟังก์ชัน “Import existing resources” เพื่อนำ Resource ที่มีอยู่แล้วเข้ามาใน Stack ได้
Ecosystem & Community ชุมชนขนาดใหญ่และ Active มี Provider และ Modules จำนวนมากใน Terraform Registry เครื่องมือเสริมและ Third-party Integrations เยอะ ชุมชนขนาดใหญ่ภายใน AWS มี AWS Solutions, Quick Starts และบริการอื่นๆ ที่ผสานรวมกับ CloudFormation ได้อย่างลงตัว
Learning Curve HCL เรียนรู้ได้ค่อนข้างเร็ว แต่การทำความเข้าใจ Core Concepts (State, Providers, Modules) อาจต้องใช้เวลา YAML/JSON คุ้นเคยสำหรับนักพัฒนา แต่การทำความเข้าใจ Syntax เฉพาะของ CloudFormation (Intrinsic Functions, Pseudo Parameters) อาจต้องใช้เวลา
Pricing Terraform CLI เป็น Open Source และฟรี แต่ HashiCorp Terraform Cloud มีเวอร์ชันฟรีและเสียเงินสำหรับคุณสมบัติขั้นสูง (เช่น Remote Operations, Collaboration) ฟรีสำหรับการใช้งาน CloudFormation Services แต่คุณต้องจ่ายค่า Resource ที่ถูกสร้างขึ้น
Rollback Functionality ไม่มีย้อนกลับอัตโนมัติ (Automatic Rollback) หาก apply ล้มเหลว ต้องแก้ไขโค้ดและ apply ใหม่ หรือใช้ terraform destroy มี Automatic Rollback หาก Stack Creation/Update ล้มเหลว สามารถย้อนกลับไปยังสถานะก่อนหน้าได้

สรุป: เลือกอะไรดี?

  • เลือก Terraform หาก:
    • คุณวางแผนที่จะใช้งานโครงสร้างพื้นฐานข้าม Cloud Providers (Multi-Cloud Strategy)
    • คุณต้องการความยืดหยุ่นและควบคุมการจัดการ State File ได้เอง
    • คุณต้องการประโยชน์จาก Ecosystem และ Community ที่กว้างขวาง
    • คุณคุ้นเคยกับภาษา Declarative ที่อ่านง่ายอย่าง HCL
  • เลือก CloudFormation หาก:
    • คุณใช้งาน AWS เพียงอย่างเดียวและไม่มีแผนจะขยายไปยัง Cloud อื่นๆ
    • คุณต้องการการผสานรวมอย่างลึกซึ้งกับ AWS Services และคุณสมบัติเฉพาะของ AWS (เช่น Automatic Rollback)
    • คุณต้องการให้ AWS จัดการ State และ Lifecycle ของ Infrastructure ให้ทั้งหมด
    • ทีมของคุณคุ้นเคยกับ YAML/JSON และ AWS Ecosystem อยู่แล้ว

ในความเป็นจริง หลายองค์กรเลือกที่จะใช้ทั้งสองเครื่องมือร่วมกันครับ โดยใช้ CloudFormation สำหรับ Infrastructure พื้นฐานที่ AWS มีความเชี่ยวชาญ และใช้ Terraform สำหรับส่วนที่ต้องการความยืดหยุ่น Multi-Cloud หรือการจัดการ Services ที่อยู่นอก AWS ครับ

10. แนวปฏิบัติที่ดีที่สุด (Best Practices) ในการใช้ Terraform กับ AWS

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

  1. จัดระเบียบโครงสร้างโปรเจกต์ (Folder Structure) อย่างเหมาะสม:

    แยกโค้ดตามสภาพแวดล้อม (Dev, Staging, Prod) หรือตาม Service/Application ครับ

    my-project/
  environments/
    dev/
      main.tf
      variables.tf
      terraform.tfvars
    prod/
      main.tf
      variables.tf
      terraform.tfvars
  modules/
    vpc/
      main.tf
      variables.tf
      outputs.tf
    ec2-app/
      main.tf
      variables.tf
      outputs.tf
  # ...
  2. ใช้ Remote State เสมอ:

    สำหรับโปรเจกต์ที่ทำงานเป็นทีม ควรใช้ S3 Bucket + DynamoDB สำหรับ State Locking เพื่อป้องกันการเขียนทับและทำให้ State File ปลอดภัยครับ

  3. ล็อกเวอร์ชันของ Provider และ Module:

    ระบุเวอร์ชันของ Terraform, Provider และ Module ในโค้ดของคุณ (เช่น version = "~> 5.0" หรือ version = "1.0.0") เพื่อป้องกันการเปลี่ยนแปลงที่ไม่คาดคิดจากการอัปเดตเวอร์ชันที่ไม่เข้ากันครับ

  4. จัดการ Sensitive Data อย่างถูกวิธี:

    อย่าเก็บรหัสผ่านหรือ API Keys ในโค้ด Terraform หรือ State File ครับ ใช้ AWS Secrets Manager หรือ SSM Parameter Store (SecureString) ในการจัดเก็บและดึงข้อมูลลับครับ

  5. ใช้ Terraform Workspaces (อย่างระมัดระวัง) หรือหลาย AWS Accounts:

    Workspaces (terraform workspace new dev) เป็นวิธีหนึ่งในการจัดการหลายสภาพแวดล้อม (Dev, Staging, Prod) ด้วยโค้ดชุดเดียวกัน แต่สามารถทำให้เกิดความสับสนได้ง่ายในโปรเจกต์ที่ซับซ้อนครับ หลายองค์กรเลือกที่จะใช้ AWS Accounts แยกกันสำหรับแต่ละสภาพแวดล้อมเพื่อการแยกส่วน (isolation) ที่ดีกว่า และใช้ Terraform เพื่อ Deploy ในแต่ละ Account ครับ

  6. รีวิวโค้ด (Code Review):

    เช่นเดียวกับการพัฒนาซอฟต์แวร์ การรีวิวโค้ด Terraform ช่วยให้มั่นใจได้ว่าโค้ดนั้นถูกต้อง ปลอดภัย และเป็นไปตามแนวทางปฏิบัติที่ดีครับ

  7. ทดสอบ (Testing):

    แม้ว่า Terraform จะ

    บทความที่เกี่ยวข้อง

    Siam2R.com — Portfolio งาน IT · XM Signal — Free Forex EA Download

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