Chuyện về DevSecOps
Terraform và cú pháp "tự hủy":
apply -auto-approve
Một câu chuyện "kinh dị" có thật về quyền năng, sự vội vã, và một dòng lệnh hủy diệt.
Chào anh em, lại là tôi từ Chuyện về DevSecOps đây.
Hôm nay chúng ta không nói về lý thuyết cao siêu, mà kể một câu chuyện "kinh dị" có thật ở đâu đó ngoài kia. Một câu chuyện về quyền năng, sự vội vã, và một dòng lệnh có sức công phá hơn cả cú búng tay của Thanos: terraform apply -auto-approve. 💀
Bối cảnh: Team "Titan"
Team "Titan", một team rất xịn, làm chủ Terraform như hơi thở. Hạ tầng của họ được code hóa 100%, và họ tự hào về tốc độ deploy của mình. Mọi thay đổi, từ tạo một cái S3 bucket nhỏ xinh đến dựng lại cả một cụm Kubernetes, đều qua Terraform.
Một "feature" nhỏ cần release gấp. Một dev lead kinh nghiệm đầy mình, chúng ta hãy gọi anh là "Anh T." cho thân mật, cần sửa nhanh một cái security group rule.
Tự tin vào sự thay đổi "nhỏ xíu" của mình, và để tiết kiệm vài phút review, anh T. đã làm điều mà mọi người đều biết là không nên làm: mở terminal và gõ dòng lệnh huyền thoại.
$ terraform apply -auto-approveRắc.
Vài giây sau, Slack bắt đầu "nổ" liên hồi. Hệ thống monitoring đỏ rực như cây thông Noel. Toàn bộ dàn web server trả về lỗi 503. Dịch vụ sập! 😱
Chuyện gì đã xảy ra?
Sau một hồi "lặn ngụp" trong hoảng loạn, team phát hiện ra rằng: do một lần refactor code module mạng trước đó, việc thay đổi security group rule đó đã vô tình kích hoạt một thay đổi khác. Terraform hiểu rằng nó cần thay thế (replace) toàn bộ Launch Configuration của cụm Auto Scaling Group, dẫn đến việc toàn bộ dàn EC2 instance cũ bị "thổi bay" trước khi instance mới kịp sẵn sàng.
Tất cả chỉ vì bỏ qua bước terraform plan. Cái bảng kế hoạch chi tiết mà Terraform đưa ra, thứ cho chúng ta biết chính xác nó sẽ thêm (+), sửa (~), hay xóa (-) cái gì, đã bị phớt lờ.
Bài học xương máu rút ra
Terraform cho bạn quyền năng của một vị thần, nhưng nó cũng đòi hỏi sự kỷ luật của một tu sĩ.
- -auto-approve là một "cái bẫy": Nó chỉ nên tồn tại trong các pipeline tự động đã được kiểm soát cực kỳ chặt chẽ, sau khi bước plan đã được cả team review và phê duyệt. Tuyệt đối không dùng nó trên máy local của bạn cho môi trường production.
- GitOps không phải để cho "ngầu": Đây chính là cứu cánh! Quy trình chuẩn phải là:
- Pull Request (PR): Mọi thay đổi về code hạ tầng phải được tạo thành một PR.
- Tự động plan: CI/CD pipeline tự động chạy `terraform plan` và post kết quả vào PR.
- Review kế hoạch (The Plan): Cả team sẽ vào review kết quả plan đó.
- Merge và apply: Sau khi PR được merge, một pipeline khác mới được kích hoạt để chạy `terraform apply`.
- Quyền lực đi đôi với trách nhiệm: Đừng bao giờ tin vào những thay đổi "nhỏ". Trong thế giới của Infrastructure as Code, một dòng code có thể tạo ra hiệu ứng cánh bướm và đánh sập cả một hệ thống.
Câu chuyện của team "Titan" là một lời nhắc nhở đắt giá. Tốc độ rất quan trọng, nhưng sự ổn định và an toàn của hệ thống còn quan trọng hơn.
