CI/CD với HCP Terraform và triển khai ít downtime

Luồng CI/CD tối thiểu

Một pull request sửa hạ tầng nên có luồng:

PR -> fmt/validate -> speculative plan -> review -> merge -> apply có approval

Kết nối workspace với GitHub/GitLab giúp mỗi commit tạo plan tự động. Với production, chỉ merge chưa đủ để tự do apply nếu tổ chức cần approval hoặc change window.

Tách plan và apply

terraform fmt -check
terraform init -backend=false
terraform validate
terraform plan -out=tfplan

CI cần kiểm tra exit code và đưa plan vào comment/console có quyền xem. Không log secret hoặc upload plan vào nơi công khai. Bước apply nên dùng commit đã merge, không dùng source code local của người review.

`create_before_destroy` có phải zero-downtime?

resource "aws_launch_template" "app" {
  name_prefix = "app-"
  image_id    = var.ami_id
  lifecycle {
    create_before_destroy = true
  }
}

Lifecycle này yêu cầu Terraform tạo object mới trước khi hủy object cũ khi provider/resource cho phép. Nó hữu ích khi đổi launch template hoặc resource có tên generated. Nhưng nó không đảm bảo request không rớt: load balancer có thể chưa health check xong, database migration có thể breaking, quota có thể hết, hoặc IP/tên duy nhất không cho phép tồn tại song song.

Thiết kế deployment an toàn hơn

Dùng ALB target group và health check trước khi deregister instance cũ.
Giữ backward compatibility cho schema và API.
Tách infrastructure change khỏi application rollout nếu cần.
Có rollback: quay lại image/config cũ, không chỉ “terraform apply commit trước”.
Đo error rate, latency và connection drain trong lúc chuyển.

Khi xóa resource

CI không nên có quyền xóa production chỉ vì một resource bị bỏ khỏi code. Có thể yêu cầu approval riêng cho destroy, dùng policy kiểm tra plan, hoặc đặt prevent_destroy cho database quan trọng.

Một pipeline production nên chặn điều gì?

Plan có destroy hoặc replace database phải dừng để review riêng.
Thay đổi IAM, network route hoặc security group cần owner của hệ thống xác nhận.
Apply phải gắn với commit đã merge, không lấy branch đang bị force-push.
Credential cloud dùng role ngắn hạn và chỉ tồn tại trong thời gian run.
Sau apply phải có smoke test và đường rollback rõ ràng.

create_before_destroy chỉ điều khiển thứ tự một số resource. Zero-downtime là thuộc tính của cả hệ thống: capacity, health check, connection draining, migration và backward compatibility đều phải được kiểm thử.

Đọc bài nguồn CI/CD và zero-downtime để xem flow kết nối VCS chi tiết hơn.