Tại Sao Kiểm Thử Thủ Công Là Bước Không Thể Thiếu Khi Làm Việc Với Terraform?

Trong bối cảnh Infrastructure as Code (IaC), đặc biệt là khi sử dụng các công cụ mạnh mẽ như Terraform, kiểm thử thủ công thường bị các kỹ sư bỏ qua. Tuy nhiên, trước khi có thể triển khai các bài kiểm tra tự động hóa, việc thực hiện kiểm thử thủ công là điều kiện tiên quyết để nắm bắt toàn bộ cách thức hạ tầng hoạt động trong các điều kiện thực tế.

Vào ngày thứ 17 của thử thách 30 ngày làm chủ Terraform, tôi đã tập trung xây dựng một quy trình kiểm thử thủ công bài bản cho cụm máy chủ web của mình (bao gồm Application Load Balancer, Auto Scaling Group và các EC2 instances). Trải nghiệm này đã củng cố một tư duy quan trọng: bạn không thể tự động hóa những thứ bạn không hiểu rõ.

Tại sao kiểm thử thủ công lại quan trọng?

Kiểm thử thủ công giúp trả lời những câu hỏi mang tính sống còn đối với hệ thống:

• Hạ tầng có được triển khai chính xác không?
• Nó có hoạt động như mong đợi trong các điều kiện thực tế không?
• Có tồn tại các cấu hình sai lệch (misconfigurations) mà các công cụ kiểm tra hợp lệ (validation tools) bỏ sót không?

Mặc dù các lệnh terraform validate và terraform plan đảm bảo tính chính xác ở cấp độ cấu hình, chúng không thể bảo chứng cho chức năng thực tế trong môi trường live. Kiểm thử thủ công chính là cầu nối nối khoảng trống đó.

Xây dựng danh sách kiểm tra có cấu trúc

Thay vì thao tác ngẫu nhiên trên AWS Console, tôi đã xây dựng một danh sách kiểm tra (checklist) chi tiết để định hướng quá trình kiểm thử.

Xác thực việc cung cấp tài nguyên (Provisioning Verification)

• Chạy terraform init và xác nhận quá trình khởi tạo hoàn tất thành công.
• Chạy terraform validate để đảm bảo cấu hình hợp lệ.
• Chạy terraform plan và xác minh các tài nguyên dự kiến.
• Chạy terraform apply và xác nhận việc cung cấp thành công.

Độ chính xác của tài nguyên (Resource Correctness)

• Kiểm tra sự tồn tại của tài nguyên trong AWS Console (EC2, ALB, Target Groups).
• Xác nhận tên, thẻ (tags) và vùng (region) khớp với cấu hình.
• Đảm bảo các quy tắc của nhóm bảo mật (Security Group) được áp dụng chính xác.

Kiểm tra chức năng (Functional Verification)

• Lấy DNS của ALB bằng lệnh terraform output.
• Chạy lệnh curl http://<alb-dns> và kiểm tra phản hồi.
• Xác nhận tất cả các phiên bản (instances) đều vượt qua các bài kiểm tra sức khỏe (health checks).
• Chấm dứt (terminate) một instance và xác minh ASG thay thế nó bằng một instance mới.

Tính nhất quán của trạng thái (State Consistency)

• Chạy terraform plan sau khi apply → mong đợi thông báo "No changes" (Không có thay đổi).
• Xác nhận trạng thái của Terraform khớp với hạ tầng thực tế.

Kiểm tra hồi quy (Regression Check)

• Thực hiện một thay đổi cấu hình nhỏ (ví dụ: thêm một tag).
• Đảm bảo chỉ các thay đổi mong muốn xuất hiện trong terraform plan.
• Apply và xác nhận kế hoạch sạch sẽ sau đó.

Thực thi kiểm tra: Điều gì hoạt động và điều gì không

Việc chạy danh sách kiểm tra đã hé lộ cả những thành công và thất bại trong quy trình.

Các bài kiểm tra thành công

Khởi tạo Terraform Lệnh: terraform init Kết quả: PASS (Đạt)

Triển khai Terraform Lệnh: terraform apply -auto-approve Kết quả: PASS Tất cả tài nguyên được tạo thành công.

Kiểm tra chức năng ALB Lệnh: curl http://my-app-alb-123456.us-east-1.elb.amazonaws.com Kết quả: PASS Phản hồi trả về: "Hello World v1" (đã xác nhận qua trình duyệt).

Tự phục hồi của Auto Scaling Lệnh: aws ec2 terminate-instances --instance-ids i-xxxx Kết quả: PASS Một phiên bản thay thế đã được tự động khởi chạy.

Thất bại và Khắc phục

Kiểm tra: Tính nhất quán của Terraform Plan Lệnh: terraform plan

• Mong đợi: Không có thay đổi.
• Thực tế: Phát hiện 1 thay đổi tài nguyên.
• Kết quả: FAIL (Không đạt).

Nguyên nhân gốc rễ: Thiếu một tag trong cấu hình của nhóm bảo mật (Security Group).

Khắc phục: Đã thêm tag bị thiếu vào mã Terraform và chạy lại: terraform apply

Kết quả kiểm tra lại: PASS Sự cố này làm nổi bật cách kiểm thử thủ công có thể phát hiện các vấn đề thực tế mà việc kiểm tra tĩnh (static validation) không thể làm được.

Kiểm thử trên nhiều môi trường

Tôi đã chạy cùng một bài kiểm tra trên cả môi trường phát triển (development) và môi trường sản xuất (production).

Các khác biệt chính:

• Môi trường Dev sử dụng t2.micro, trong khi môi trường Production sử dụng t3.medium.
• Môi trường Production có các quy tắc Security Group chặt chẽ hơn.

Vấn đề bất ngờ: Ứng dụng ban đầu thất bại trong môi trường Production vì HTTP (cổng 80) bị chặn.

Khắc phục: Cập nhật nhóm bảo mật để cho phép lưu lượng truy cập HTTP inbound.

Điều này minh họa cho một vấn đề thực tế phổ biến: cái gì hoạt động ở dev có thể thất bại ở production do sự khác biệt về cấu hình.

Tầm quan trọng của việc dọn dẹp (Cleanup)

Sau khi kiểm thử, tôi đã hủy tất cả tài nguyên để tránh các chi phí không cần thiết.

terraform destroy -auto-approve

Xác minh

• aws ec2 describe-instances -> Output: []
• aws elbv2 describe-load-balancers -> Output: []

Tại sao việc dọn dẹp lại quan trọng?

Việc dọn dẹp nghe có vẻ đơn giản, nhưng đây thường là nơi các kỹ sư thất bại. Terraform có thể chỉ hủy một phần tài nguyên, để lại các hạ tầng mồ côi (orphaned infrastructure).

Nếu bỏ qua việc dọn dẹp:

• Chi phí AWS có thể tăng nhanh.
• Các tài nguyên cũ có thể can thiệp vào các bài kiểm tra trong tương lai.
• Sự lệch pha hạ tầng (infrastructure drift) sẽ trở nên khó quản lý hơn.

Bài học từ Terraform Import

Thử nghiệm với lệnh terraform import đã giới thiệu một khái niệm quan trọng: đưa hạ tầng có sẵn dưới sự quản lý của Terraform.

Nó giải quyết vấn đề gì:

• Cho phép Terraform quản lý các tài nguyên được tạo thủ công.

Nó KHÔNG giải quyết vấn đề gì:

• Nó không tự sinh ra cấu hình Terraform.
• Bạn phải viết thủ công các tệp .tf.

Điều này củng cố rằng Terraform không chỉ là một công cụ — nó đòi hỏi sự kỷ luật và sự hiểu biết sâu sắc từ người sử dụng.

Các thách thức chính và cách khắc phục

Vấn đề	Nguyên nhân gốc rễ	Cách khắc phục
Thiếu tag	Không được định nghĩa trong cấu hình	Thêm khối tag
ALB không thể truy cập	Cổng 80 bị chặn	Cập nhật Security Group
Plan không nhất quán	Sự lệch pha cấu hình (Config drift)	Chạy lại cấu hình (re-apply)

Tổng kết

Kiểm thử thủ công không phải là tùy chọn — nó là nền tảng của một hạ tầng đáng tin cậy.

Nó giúp bạn:

• Hiểu sâu sắc về hệ thống của mình.
• Phát hiện các thất bại trong thế giới thực sớm hơn.
• Xây dựng sự tự tin trước khi tự động hóa.

Mọi thất bại được phát hiện trong quá trình kiểm thử thủ công sẽ trở thành một bài kiểm tra tự động hóa trong tương lai.

Khi tôi tiếp tục thử thách này, bước tiếp theo đã rõ ràng: chuyển đổi các kiểm tra thủ công này thành các bài kiểm tra tự động.

Tóm tắt Ngày 17

• Xây dựng danh sách kiểm tra thủ công có cấu trúc.
• Kiểm thử cả môi trường phát triển và sản xuất.
• Xác định và khắc phục các vấn đề hạ tầng thực tế.
• Thực hành kỷ luật dọn dẹp nghiêm ngặt.

Kiểm thử thủ công không chỉ là một bước đi — nó là một tư duy.