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

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

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ử.

Expected pipeline và failure drills

Expected state của pipeline là: PR chạy fmt/validate và speculative plan không mutate cloud; plan có artifact/access policy rõ; merge tạo run từ commit bất biến; production apply dừng ở approval/policy khi có destroy/replace/IAM/network/database risk; sau apply có smoke test và rollback owner. Mỗi workspace/environment phải có concurrency lock để không chạy hai apply chồng nhau.

Thực hiện các drill:

1. Đưa PR có syntax/type error, provider init fail và plan có destroy database vào pipeline; xác nhận mỗi lỗi dừng ở đúng gate, không sinh apply.
2. Tạo hai run cùng workspace, kiểm tra lock/concurrency/cancel behavior; không chạy -lock=false hoặc retry apply bằng credential cá nhân.
3. Mô phỏng credential hết hạn, policy deny, quota hết và health check fail; phân loại CI/HCP/IAM/provider/runtime, lưu log không có secret và kích hoạt rollback/hold.
4. So sánh plan artifact với commit SHA đã merge, kiểm tra approval actor, plan hash/run URL và smoke-test result; không apply plan từ branch force-push hoặc artifact public.

Quality gate

Pass khi pipeline tách check/plan/apply, dùng credential ngắn hạn, có concurrency/approval/policy gates, phân loại destroy/replace risk, deploy từ commit bất biến, có health/rollback evidence và cleanup job. Người học phải giải thích được create-before-destroy không đảm bảo zero downtime nếu ALB health, capacity, schema hoặc dependency chưa sẵn sàng.