Terraform Backend là gì và vì sao team cần nó?

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

Vấn đề của local state

Mặc định Terraform lưu state trong terraform.tfstate tại máy chạy lệnh. Cách này ổn cho bài lab cá nhân, nhưng nhanh chóng có vấn đề:

• Hai người có state khác nhau và không biết ai đang sở hữu resource.
• State nằm trên laptop có thể mất hoặc bị lộ.
• Hai pipeline chạy cùng lúc có thể ghi đè state.
• Người review không có một nơi chung để xem lịch sử thay đổi.

Backend quyết định state nằm ở đâu và, tùy loại backend, operation chạy ở đâu.

Ba mô hình phổ biến

Local backend: đơn giản, không cần cấu hình. Dùng cho learning hoặc prototype không có shared infrastructure.

Standard backend: state ở storage chung như S3, GCS, Azure Blob. Terraform CLI vẫn chạy ở máy/runner của bạn.

Remote backend: state và có thể cả plan/apply chạy trên dịch vụ như HCP Terraform. Dịch vụ thường cung cấp locking, variable store, policy và audit.

Ví dụ khai báo HCP Terraform:

terraform {
  cloud {
    organization = "my-org"
    workspaces { name = "app-dev" }
  }
}

Backend không phải backup duy nhất

Một remote backend tốt vẫn cần versioning, mã hóa, phân quyền và retention. State có thể chứa mật khẩu, endpoint nội bộ hoặc token dù output đã đánh dấu sensitive. Coi state như dữ liệu production.

Khi đổi backend, Terraform yêu cầu migrate state:

terraform init -migrate-state

Không chạy migrate khi chưa biết state hiện tại nằm ở đâu. Hãy backup/kiểm tra trước, thông báo team và đảm bảo chỉ một người thực hiện.

Chọn backend theo quy mô

Điểm mấu chốt: backend giải quyết việc chia sẻ và khóa state, không thay thế quy trình review hay quyền IAM.

Cách migrate an toàn

Hãy coi đổi backend là một change riêng, không gộp với việc refactor resource:

1. Dừng pipeline và xác nhận không có apply đang chạy.
2. Sao lưu hoặc xác nhận version state hiện tại.
3. Thêm block backend nhưng chưa đổi resource.
4. Chạy terraform init -migrate-state, đọc đường dẫn nguồn/đích.
5. Chạy terraform plan và đảm bảo không có create/destroy bất ngờ.
6. Cập nhật README, credential và quyền truy cập cho team.

Nếu plan sau migrate đề xuất tạo lại mọi resource, dừng lại. Thường nguyên nhân là sai backend key, sai workspace, sai account/region hoặc provider alias.

Expected state và migration drill

Tạo project lab có resource không nhạy cảm, ghi state owner, backend source/destination, workspace/key, account/region và lock mechanism. Expected state trước migrate là plan no-op với local backend; sau migrate, state chỉ xuất hiện ở backend đích, terraform plan vẫn no-op, lock ngăn hai operation đồng thời và không có resource create/destroy ngoài chủ ý.

Thực hiện drill theo thứ tự:

1. Chạy terraform state pull/backup ở local, kiểm tra metadata và quyền file; không commit bản backup hoặc upload state vào issue/log.
2. Migrate bản copy sang backend test, đọc prompt/source/destination, xác nhận backend key/workspace và chạy plan no-op; thử dùng sai key trong sandbox để nhận diện plan tạo mới trước khi khôi phục.
3. Mô phỏng concurrent operation hoặc lock tồn tại, đọc lock/error và xử lý owner; không dùng -lock=false để chữa cháy trên shared state.
4. Kiểm tra versioning/encryption/IAM/retention của storage backend và thử recovery từ một state version trong sandbox; backup/versioning không thay thế approval migrate.

Quality gate

Pass khi người học phân biệt local/standard/remote operation, chứng minh state location/workspace/key/lock, có backup/restore và IAM plan, migrate an toàn với no-op post-check, biết dừng khi plan tạo lại resource và không gộp backend migration với resource refactor. State/backup luôn được coi là dữ liệu nhạy cảm.