Terraform Module Zero Downtime Deployment — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

บทนำ: ความท้าทายของการปรับใช้ Infrastructure แบบ Zero Downtime

ในยุคที่ระบบคลาวด์และโครงสร้างพื้นฐานแบบ Infrastructure as Code (IaC) กลายเป็นมาตรฐาน การปรับใช้การเปลี่ยนแปลงโดยไม่ทำให้บริการหยุดชะงัก (Zero Downtime Deployment) กลายเป็นความจำเป็นที่ไม่อาจมองข้าม โดยเฉพาะอย่างยิ่งเมื่อเราทำงานกับ Terraform Modules ซึ่งเป็นหน่วยการทำงานที่ถูกออกแบบมาให้สามารถนำกลับมาใช้ซ้ำได้ (Reusable Components)

บทความนี้จะพาคุณดำดิ่งสู่โลกของ Terraform Module Zero Downtime Deployment อย่างละเอียด ครอบคลุมตั้งแต่แนวคิดพื้นฐาน กลยุทธ์การปรับใช้ ไปจนถึงแนวทางปฏิบัติที่ดีที่สุดในปี 2026 เราจะใช้ภาษาไทยที่เข้าใจง่าย พร้อมตัวอย่างโค้ดและตารางเปรียบเทียบที่ใช้งานได้จริง

การทำ Zero Downtime Deployment กับ Terraform Modules ไม่ใช่แค่การเขียนโค้ดให้ถูกต้อง แต่คือการออกแบบสถาปัตยกรรมที่ยืดหยุ่น ทนทาน และสามารถกู้คืนได้อย่างรวดเร็ว บทความนี้เหมาะสำหรับ DevOps Engineers, Cloud Architects, และทุกคนที่ต้องการยกระดับทักษะ IaC ของตนเอง

1. ทำความเข้าใจ Terraform Module และความท้าทายในการปรับใช้

1.1 Terraform Module คืออะไร?

Terraform Module คือกลุ่มของ resource definitions ที่ถูกจัดกลุ่มไว้ด้วยกันในไดเรกทอรีเดียว เพื่อให้สามารถนำกลับมาใช้ซ้ำได้ในหลายโปรเจกต์ เปรียบเสมือนฟังก์ชันในภาษาโปรแกรมมิ่งที่รับ input (variables) และส่ง output (outputs) กลับมา

ตัวอย่าง Module พื้นฐานสำหรับสร้าง VPC:

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

  tags = {
    Name        = var.name
    Environment = var.environment
  }
}

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.availability_zones[count.index]

  map_public_ip_on_launch = true

  tags = {
    Name = "${var.name}-public-${count.index}"
  }
}

variable "cidr_block" {
  type = string
}

variable "name" {
  type = string
}

variable "environment" {
  type = string
}

variable "public_subnet_cidrs" {
  type = list(string)
}

variable "availability_zones" {
  type = list(string)
}

output "vpc_id" {
  value = aws_vpc.this.id
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

1.2 ความท้าทายเฉพาะของ Zero Downtime สำหรับ Modules

เมื่อเราปรับใช้ Terraform Module ในสภาพแวดล้อมจริง โดยเฉพาะอย่างยิ่งกับทรัพยากรที่สำคัญ เช่น ฐานข้อมูล (RDS, Aurora) หรือ Load Balancer ความท้าทายหลักๆ ได้แก่:

• State Locking: เมื่อทีมหลายคนทำงานพร้อมกัน การจัดการ State File ให้สอดคล้องกันเป็นสิ่งสำคัญ
• Resource Dependencies: Module มักมี dependencies ที่ซับซ้อน การเปลี่ยนแปลงทรัพยากรหนึ่งอาจส่งผลกระทบต่อทรัพยากรอื่น
• Immutable Infrastructure: บางทรัพยากรเช่น AWS Launch Template ไม่สามารถแก้ไขได้ ต้องสร้างใหม่แทน
• Rollback Complexity: เมื่อการปรับใช้ล้มเหลว การย้อนกลับไปยังสถานะก่อนหน้าอาจทำได้ยากหากไม่มีการวางแผนที่ดี
• Network Connectivity: การเปลี่ยนแปลง Security Group หรือ Network ACL อาจทำให้บริการขาดการเชื่อมต่อชั่วคราว

2. กลยุทธ์หลักสำหรับ Zero Downtime Deployment ใน Terraform

2.1 Blue-Green Deployment ผ่าน Module Versioning

กลยุทธ์นี้ใช้หลักการของการมีสภาพแวดล้อมสองชุดที่เหมือนกันทุกประการ (Blue และ Green) โดยที่ครั้งหนึ่งจะมีเพียงชุดเดียวที่รับ traffic จริง

การนำไปใช้กับ Terraform Module สามารถทำได้โดยการกำหนด module version และใช้ Terraform Workspace หรือ Terragrunt ในการจัดการ:

# environments/production/terragrunt.hcl
terraform {
  source = "git::https://github.com/your-org/terraform-modules.git//vpc?ref=v1.2.0"
}

inputs = {
  name        = "production-vpc"
  environment = "production"
  cidr_block  = "10.0.0.0/16"
  public_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"]
  availability_zones  = ["ap-southeast-1a", "ap-southeast-1b"]
}

# สำหรับ Blue-Green Deployment เราจะมีสองชุด
# environments/production-blue/terragrunt.hcl (active)
# environments/production-green/terragrunt.hcl (standby)

ข้อดี: การสลับ traffic ทำได้ทันทีโดยการเปลี่ยน DNS หรือ Load Balancer Target Group

ข้อเสีย: ใช้ทรัพยากรมากเป็นสองเท่าในระหว่างการปรับใช้

2.2 Canary Deployment กับ Module Count

Canary Deployment คือการค่อยๆ เปลี่ยน traffic ไปยังเวอร์ชันใหม่ทีละน้อย โดยเริ่มจากเปอร์เซ็นต์เล็กๆ ก่อน

ใน Terraform เราสามารถใช้ count หรือ for_each ร่วมกับ module เพื่อควบคุมจำนวนทรัพยากรที่ถูกสร้าง:

# main.tf
module "web_app" {
  source = "./modules/web-app"

  instance_count = var.canary_percentage == 0 ? 0 : floor(var.total_instances * (var.canary_percentage / 100))
  instance_type  = var.new_instance_type
  ami_id         = var.new_ami_id
  subnet_ids     = var.subnet_ids
}

# variables.tf
variable "canary_percentage" {
  description = "Percentage of traffic to route to new version"
  type        = number
  default     = 0
}

variable "total_instances" {
  description = "Total number of instances in the auto scaling group"
  type        = number
  default     = 10
}

variable "new_instance_type" {
  type = string
}

variable "new_ami_id" {
  type = string
}

variable "subnet_ids" {
  type = list(string)
}

2.3 Rolling Update กับ Lifecycle Meta-Argument

Rolling Update เป็นกลยุทธ์ที่ค่อยๆ อัปเดตทรัพยากรทีละตัว โดยใช้ create_before_destroy lifecycle rule เพื่อให้แน่ใจว่าทรัพยากรใหม่ถูกสร้างก่อนลบทรัพยากรเก่า

# modules/web-app/main.tf
resource "aws_launch_template" "this" {
  name_prefix   = "${var.name}-"
  image_id      = var.ami_id
  instance_type = var.instance_type

  lifecycle {
    create_before_destroy = true
  }

  # ใช้ name-based versioning เพื่อหลีกเลี่ยง conflict
  user_data = base64encode(templatefile("${path.module}/user_data.sh", {
    app_version = var.app_version
  }))

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = var.name
      Version = var.app_version
    }
  }
}

resource "aws_autoscaling_group" "this" {
  name                = "${var.name}-${var.app_version}"
  vpc_zone_identifier = var.subnet_ids
  min_size            = var.min_size
  max_size            = var.max_size
  desired_capacity    = var.desired_capacity

  launch_template {
    id      = aws_launch_template.this.id
    version = "$Latest"
  }

  lifecycle {
    create_before_destroy = true
  }

  tag {
    key                 = "Name"
    value               = var.name
    propagate_at_launch = true
  }
}

3. การจัดการ State และ Dependency อย่างปลอดภัย

3.1 Remote State Backend และ State Locking

การใช้ Remote State Backend (เช่น AWS S3 + DynamoDB) เป็นสิ่งจำเป็นสำหรับการทำงานเป็นทีมและการทำ Zero Downtime

3.2 การจัดการ Module Dependencies

เมื่อ Module มี dependencies ต่อกัน (เช่น Module A ต้องสร้างก่อน Module B) การใช้ depends_on และ data sources อย่างถูกต้องเป็นสิ่งสำคัญ

# main.tf - การจัดการ dependencies ระหว่าง modules
module "networking" {
  source = "./modules/networking"
  
  environment = var.environment
  vpc_cidr    = "10.0.0.0/16"
}

module "database" {
  source = "./modules/database"
  
  # ใช้ output จาก networking module
  vpc_id             = module.networking.vpc_id
  subnet_ids         = module.networking.private_subnet_ids
  database_name      = "myapp_${var.environment}"
  master_username    = var.db_username
  master_password    = var.db_password
  
  # ระบุ dependency อย่างชัดเจน (ถึงแม้ Terraform จะ infer ได้)
  depends_on = [module.networking]
}

module "application" {
  source = "./modules/application"
  
  vpc_id          = module.networking.vpc_id
  subnet_ids      = module.networking.public_subnet_ids
  database_url    = module.database.endpoint
  instance_count  = var.app_instance_count
  
  depends_on = [module.networking, module.database]
}

3.3 Data Source สำหรับการอ้างอิงทรัพยากรที่มีอยู่แล้ว

การใช้ data source ช่วยให้ Module สามารถอ้างอิงทรัพยากรที่มีอยู่แล้วโดยไม่ต้องสร้างใหม่ ซึ่งช่วยลดความเสี่ยงในการหยุดชะงัก

# modules/security/main.tf
data "aws_security_group" "existing" {
  filter {
    name   = "group-name"
    values = ["${var.environment}-web-sg"]
  }
  
  # ถ้าไม่พบ จะใช้ resource ที่สร้างใหม่
  count = var.use_existing_sg ? 1 : 0
}

resource "aws_security_group" "new" {
  count = var.use_existing_sg ? 0 : 1
  
  name        = "${var.environment}-web-sg"
  description = "Security group for web servers"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  lifecycle {
    create_before_destroy = true
  }
}

locals {
  security_group_id = var.use_existing_sg ? data.aws_security_group.existing[0].id : aws_security_group.new[0].id
}

output "security_group_id" {
  value = local.security_group_id
}

4. การทดสอบและตรวจสอบความพร้อมก่อนปรับใช้จริง

4.1 การใช้ Terraform Plan อย่างชาญฉลาด

terraform plan เป็นเครื่องมือที่มีประสิทธิภาพในการตรวจสอบการเปลี่ยนแปลงก่อนนำไปใช้จริง แต่สำหรับ Zero Downtime เราควรทำมากกว่านั้น:

• Plan with Detailed Exit Code: ใช้ -detailed-exitcode เพื่อแยกแยะระหว่าง “no changes” (0), “error” (1), และ “changes” (2)
• Plan Output Analysis: ใช้ terraform show -json plan.out เพื่อวิเคราะห์การเปลี่ยนแปลงในรูปแบบ JSON
• Automated Policy Checks: ใช้ Sentinel (Terraform Cloud) หรือ Open Policy Agent (OPA) เพื่อตรวจสอบว่าการเปลี่ยนแปลงไม่ละเมิดนโยบาย

4.2 Integration Testing ด้วย Terratest หรือ Kitchen-Terraform

การทดสอบแบบ Integration ช่วยให้มั่นใจว่า Module ทำงานได้ถูกต้องในสภาพแวดล้อมที่จำลองขึ้น:

// test/vpc_test.go (ใช้ Terratest)
package test

import (
  "testing"
  "github.com/gruntwork-io/terratest/modules/terraform"
  "github.com/stretchr/testify/assert"
)

func TestVPCCreation(t *testing.T) {
  t.Parallel()

  terraformOptions := &terraform.Options{
    // Path to the Terraform code
    TerraformDir: "../examples/vpc-example",

    // Variables to pass to the module
    Vars: map[string]interface{}{
      "name":        "test-vpc",
      "environment": "test",
      "cidr_block":  "10.0.0.0/16",
      "public_subnet_cidrs": []string{"10.0.1.0/24", "10.0.2.0/24"},
      "availability_zones":  []string{"ap-southeast-1a", "ap-southeast-1b"},
    },
  }

  // Clean up resources at the end of the test
  defer terraform.Destroy(t, terraformOptions)

  // Apply the Terraform code
  terraform.InitAndApply(t, terraformOptions)

  // Get the output values
  vpcID := terraform.Output(t, terraformOptions, "vpc_id")
  subnetIDs := terraform.OutputList(t, terraformOptions, "public_subnet_ids")

  // Assert that the VPC was created
  assert.NotEmpty(t, vpcID)
  assert.Equal(t, 2, len(subnetIDs))
}

4.3 การจำลองสถานการณ์ (Chaos Engineering)

การทดสอบความทนทานของระบบด้วยการจำลองความล้มเหลว เช่น การปิด instance ทันที หรือการตัด network connectivity จะช่วยให้มั่นใจว่า Zero Downtime strategy ใช้ได้จริง

5. Best Practices สำหรับ Zero Downtime Module Deployment

5.1 การออกแบบ Module ให้รองรับการเปลี่ยนแปลง

• ใช้ Semantic Versioning: กำหนดเวอร์ชันของ Module อย่างชัดเจน (major.minor.patch)
• หลีกเลี่ยง Hard-coded Values: ใช้ variables สำหรับทุกค่าที่อาจเปลี่ยนแปลง
• ใช้ Default Values ที่ปลอดภัย: กำหนด default values ที่ไม่ทำให้ระบบล่มเมื่อผู้ใช้ลืมระบุ
• ออกแบบให้มี Multiple Instances: ใช้ count หรือ for_each เพื่อให้สามารถปรับขนาดได้

5.2 การจัดการ Secrets และ Credentials

การรั่วไหลของ secrets อาจทำให้ต้อง rebuild ทั้งระบบ ซึ่งนำไปสู่ downtime:

• ใช้ AWS Secrets Manager, HashiCorp Vault, หรือ Azure Key Vault ในการจัดเก็บ secrets
• หลีกเลี่ยงการเก็บ secrets ใน Terraform state file โดยใช้ sensitive = true ใน output
• ใช้ dynamic credentials เช่น AWS STS เพื่อลดความเสี่ยง

5.3 การทำ Rollback อย่างมีประสิทธิภาพ

5.4 การใช้ Pre-commit Hooks และ CI/CD Pipeline

การตรวจสอบโค้ดก่อน commit ช่วยลดข้อผิดพลาด:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.83.0
    hooks:
      - id: terraform_fmt
      - id: terraform_docs
      - id: terraform_tflint
        args:
          - --args=--config=__GIT_WORKING_DIR__/.tflint.hcl
      - id: terraform_tfsec
      - id: terraform_validate
      - id: terraform_checkov
        args:
          - --args=--config-file=__GIT_WORKING_DIR__/.checkov.yml

6. กรณีศึกษา (Real-World Use Cases)

6.1 กรณีศึกษา: การปรับใช้ Database Module แบบ Zero Downtime

ปัญหา: บริษัท E-commerce แห่งหนึ่งต้องการอัปเกรด Amazon RDS instance type จาก db.r5.large เป็น db.r6g.large โดยไม่ให้บริการหยุดชะงักในช่วง Black Friday

แนวทางแก้ไข:

1. สร้าง Multi-AZ Deployment: ใช้ RDS Multi-AZ เพื่อให้มีการ failover โดยอัตโนมัติ
2. ใช้ Blue-Green Deployment:
   • สร้าง RDS instance ใหม่ใน module version 2.0.0
   • ใช้ AWS DMS (Database Migration Service) เพื่อ sync ข้อมูล
   • เปลี่ยน DNS CNAME ชี้ไปยัง instance ใหม่
3. Monitor และ Rollback: ใช้ CloudWatch alarms เพื่อตรวจจับความผิดปกติ ถ้าพบ ให้เปลี่ยน DNS กลับ

ผลลัพธ์: การเปลี่ยน instance type เสร็จสมบูรณ์ภายใน 45 นาที โดยไม่มี downtime ที่ตรวจพบได้

6.2 กรณีศึกษา: การอัปเดต Kubernetes Module

ปัญหา: ทีม DevOps ต้องการอัปเกรด EKS cluster version จาก 1.27 เป็น 1.28 โดยใช้ Terraform module ที่มีการจัดการ node group

แนวทางแก้ไข:

1. ใช้ Node Group Versioning: สร้าง node group ใหม่พร้อม Kubernetes version 1.28
2. ใช้ Pod Disruption Budgets (PDB): กำหนด PDB ให้ pods ทำงานได้ตลอดระหว่างการเปลี่ยน node
3. Cordon and Drain: ใช้ local-exec provisioner ในการ cordon และ drain node เก่า

# modules/eks-cluster/main.tf
resource "aws_eks_node_group" "new" {
  cluster_name    = aws_eks_cluster.this.name
  node_group_name = "${var.cluster_name}-v2"
  node_role_arn   = aws_iam_role.node.arn
  subnet_ids      = var.subnet_ids

  scaling_config {
    desired_size = var.desired_size
    max_size     = var.max_size
    min_size     = var.min_size
  }

  ami_type       = "AL2_x86_64"
  instance_types = [var.instance_type]
  disk_size      = var.disk_size

  # ใช้ Kubernetes version ใหม่
  version = var.new_kubernetes_version

  # ใช้ launch template เพื่อกำหนด taints และ labels
  launch_template {
    id      = aws_launch_template.new.id
    version = "$Latest"
  }

  lifecycle {
    create_before_destroy = true
  }
}

# ใช้ null_resource เพื่อ drain node เก่า
resource "null_resource" "drain_old_nodes" {
  depends_on = [aws_eks_node_group.new]

  provisioner "local-exec" {
    command = <

# environments/production/terragrunt.hcl
dependency "networking" {
  config_path = "../networking"

  mock_outputs = {
    vpc_id             = "vpc-mock"
    private_subnet_ids = ["subnet-mock-1", "subnet-mock-2"]
  }
}

dependency "database" {
  config_path = "../database"

  mock_outputs = {
    endpoint = "db-mock.example.com:5432"
  }
}

inputs = {
  vpc_id      = dependency.networking.outputs.vpc_id
  subnet_ids  = dependency.networking.outputs.private_subnet_ids
  database_url = dependency.database.outputs.endpoint
}

# tests/vpc_test.tftest.hcl
run "setup_vpc" {
  module {
    source = "./examples/vpc-example"
  }

  variables {
    name        = "test-vpc"
    environment = "test"
    cidr_block  = "10.0.0.0/16"
    public_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"]
    availability_zones  = ["ap-southeast-1a", "ap-southeast-1b"]
  }

  # ตรวจสอบว่า VPC ถูกสร้าง
  assert {
    condition     = aws_vpc.this.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR block mismatch"
  }

  # ตรวจสอบจำนวน subnet
  assert {
    condition     = length(aws_subnet.public) == 2
    error_message = "Expected 2 public subnets"
  }
}

run "verify_subnet_tags" {
  module {
    source = "./examples/vpc-example"
  }

  variables {
    name        = "test-vpc"
    environment = "test"
    cidr_block  = "10.0.0.0/16"
    public_subnet_cidrs = ["10.0.1.0/24", "10.0.2.0/24"]
    availability_zones  = ["ap-southeast-1a", "ap-southeast-1b"]
  }

  assert {
    condition     = aws_subnet.public[0].tags["Name"] == "test-vpc-public-0"
    error_message = "Subnet tag name incorrect"
  }
}

# policy/terraform.rego
package terraform

# ตรวจสอบว่ามี encryption สำหรับ RDS instances
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_db_instance"
  not resource.change.after.storage_encrypted
  
  msg := sprintf("RDS instance %v must have storage_encrypted enabled", [resource.address])
}

# ตรวจสอบว่าใช้ instance types ที่ได้รับอนุมัติ
approved_instance_types := {"t3.medium", "t3.large", "m5.large", "m5.xlarge"}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_instance"
  not approved_instance_types[resource.change.after.instance_type]
  
  msg := sprintf("Instance %v uses unapproved instance type: %v", [resource.address, resource.change.after.instance_type])
}

# ตรวจสอบว่า Security Group ไม่เปิดพอร์ต 22/3389 ให้全世界
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_security_group_rule"
  resource.change.after.type == "ingress"
  resource.change.after.cidr_blocks[_] == "0.0.0.0/0"
  resource.change.after.from_port <= 22
  resource.change.after.to_port >= 22
  
  msg := sprintf("Security group rule %v allows SSH access from anywhere", [resource.address])
}