
Terraform là gì là câu hỏi mà bất kỳ lập trình viên nào làm hạ tầng đều gặp phải. Công cụ mã nguồn mở của HashiCorp cho phép bạn mô tả toàn bộ hạ tầng cloud của mình bằng một ngôn ngữ khai báo đơn giản, rồi để máy tính lo phần còn lại. Thay vì click tay trên AWS console hay GCP, bạn viết code, commit vào Git, và triển khai lặp lại được trên mọi môi trường.
Bài này đi từ lý do Infrastructure as Code ra đời, cách Terraform mô hình hoá tài nguyên, quy trình plan/apply, cho tới những lỗi phổ biến mà đội ngũ mới hay mắc khi chuyển sang dùng Terraform.

Vì sao cần Infrastructure as Code
Trước khi IaC xuất hiện, cấu hình hạ tầng nằm trong đầu kỹ sư vận hành hoặc trong một file wiki. Khi cần mở rộng từ 3 server lên 30 server, người ta click tay 27 lần nữa. Sai sót là ở đây, và không ai biết server thứ 14 được cấu hình khác gì.
Infrastructure as Code đưa cấu hình hạ tầng về cùng định dạng với mã nguồn: văn bản, review được, lịch sử thay đổi rõ ràng. Những lợi ích thực tế:
- Không lặp lại thao tác tay — script tạo 30 server cho production chạy trong vài phút.
- Phát hiện sai sót sớm — pull request review phát hiện được security group mở cả Internet trước khi nó lên production.
- Tái tạo môi trường — dev, staging, production dùng chung một bộ khai báo, chỉ khác biến số.
- Khôi phục sau thảm hoạ — dựng lại toàn bộ hạ tầng từ Git khi server cháy.
- Chi phí minh bạch — nhìn code là biết nhóm đang chạy những gì, tránh quên tắt tài nguyên chạy đêm.
Terraform là gì và hoạt động ra sao
Terraform là gì — câu trả lời ngắn: đây là công cụ IaC phổ biến nhất thế giới, do HashiCorp phát triển, được viết bằng Go, mã nguồn mở theo giấy phép MPL-2.0. Nó hoạt động theo ba bước rõ ràng:
- Write — bạn viết khai báo tài nguyên trong file cấu hình HCL hoặc JSON.
- Plan — Terraform đối chiếu khai báo với hạ tầng thực tế, sinh ra danh sách thay đổi cần thiết.
- Apply — thực thi những thay đổi đó và lưu trạng thái mới vào file state.
Điểm cốt lõi nằm ở file state. Terraform ghi lại toàn bộ tài nguyên nó quản lý vào một file JSON, thường đặt tên terraform.tfstate. Nhờ vậy ở lần chạy sau, nó biết chính xác tài nguyên nào do nó tạo ra nên có thể sửa hoặc huỷ. Nhưng file state cũng chứa thông tin nhạy cảm như mật khẩu database, nên tuyệt đối không commit file này vào Git.
Ngôn ngữ HCL gần giống JSON nhưng dễ đọc hơn nhiều, cho phép khai báo biến, vòng lặp và hàm:
resource "aws_instance" "web" {
ami = data.aws_ami.ubuntu.id
instance_type = var.instance_type
subnet_id = aws_subnet.main.id
tags = {
Name = "web-${var.environment}"
}
}
Ba lệnh quan trọng nhất
| Lệnh | Chức năng | Khi nào dùng |
|---|---|---|
terraform init |
Tải provider, khởi tạo thư mục làm việc | Mỗi khi clone repo hoặc thêm provider mới |
terraform plan |
Xem thay đổi mà không áp dụng | Mỗi lần thay đổi khai báo |
terraform apply |
Thực thi thay đổi đã plan | Sau khi đã duyệt output của plan |
terraform destroy |
Xoá toàn bộ tài nguyên trong khai báo | Dọn dẹp môi trường tạm, cẩn thận khi dùng production |
terraform fmt |
Chuẩn hoá định dạng file HCL | Trước khi commit |
terraform validate |
Kiểm tra cú pháp khai báo | Trong bước lint của CI |
Luôn chạy plan trước apply và đọc kỹ output. Terraform liệt kê rõ dấu + cho tạo mới, - cho xoá, ~ cho sửa. Một lần apply nhầm có thể xoá nhầm database, mà Terraform cũng chẳng hỏi lại lần thứ hai.

Terraform Provider và cấu trúc thư mục
Terraform không tự hiểu AWS hay Google Cloud. Nó giao tiếp với họ qua các provider — plugin riêng cho từng nền tảng, tải về từ registry khi chạy init. Một cấu trúc thư mục thực tế cho dự án nhiều môi trường thường trông như sau:
infrastructure/
modules/
vpc/
main.tf
variables.tf
outputs.tf
environments/
staging/
main.tf
terraform.tfvars
production/
main.tf
terraform.tfvars
Cấu trúc này tách phần tái sử dụng (module) khỏi phần cấu hình riêng từng môi trường. Module là cách gom các tài nguyên thành khối có đầu vào và đầu ra riêng, giúp tái dùng cấu hình VPC cho cả staging lẫn production mà không viết lại.
Quản lý bí mật và state từ xa
Không bao giờ hardcode mật khẩu trong file .tf. Bội đội hiện đại dùng biến môi trường, Vault hoặc secret manager của cloud. Với state, chuẩn là lưu trên backend từ xa thay vì file cục bộ:
terraform {
backend "s3" {
bucket = "myapp-tfstate"
key = "prod/terraform.tfstate"
encrypt = true
region = "ap-southeast-1"
}
}
Cách này giúp nhiều người cùng truy cập một state, khóa file trong lúc đang apply để tránh xung đột. Ngoài ra cần bật state locking — hoặc tuỳ chọn -lock-timeout khi apply để không vỡ pipeline khi hai người chạy song song.
Những lỗi phổ biến cần tránh
- Commit file state vào Git — lộ bí mật, thêm vào
.gitignorengay lập tức nếu đã lỡ. - Không kiểm tra output của plan — luôn đọc, đặc biệt khi có dòng bị đánh dấu xoá.
- Hardcode giá trị thay vì biến — khiến mọi môi trường trở nên giống nhau và khó mở rộng.
- Dùng chung một state cho mọi môi trường — dễ vỡ hạ tầng khi apply nhầm; tách state theo từng môi trường.
- Bỏ qua quyền truy cập tối thiểu — thêm
iam_rolegiới hạn phạm vi thay vì dùng key admin. - Không đặt giới hạn chi phí — dùng budget alert của cloud để chặn hoá đơn bất ngờ do tài nguyên quên tắt.

Terraform kết hợp với CI/CD
Luồng chuẩn là đưa fmt, validate, plan vào pipeline. Khi có pull request merge vào nhánh chính, tự động apply. Nhiều đội dùng Atlantis hoặc Terraform Cloud để thêm lớp phê duyệt: người khác phải click duyệt plan trước khi apply, tách biệt hoàn toàn quyền viết hạ tầng khỏi quyền viết code.
Nếu muốn phân tách theo vai trò, dùng -target để giới hạn phạm vi thay đổi, và luôn nhớ rằng target có thể làm state lệch so với khai báo. Đây là công cụ thoát chốt cho tình huống khẩn cấp, không phải cách làm việc hằng ngày.
Kết luận
Trả lời câu hỏi ban đầu: Terraform là gì — đó là lớp trừu tượng cho phép quản lý hạ tầng như quản lý mã nguồn. Nó không thay thế hiểu biết về hệ điống, chỉ giúp bạn hiện thức hoá kiến thức đó một cách có kiểm soát, review được và lặp lại được. Nếu đội của bạn đang click tay trên console để dựng môi trường, đây là lúc để bắt đầu chuyển đổi.
Tài liệu chính thức của dự án nằm tại trang HashiCorp Terraform Documentation, phần Concepts giải thích chi tiết về module, provider và state. Bạn cũng nên đọc bài The Twelve-Factor App để hiểu vì sao cấu hình hạ tầng nên được tách biệt khỏi ứng dụng.
