Terraform vs. Ansible: Cái nào bạn thực sự cần?

Những người mới với Infrastructure as Code thường đặt câu hỏi này theo một trong hai cách: "tôi nên học công cụ nào trước" hoặc "tại sao các team lại sử dụng cả hai." Câu trả lời ngắn gọn là Terraform và Ansible giải quyết các vấn đề khác nhau, và hầu hết các setup production sử dụng chúng cùng lúc thay vì chỉ chọn một.

Terraform thực sự dùng để làm gì

Terraform là một công cụ provisioning. Nó khai báo cấu trúc hạ tầng nên tồn tại: một VPC, ba EC2 instances, một RDS database, một S3 bucket có policy cụ thể. Bạn viết HCL mô tả trạng thái cuối cùng, chạy terraform plan để xem những gì sẽ thay đổi, rồi terraform apply để thực hiện. Terraform giữ một state file (cục bộ hoặc trong một backend như S3 bucket có DynamoDB locking) ánh xạ config của bạn tới các resource ID thực trong cloud provider.

Mạnh mẽ ở đây là dependency resolution trên các provider. Nếu bạn bảo Terraform tạo một security group và sau đó gắn nó vào một EC2 instance, nó tự động xác định thứ tự. Nó cũng hoạt động trên AWS, Azure, GCP, Cloudflare, Datadog, và hàng chục provider khác thông qua quy trình làm việc giống nhau, điều này quan trọng khi cơ sở hạ tầng của bạn kéo dài hơn một vendor.

Terraform không tốt trong bất kỳ điều gì xảy ra bên trong máy khi nó tồn tại. Nó không cài đặt package, chỉnh sửa file config, hoặc restart service theo bất kỳ cách có ý nghĩa nào. Provisioners như remote-exec tồn tại nhưng chính HashiCorp khuyến cáo tránh chúng cho bất kỳ điều gì ngoài bootstrapping.

Ansible thực sự dùng để làm gì

Ansible là một công cụ configuration management. Nó kết nối qua SSH (hoặc WinRM cho Windows) và chạy các task trên các máy đã tồn tại: cài đặt nginx, template một file config, tạo user, restart service, đảm bảo cron job hiện diện. Playbooks là YAML, và modules idempotent theo thiết kế, vì vậy chạy cùng một playbook hai lần không nên thay đổi gì lần thứ hai nếu hệ thống đã khớp trạng thái mong muốn.

Ansible không cần agents được cài trên target hosts, chỉ Python và SSH access, điều này giúp dễ dàng gắn vào cơ sở hạ tầng hiện tại. Nó cũng tốt trong các task orchestration không hoàn toàn là "provisioning" — rolling restarts trên một fleet, blue-green deploy steps, chạy database migration trên một host rồi cập nhật load balancer.

Chỗ chúng overlap và nơi mọi người bị nhầm lẫn

Cả hai công cụ về mặt kỹ thuật có thể làm một chút công việc của công cụ kia. Ansible có cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) có thể quay lên cơ sở hạ tầng. Terraform có provisioners có thể chạy shell commands trên một instance mới. Nhưng sử dụng Ansible cho provisioning có nghĩa là từ bỏ Terraform's state tracking và plan/diff workflow, và sử dụng Terraform provisioners cho configuration có nghĩa là từ bỏ idempotent, repeatable config management.

Phân chia thực tế mà hầu hết các team hạ cánh:

• Terraform xây dựng cơ sở hạ tầng: networks, compute instances, load balancers, managed databases, IAM roles.
• Ansible cấu hình những gì nằm trên đó: software installs, users, config files, service state, application deployment steps.

Một ví dụ cụ thể về handoff

Giả sử bạn đang thiết lập ba web servers phía sau một load balancer trên AWS.

resource "aws_instance" "web" {
  count         = 3
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  tags = { Name = "web-${count.index}" }
}

output "web_ips" {
  value = aws_instance.web[*].public_ip
}

Terraform tạo các instances và output IPs của chúng. Bạn có thể feed output đó vào một dynamic Ansible inventory (plugin amazon.aws.aws_ec2 đọc EC2 tags trực tiếp, không cần manual copy-paste) và rồi chạy:

ansible-playbook -i aws_ec2.yml site.yml

nơi site.yml cài đặt nginx, drop app config, và start service. Terraform không bao giờ chạm vào nginx. Ansible không bao giờ chạm vào VPC. Mỗi công cụ ở trong lane của nó, và mỗi có state/idempotency model riêng không xung đột với model của công cụ kia.

Sai lầm phổ biến nên tránh

Lưu trữ Terraform state trong git là sai lầm phổ biến nhất ban đầu — state files có thể chứa secrets ở plaintext và gây merge conflicts làm hỏng cơ sở hạ tầng model của bạn. Sử dụng một remote backend từ ngày đầu.

Với Ansible, sai lầm là viết playbooks không thực sự idempotent — sử dụng shell hoặc command modules cho những thứ có một proper module (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) đã handle logic check-then-act đúng.

Nếu bạn đang quyết định nên học cái nào trước: học Terraform nếu bạn đang làm cloud provisioning và multi-environment setups, học Ansible nếu bạn đang quản lý config drift trên các servers bạn đã có. Hầu hết DevOps roles mong đợi quen thuộc với cả hai trong năm đầu tiên.

Để tìm hiểu thêm về state management, dynamic inventories, và xây dựng một full CI/CD pipeline xung quanh những công cụ này, hãy kiểm tra các DevOps và Cloud segments liên quan trên Korra Studio.