- IaC hơn gì so với click tay trên console của cloud?
Hạ tầng thành code có review, có version, dựng lại được. Cùng một repo dựng ra staging và production giống nhau, và git log trả lời được câu "vì sao security group này mở port 6379". Click tay không trả lời được câu đó. Sau…
- State của Terraform chứa gì và vì sao không được commit nó vào Git?
State là bảng ánh xạ giữa địa chỉ resource trong code và ID thật ở provider, cộng với snapshot attribute của lần apply gần nhất. Không có state, Terraform không biết awsdbinstance.main ứng với DB nào nên apply sẽ tạo mới thay vì update. Lý…
- Đọc output của `terraform plan` thì phải soi kỹ nhất dòng nào?
Dòng ... must be replaced và ký hiệu -/+. Đó là destroy rồi create lại, và với RDS hay EBS thì bằng mất dữ liệu. Đọc theo thứ tự: 1. Dòng tổng cuối: Plan: 2 to add, 1 to change, 3 to destroy. — số…
- Provider là gì? Dùng Terraform có làm hạ tầng portable giữa AWS và GCP không?
Không. Provider là plugin dịch resource block thành API call của một dịch vụ cụ thể, mà resource của mỗi cloud khác nhau hoàn toàn. awsinstance không chạy trên GCP, đổi cloud vẫn phải viết lại gần hết code. Cái dùng chung được là tool,…
- Variable nhận giá trị theo thứ tự ưu tiên nào, và secret nên truyền kiểu gì?
Từ thấp lên cao: default trong block variable, rồi TFVAR, rồi terraform.tfvars / .auto.tfvars, rồi -var-file, cao nhất là -var trên CLI. Cấu trúc thường dùng: mỗi env một file prod.tfvars / staging.tfvars, commit vào repo, trừ secret. Khác biệt giữa hai env nằm rõ…
- Khác nhau giữa `resource` và `data` block? Dùng `data` khi nào?
resource tạo và quản lý vòng đời; data chỉ đọc thứ đã tồn tại, không tạo, không sửa, không xoá. Đây là cách nối các state độc lập mà không gộp chúng: team platform sở hữu VPC, team application chỉ đọc và không có quyền…
- `terraform init` làm gì, và `.terraform.lock.hcl` có phải commit không?
init tải provider + module về .terraform/, cấu hình backend, và sinh hoặc cập nhật .terraform.lock.hcl. Lock file phải commit. Lock file ghi version chính xác + checksum của từng provider. Không commit thì mỗi máy resolve ra một version khác, plan khác nhau giữa…
- Terraform quyết định thứ tự tạo resource dựa vào đâu? Khi nào cần `depends_on`?
Dựa vào dependency graph suy ra từ tham chiếu giữa các resource, không phải thứ tự viết trong file. Resource không phụ thuộc nhau được tạo song song. dependson chỉ cần khi có phụ thuộc ẩn mà Terraform không thấy qua tham chiếu: Lạm dụng…
- Remote backend cần những gì cho production, và state locking giải quyết vấn đề gì?
Locking chặn hai apply chạy song song trên cùng state. Không có nó, hai người apply cùng lúc ghi đè state của nhau, hậu quả là resource mồ côi không nằm trong state nào. Checklist backend production: - Encryption at rest — state chứa secret.…
- Có người sửa tay trên console. Terraform xử lý sao và phòng thế nào?
Plan phát hiện drift lúc refresh và đề xuất kéo resource về đúng code, nên thay đổi làm tay bị revert ở lần apply kế tiếp. Đây vừa là feature vừa là bẫy: hotfix mở port lúc sự cố sẽ bị xoá âm thầm khi…
- Tách code ra module có giảm blast radius không?
Không. Module tách về mặt code để reuse, nhưng mọi module trong cùng một config vẫn dùng chung một state. Gõ nhầm terraform destroy vẫn xoá hết. Hai mức tách khác nhau hoàn toàn: - Module = reuse code, interface là variable / output. -…
- Vì sao nên dùng `for_each` thay vì `count` khi tạo nhiều resource?
count đánh địa chỉ theo index, nên xoá phần tử ở giữa list làm mọi phần tử sau bị shift index và Terraform destroy/recreate hàng loạt. Đây là cái bẫy tốn kém nhất với người mới: chèn một subnet vào giữa list và plan báo…
- Đưa một EC2 tạo tay vào Terraform quản lý thì làm những bước nào?
Viết resource block tương ứng, import vào state theo ID thật, rồi sửa code tới khi terraform plan ra "No changes". Cách mới (khai báo trong code, review được trong PR): Cách cũ chạy lệnh trực tiếp: Bước tốn thời gian nhất là bước cuối:…
- Đổi tên resource hoặc bọc nó vào module mà không muốn bị recreate thì làm gì?
Khai báo moved block. Terraform nhận diện resource theo địa chỉ trong config, nên đổi tên mà không khai báo bị hiểu là destroy cái cũ + create cái mới. Cách cũ là chạy lệnh trên state: moved block tốt hơn vì nó được review…
- Tách staging và production: dùng workspace hay tách thư mục?
Dự án lớn thường tách thư mục, mỗi env một state riêng, cùng gọi chung module. Workspace hợp cho env tạm và ngắn hạn. Vì sao tách thư mục hợp hơn cho production: - Khác biệt giữa hai env hiện ra trong code, review được.…
- `sensitive = true` có bảo vệ được secret không?
Không. Nó chỉ che giá trị trong output và log, hiện ra (sensitive value). State vẫn lưu plaintext. Đây là hiểu nhầm rất phổ biến và là nguyên nhân nhiều vụ leak: team tưởng đánh dấu là đủ rồi để state bucket cho cả công…
- Pipeline chạy Terraform nên gồm những bước nào?
plan tự động khi mở PR và post output vào comment, apply sau khi merge. Thay đổi hạ tầng đi qua đúng quy trình như thay đổi code. Điểm quan trọng về tính đúng đắn: apply đúng file plan đã review, đừng plan lại lúc…
- Ngăn RDS production bị xoá nhầm qua Terraform bằng cách nào?
Xếp nhiều lớp, vì một lớp không đủ: preventdestroy làm mọi plan chứa thao tác destroy resource đó fail thay vì chạy. Giới hạn của nó: chỉ chặn ở tầng Terraform, xoá thẳng trên console thì không đỡ được — nên phải có deletionprotection ở…
- Vì sao `remote-exec` provisioner bị coi là giải pháp cuối cùng?
Kết quả của lệnh không được ghi vào state, nên Terraform chỉ biết provisioner đã chạy hay chưa, không biết máy đang ở cấu hình nào. Lệnh fail giữa chừng để lại resource tainted. Thay bằng, theo thứ tự ưu tiên: 1. AMI dựng sẵn…
- Tạo resource ở hai region hoặc hai account trong cùng một config thì làm sao?
Khai báo nhiều provider block với alias, rồi chỉ định provider cho từng resource. Các trường hợp thường cần: cert cho CloudFront, DR ở region thứ hai, và kiến trúc multi-account (mỗi env một account, dùng assumerole). Khi truyền vào module, module phải khai báo…
- Test cho Terraform code nên bắt đầu từ đâu?
Từ fmt + validate + plan tự động trong CI. Ba bước này rẻ, chạy vài giây, và bắt được phần lớn lỗi trước khi hạ tầng bị đụng tới. Các tầng theo mức đầu tư tăng dần: Dòng cuối là kiểm tra đáng có…
- Ai nên có quyền `terraform apply` lên production?
Chỉ CI role. Người chỉ có read-only ở production. Nhờ vậy mọi thay đổi đều qua review, để lại audit trail, và không ai apply từ laptop. Dùng OIDC để CI mượn role ngắn hạn, không giữ access key: Phải chuẩn bị sẵn break-glass: một…
- Thay một resource đang phục vụ mà không downtime thì cấu hình thế nào?
createbeforedestroy. Mặc định Terraform destroy trước rồi create sau, nên có một khoảng không có resource nào phục vụ. Điều kiện để chạy được: hai bản phải tồn tại đồng thời. Nhiều resource ràng buộc tên unique nên phải dùng nameprefix thay vì name, không…
- Policy as code (Sentinel, OPA/Conftest) dùng để làm gì trong pipeline Terraform?
Chặn config vi phạm quy định ngay trong pipeline: S3 bucket public, security group mở port 22 ra 0.0.0.0/0, resource thiếu tag bắt buộc. Điểm mạnh là quy định trở thành thứ chạy được thay vì một trang wiki. Wiki thì người mới không đọc,…
- Vì sao không nên để toàn bộ hạ tầng công ty trong một state?
Blast radius quá rộng và apply quá chậm: một sai sót chạm tới mọi thứ, mỗi lần chạy phải refresh hàng nghìn resource, và state lock làm các team chờ nhau. Ba tiêu chí chia thường dùng: theo environment, theo domain nghiệp vụ, và theo…
- IaC giúp kiểm soát chi phí cloud thế nào?
Chi phí thành thứ nhìn thấy được lúc review PR thay vì phát hiện vào cuối tháng. Ba lợi ích cụ thể: 1. Ước tính trước khi merge — reviewer thấy ngay một PR làm hoá đơn tăng 800 đô/tháng. 2. Dọn dẹp khả thi…
- Vì sao tag mọi resource lại quan trọng, và áp tag nhất quán bằng cách nào?
Tag cho phép phân bổ chi phí theo team/dự án và trả lời được resource lạ này của ai. Không có tag thì hoá đơn chỉ là một con số tổng. Áp một lần ở provider level: Tag ManagedBy là cái hữu ích nhất lúc…
- `terraform apply` fail giữa chừng vì API provider lỗi. Lúc đó state ra sao?
Resource đã tạo vẫn được ghi vào state, nên chạy lại sẽ làm tiếp phần còn thiếu chứ không làm lại từ đầu. Terraform không có transaction trên nhiều resource nên không có rollback toàn bộ. Trường hợp khó chịu hơn: resource đã tạo ở…
- Module dùng chung trong công ty nên được reference và release thế nào?
Reference theo version đã pin, không bao giờ trỏ vào main. Trỏ vào main nghĩa là hạ tầng đổi chỉ vì ai đó merge một PR, và lúc sự cố không ai lần ra nguyên nhân. Quy trình release nên có: semver rõ ràng, changelog…
- Dựng environment tạm cho mỗi PR cần những điều kiện gì?
Mọi resource phải đặt tên theo branch/PR để không trùng, và destroy sạch được khi PR đóng. Các chỗ thường vướng: - Tên unique toàn cầu (S3 bucket, domain, ECR repo). - Resource có preventdestroy hoặc deletionprotection copy từ production sang. - Thứ sinh ra…
- State bị xoá mất hoàn toàn. Hậu quả và cách khôi phục?
- `terraform plan` đã mất 15 phút. Hướng xử lý gốc rễ là gì?
- Drift detection ở quy mô lớn nên làm thế nào, và phân loại drift ra sao?
- Nâng Terraform lên major version mới trên hàng chục state thì làm thế nào?
- IaC đóng vai trò gì trong kế hoạch disaster recovery?
- Vì sao RDS và S3 cần cách quản lý khác với EC2 và ASG?
- Tiếp quản một hệ thống production tạo tay hoàn toàn thì bắt đầu từ đâu?
- Việc gì không nên giao cho Terraform quản lý?
- Đánh giá một dự án IaC có khoẻ mạnh hay không thì nhìn vào đâu?
- Nguyên nhân phổ biến nhất khiến việc adopt IaC thất bại là gì?
