Blue/Green deployment bằng Terraform

terraform fmt
terraform init
terraform validate
terraform plan
terraform apply
terraform plan -destroy
terraform destroy

Blue/green giải quyết điều gì?

blue là phiên bản đang phục vụ traffic; green là phiên bản mới. Thay vì replace trực tiếp một ASG, ta dựng green song song, chạy health check/smoke test, rồi đổi listener hoặc target group. Nếu green lỗi, chuyển traffic về blue.

ALB listener -> target group blue  (đang nhận traffic)
             -> target group green (đang kiểm tra)

Module nên tách base và application

Module base có VPC, ALB, security group và listener. Module application nhận color và tạo launch template/ASG tương ứng:

module "blue" {
  source       = "./modules/app"
  color        = "blue"
  ami_id       = var.blue_ami_id
  target_group = module.base.blue_target_group_arn
}

module "green" {
  source       = "./modules/app"
  color        = "green"
  ami_id       = var.green_ami_id
  target_group = module.base.green_target_group_arn
}

color phải nằm trong tên/identity để Terraform không nhầm hai nhóm. Tránh dùng một biến boolean rồi mutate cùng resource nếu mục tiêu là giữ cả hai phiên bản cùng tồn tại.

Cutover

Một cách chuyển traffic là thay default action của listener:

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.app.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    forward {
      target_group { arn = var.active_target_group_arn }
    }
  }
}

Thực tế có thể dùng weighted target groups để chuyển dần 1% -> 10% -> 100%, hoặc dùng một hệ thống release riêng điều khiển cutover. Terraform là công cụ quản lý desired state; đừng nhét toàn bộ health-check loop phức tạp vào terraform apply.

Checklist rollback

• Green có endpoint kiểm tra riêng.
• Health check kiểm tra dependency thật, không chỉ trả HTTP 200 giả.
• DB migration tương thích với cả blue và green.
• Có người chịu trách nhiệm quyết định cutover.
• Blue chưa bị destroy ngay sau apply green.
• Có metric và log để xác định rollback.

Runbook cutover 10 phút

1. Apply green với image/version mới, chưa đổi listener.
2. Gọi health endpoint và smoke test qua target group green.
3. Kiểm tra error rate, latency, log và dependency như database/queue.
4. Chuyển 1% hoặc 10% traffic nếu hệ thống hỗ trợ weighted forward.
5. Theo dõi trong một khoảng thời gian đã thống nhất rồi mới lên 100%.
6. Giữ blue đủ lâu cho rollback; chỉ destroy khi release đã ổn định.

Nếu dùng Terraform để đổi active_color, hãy để thay đổi đó nhỏ và dễ rollback. Đừng cùng một apply vừa đổi AMI, schema database, listener và xóa blue; blast radius quá lớn và khó xác định nguyên nhân khi lỗi.

Expected state và cutover gate

Dùng sandbox có tag Training = terraform-11. Expected state trước cutover là blue nhận 100% traffic, green tồn tại nhưng chưa active, target health/metrics được ghi baseline và database schema tương thích. Sau cutover, listener/weighted action trỏ đúng green theo change đã review, smoke test/metric pass, blue vẫn rollback được và Terraform plan không lẫn destroy application/data.

Thực hiện các drill:

1. Làm green health check fail vì port/dependency/config, xác nhận listener vẫn ở blue và plan/apply không tự chuyển traffic khi gate fail.
2. Chuyển canary 1/10%, đo error rate/latency/logs/connection drain, rồi mô phỏng rollback listener về blue; giữ evidence timestamp/actor/active color.
3. Tạo DB migration không backward-compatible trong sandbox, nhận diện blue/green incompatibility và dừng trước cutover; không dùng Terraform apply để ép schema/data migration.
4. Thử destroy green/blue trong plan, kiểm tra target group/ASG/connection/data dependencies và retention window; không xóa blue ngay sau cutover hoặc dùng -auto-approve.

Quality gate

Pass khi blue/green resource identity và ownership tách rõ, green có health/smoke/metric evidence, cutover là change nhỏ có approval, rollback listener/traffic có runbook và thời gian, database compatibility được kiểm tra, blue retention/cost được quản lý và destroy chỉ sau stability gate. Terraform quản lý desired infrastructure; release controller/observability có thể cần điều khiển progressive traffic.