Blog
Thoughts on engineering, design, and building great products.
Secrets: sensitive, ephemeral, và Write-Only Arguments
State lưu secret ở dạng plaintext — bài này xử lý đúng vấn đề đó. sensitive chỉ che output chứ vẫn ghi vào state; ephemeral resources và write-only arguments (Terraform 1.10/1.11) mới thực sự giữ secret khỏi state. Demo thật: cùng một mật khẩu, cách cũ lọt vào state còn write-only thì không.
Thao Tác State: import Block, state mv, state rm
Làm việc với state hằng ngày: đưa hạ tầng có sẵn vào quản lý bằng import block và tự sinh cấu hình với -generate-config-out, đổi tên resource trong state bằng state mv, và gỡ resource khỏi quản lý mà không xóa nó bằng state rm. Tất cả chạy thật trên một bucket dựng tay từ trước.
Remote State Trên S3 Với use_lockfile
State nằm trên máy cá nhân không chia sẻ được, không an toàn, và hai người chạy cùng lúc sẽ ghi đè nhau. Bài này chuyển state lên S3: bootstrap một bucket có versioning và mã hóa, cấu hình backend, và bật khóa state bằng use_lockfile — cách hiện hành thay cho DynamoDB đã lỗi thời. Có demo xung đột lock thật.
Đồ Thị Phụ Thuộc: Implicit, depends_on, và -target
Terraform tự suy ra thứ tự tạo và xóa resource từ một đồ thị phụ thuộc. Bài này mổ chính đồ thị đó: phụ thuộc ngầm sinh ra từ tham chiếu, xem trực tiếp bằng lệnh graph, vì sao destroy đảo ngược thứ tự, khi nào cần depends_on, và vì sao -target chỉ là lối thoát hiểm.
State: Terraform Lưu Gì, Vì Sao Cần, và Drift
Đào vào file state: vì sao Terraform cần nó thay vì hỏi thẳng AWS mỗi lần, nó lưu chính xác cái gì, và cơ chế refresh so ba chiều giữa cấu hình, state và thực tế. Tự tay tạo drift bằng AWS CLI rồi xem Terraform phát hiện ra sao, khác nhau giữa plan thường và plan -refresh-only.
HCL Từ Trong Ra Ngoài: Block, Kiểu Dữ Liệu, Biểu Thức
Mổ xẻ ngôn ngữ HCL cho ra ngọn ngành: cấu trúc một block gồm gì, các kiểu dữ liệu string/number/bool/list/map/null, biểu thức và hàm, cách nội suy chuỗi. Dùng terraform console để thử trực tiếp, và xem block terraform{} còn khai báo được những gì.
Provider, Resource Đầu Tiên, và Vòng Đời init plan apply destroy
Dựng resource AWS thật đầu tiên: khai báo provider và pin phiên bản, tạo một bucket S3, rồi đi trọn vòng init → plan → apply → destroy. Mỗi lệnh làm gì bên trong, vì sao plan ghi 'known after apply', state lưu cái gì, và vì sao chạy apply lần hai không tạo thêm gì.