Trong quá trình làm nghề, mình dùng qua Terraform và Ansible. Đây đều là hai công cụ rất phổ biến trong DevOps/Infra. Mình cũng khá hay gặp câu hỏi của mấy em intern kiểu như: Terraform với Ansible khác nhau ở đâu, rồi khi nào nên dùng cái nào?
Với anh em có tính chủ động hay đã có kinh nghiệm thì không vấn đề gì. Nhưng với người mới, hoặc với team đang bắt đầu chuẩn hóa hạ tầng, đây lại là chỗ rất dễ nhầm. Nên bài này mình xin chia sẻ lại theo trải nghiệm cá nhân, từ những gì mình đã va phải trong lúc làm việc, và vài case vận hành Production cho dễ hiểu nhé.
Khi mới nhìn vào hai tools này rất dễ gây cảm giác giống nhau vì rất hay bị sếp nhanh vào Iac. Terraform cũng automate được. Ansible cũng automate được. Terraform tạo được hạ tầng. Ansible cũng có thể đụng tới cloud. Terraform còn chạy được script. Ansible thì vốn sinh ra để tự động hóa đủ thứ. Nhìn qua, rất dễ đi đến kết luận là hai công cụ này chỉ khác nhau ở cách viết.
Nhưng đi làm lâu hơn một chút thì vấn đề không nằm ở syntax. Nó nằm ở chỗ mỗi tool đang gánh một loại trách nhiệm khác nhau.
Có thể nói Bản chất khác hoàn toàn nhau.
Ngắn gọn là Terraform hợp với phần hạ tầng, còn Ansible hợp với phần cấu hình và vận hành. Terraform trả lời câu hỏi hệ thống này cần có những tài nguyên nào. Ansible trả lời câu hỏi những tài nguyên đó cần được cấu hình ra sao để chạy đúng.
Nghe có vẻ cơ bản, nhưng rất nhiều rắc rối trong production lại bắt đầu từ đúng chỗ này nhìn thấy hai tool đều làm được, rồi tưởng chúng thay thế cho nhau hoàn toàn.
Khi bài toán là hạ tầng, Terraform thường đúng vai hơn
Có những việc mà cứ đụng vào là sẽ nghĩ tới Terraform gần như theo phản xạ. Ví dụ dựng VPC, subnet, security group, EC2, RDS, load balancer, IAM, DNS, hay xa hơn là cluster Kubernetes. Những thứ này có một điểm chung là chúng là resource theo đúng nghĩa: có vòng đời rõ ràng, có quan hệ phụ thuộc, có lúc được tạo mới, có lúc bị thay thế, có lúc phải cập nhật rất cẩn thận để không làm hỏng môi trường đang chạy.
Điều mà Terraform làm tốt là nó cho chúng ta một mô hình tương đối rõ để quản lý chuyện đó. Nó biết resource nào đang tồn tại, cái nào liên quan tới cái nào, thay đổi sắp tới sẽ tác động ra sao. Đặc biệt, khi hạ tầng không còn nhỏ nữa, việc có một cách nhìn tương đối mạch lạc về thay đổi là cực kỳ có giá trị.
Ví dụ, nếu team cần dựng một service mới trên AWS với đầy đủ network, máy chạy ứng dụng, load balancer, database, IAM role và DNS, thì Terraform gần như là lựa chọn rất tự nhiên. Không phải vì Ansible không làm được một phần của việc đó, mà vì bản chất bài toán lúc này là quản lý lifecycle của hạ tầng. Terraform hợp với cách nghĩ đó hơn hẳn.
Khi bài toán là cấu hình và vận hành, Ansible lại tự nhiên hơn nhiều
Ngược lại, có những việc mà nếu cố ép vào Terraform thì mình luôn có cảm giác đang làm trái tay. Chẳng hạn như cài Docker, cài Nginx, tạo user deploy, đẩy file config, sửa systemd, setup logrotate, cài monitoring agent, restart service theo batch, hoặc chuẩn hóa một đám server vốn đã tồn tại từ trước.
Đây là chỗ Ansible rất hợp.
Lý do không chỉ vì nó chạy qua SSH hay vì viết playbook nhanh. Cái hợp hơn nằm ở tư duy. Với Ansible, mình nghĩ theo kiểu máy nào cần gì, task nào chạy trước, task nào chạy sau, service nào cần restart, rollout theo từng nhóm thế nào để giảm rủi ro. Nó gần với nhịp vận hành thật hơn.
Ví dụ, nếu hạ tầng đã có sẵn 20 con VM và việc còn lại là chuẩn hóa cấu hình cho chúng, thì mình sẽ nghiêng rõ về Ansible. Lúc này câu hỏi không còn là hệ thống cần có resource nào nữa. Câu hỏi là làm sao để 20 con đó chạy cùng một kiểu, ít lệch nhau nhất, và sau này có thay đổi thì đẩy ra được theo cách kiểm soát được.
Đó là bài toán Ansible giải rất tự nhiên.
Chỗ khác biệt kỹ thuật đáng nhớ nhất
Nếu phải chọn ra một khác biệt kỹ thuật đáng nhớ nhất giữa Terraform và Ansible, mình sẽ chọn state.
Terraform mạnh lên rất nhiều nhờ state. Nó biết nó đang quản lý những gì, nhờ đó mới plan được, mới tính được quan hệ phụ thuộc, mới biết apply xong sẽ thay đổi cái gì. Với bài toán hạ tầng cloud, đây là lợi thế cực lớn.
Nhưng state cũng là thứ khiến Terraform không phải lúc nào cũng nhẹ đầu hơn. Ai từng gặp state lệch, import dở dang, đổi tên resource thiếu cẩn thận, hoặc nhiều người cùng sửa mà backend lock không chặt thì sẽ hiểu cái giá của nó. Tức là Terraform mạnh hơn ở lớp resource, nhưng đi kèm là trách nhiệm quản lý state tử tế.
Ansible thì khác. Nó không cố giữ một bức tranh trung tâm của toàn bộ hạ tầng theo cách đó. Nó đi vào target và đưa target về trạng thái mong muốn. Package cần được cài thì cài. File config cần đúng thì sửa cho đúng. Service cần chạy thì đảm bảo nó đang chạy. Thành ra nó rất hợp ở tầng cấu hình, nhưng không phải kiểu công cụ sinh ra để quản lý lifecycle của cả một mảng cloud resource phức tạp.
Nếu cần nói thật ngắn, mình sẽ nhớ thế này:
| Chỗ mạnh hơn | Terraform | Ansible |
|---|---|---|
| Quản lý tài nguyên hạ tầng | Rõ hơn | Không phải điểm mạnh chính |
| Cấu hình máy và service | Không phải sân chính | Tự nhiên hơn |
| Nhìn trước thay đổi hạ tầng | Tốt hơn | Hạn chế hơn |
| Chạy các bước vận hành theo trình tự | Không đẹp bằng | Hợp hơn |
Mình chỉ để một bảng ngắn như vậy thôi, vì phần này nếu nhồi quá nhiều bảng sẽ lại thành tài liệu, mất chất bài chia sẻ.
Production hay mắc ở đâu? Thường là ở lúc bắt một tool làm quá phần của nó
Theo trải nghiệm của mình, cả Terraform lẫn Ansible đều dễ bị dùng lộn.
Một kiểu gặp khá nhiều là dùng Terraform để làm quá nhiều việc bên trong máy. Ban đầu chỉ là vài dòng user data. Sau đó thêm remote-exec. Rồi thêm null_resource để chạy script. Lúc đầu trông vẫn ổn vì thấy một lệnh apply là xong hết. Nhưng càng về sau, phần cấu hình, deploy, restart service, thậm chí migrate cũng bị nhét vào chung một chỗ với hạ tầng. Đến khi có lỗi thì rất khó nói đang hỏng ở infra hay hỏng ở logic cấu hình. Đọc code cũng mệt, debug còn mệt hơn.
Chiều ngược lại, cũng có team dùng Ansible để ôm quá nhiều phần cloud resource. Khi quy mô nhỏ thì không sao. Nhưng khi resource nhiều hơn, phụ thuộc chồng chéo hơn, nhiều môi trường hơn, nhu cầu review thay đổi rõ ràng hơn, bài toán drift bắt đầu khó chịu hơn, thì mọi thứ dần nặng lên. Không phải vì Ansible kém, mà vì nó đang bị giao một phần việc không phải thế mạnh trung tâm.
Nói cách khác, vấn đề thường không nằm ở việc tool nào dở. Vấn đề nằm ở chỗ bắt tool nào đó gánh luôn phần trách nhiệm mà tool kia sinh ra để làm tốt hơn.
Cách nhớ để khỏi nhầm
Nếu phải giữ lại một câu đơn giản nhất sau tất cả những thứ ở trên, mình sẽ giữ câu này:
- Terraform dựng cái hệ thống cần có.
- Ansible làm cho cái hệ thống đó chạy đúng.
Câu này không đúng tuyệt đối cho mọi hoàn cảnh, nhưng với phần lớn tình huống thực tế mà mình từng làm, nó đủ đúng để giúp chọn hướng tiếp cận ban đầu.
Vậy có phải lúc nào cũng cần dùng cả hai không?
Thực ra là không.
Có những hệ thống mà Terraform gần như là trục chính, nhất là khi phần lớn workload nằm ở managed service, container platform hoặc serverless, và team không phải chăm nhiều ở tầng VM hay OS. Trong trường hợp đó, Terraform gánh phần hạ tầng, còn deploy ứng dụng có thể nằm ở pipeline hoặc công cụ khác.
Ngược lại, cũng có những hệ thống mà Ansible lại mang lại giá trị nhanh hơn, nhất là khi hạ tầng đã tồn tại sẵn, còn nỗi đau lớn nhất nằm ở chuyện cấu hình máy, patching, deploy hay chuẩn hóa môi trường vận hành.
Nhưng với khá nhiều hệ thống production mà mình từng thấy, cách bền nhất vẫn là chia vai khá rõ: Terraform lo phần dựng nền, Ansible lo phần cấu hình và vận hành trên nền đó. Nghe không mới, nhưng thường là cách ít gây nợ kỹ thuật hơn.
Kết Luận
Nếu hỏi Terraform và Ansible khác nhau ở đâu, thì câu trả lời ngắn nhất của mình vẫn là:
- Terraform hợp với bài toán hạ tầng.
- Ansible hợp với bài toán cấu hình và vận hành.
Mình không nghĩ đây là câu chuyện công cụ nào hơn công cụ nào. Cũng không nghĩ có một đáp án đúng cho mọi team. Nhưng nếu dùng đúng vai, nhất là khi hệ thống đã đi vào production, thì mọi thứ thường đỡ rối hơn rất nhiều.
