Trong nhiều tình huống Production thực tế, mình chọn bash script thay vì Ansible. Vì sao? Không phải vì bash ngon hơn mà vì team không đủ kỷ luật để xài Ansible đúng cách.
1. Ansible là một công cụ xịn và cũng là một con dao sắc
Ansible rất đẹp trên lý thuyết:
- Idempotent
- Readable
- Tái sử dụng được
- Có inventory
- Có role, task, handler các kiểu
Nhưng vấn đề nằm ở chỗ này: Khi team thiếu quy ước, thiếu code review nghiêm túc, thiếu hiểu biết về Ansible module, thì playbook sẽ biến thành một mớ YAML không ai dám chạm vào.
Mình từng vào một công ty có 5 người viết playbook theo 5 phong cách.
- Người thì nhét hết vào
main.ymldài 500 dòng - Người thì override biến loạn xạ trong host_vars
- Người khác lại hardcode path, không test, không rollback
Thành ra lỗi thì debug còn khó hơn bash, vì không biết nó fail ở đâu trong hàng tá biến và template.
2. Bash tuy xấu nhưng ai cũng hiểu
Bash script dĩ nhiên là không đẹp, không idempotent, không DRY, nhưng:
- Mọi người đều hiểu được
- Dễ test cục bộ
- Dễ copy ra chạy thử
- Và quan trọng là: khi hệ thống gặp sự cố, bash dễ đọc – dễ fix – dễ override bằng tay
Mình từng có một lần deploy bị fail vì playbook dính bug template. Devops khác trong team mất 2 tiếng tìm lỗi YAML. Mình rewrite lại bằng bash trong 15 phút: clone code, tạo env, migrate DB, restart service. Done.
3. Vấn đề không phải là công cụ mà là độ trưởng thành của team
Ansible cần discipline.
Nếu không có:
- Convention rõ ràng
- Review code kỹ
- Testing bài bản (molecule hoặc tương đương)
- Logging và rollback chuẩn
Thì bash vẫn là lựa chọn an toàn hơn cho team còn đang support sản phẩm mà không có đủ thời gian maintain.
4. Kết
Chắc chắn là bash không thể tốt hơn Ansible trong mọi tình huống. Nhưng đừng thần thánh hóa công cụ mà bỏ qua thực tế là:
- Tool càng phức tạp thì càng đòi hỏi team phải nghiêm túc
- Nếu không có văn hóa viết infra code như viết app code, thì đôi khi sự đơn giản của bash lại là cách ổn định nhất để sống sót qua on-call.
