Terraform vs. Ansible: Який з них вам насправді потрібен?

Люди, які новичкові в Infrastructure as Code, зазвичай ставлять це питання одним з двох способів: "який інструмент мені вчити першим" або "чому команди використовують обидва". Коротка відповідь: Terraform і Ansible вирішують різні проблеми, і більшість production-налаштувань використовують їх разом, а не вибирають один.

Що насправді робить Terraform

Terraform — це інструмент provisioning. Він описує, яка інфраструктура має існувати: VPC, три EC2 instances, RDS database, S3 bucket з конкретною policy. Ви пишете HCL, що описує кінцевий стан, запускаєте terraform plan, щоб побачити, що змінюватиметься, а потім terraform apply, щоб це зробити. Terraform тримає файл стану (локально або в backend типу S3 bucket з DynamoDB locking), який сопоставляє вашу конфігурацію з реальними ID ресурсів у хмарному провайдері.

Сила тут — це вирішення залежностей між провайдерами. Якщо ви скажете Terraform створити security group і потім приєднати його до EC2 instance, він автоматично визначить порядок. Це також працює на AWS, Azure, GCP, Cloudflare, Datadog та десятках інших провайдерів через той же workflow, що важливо, коли ваша інфраструктура охоплює більше одного продавця.

Terraform погано справляється з чим завгодно, що відбувається всередині машини після того, як вона існує. Він не встановлює пакети, не редагує файли конфігурації та не перезавантажує сервіси жодним значущим постійним способом. Provisioners як remote-exec існують, але сам HashiCorp рекомендує їх уникати для всього, крім bootstrap.

Що насправді робить Ansible

Ansible — це інструмент управління конфігурацією. Він з'єднується через SSH (або WinRM для Windows) і запускає завдання на машинах, які вже існують: встановити nginx, шаблонувати файл конфігурації, створити користувача, перезавантажити сервіс, забезпечити наявність cron job. Playbooks — це YAML, а модулі є idempotent за дизайном, тому запуск одного playbook двічі не повинен щось змінювати в другий раз, якщо система вже відповідає бажаному стану.

Ansible не потребує встановлення agents на цільових хостах, тільки Python і SSH доступ, що спрощує його додавання до існуючої інфраструктури. Це також добре для завдань оркестрування, які не є строго "provisioning" — rolling restarts по флоту, blue-green deploy кроки, запуск database migration на одному хості і потім оновлення load balancer.

Де вони накладаються і де людей заплутують

Оба інструменти технічно можуть робити трохи роботи один одного. Ansible має cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine), що можуть розгорнути інфраструктуру. Terraform має provisioners, що можуть запускати shell commands на новому instance. Але використання Ansible для provisioning означає відмову від Terraform state tracking і plan/diff workflow, а використання Terraform provisioners для конфігурації означає відмову від idempotent, повторюваного управління конфігурацією.

Практичний поділ, на якому зупиняються більшість команд:

• Terraform будує інфраструктуру: мережі, compute instances, load balancers, managed databases, IAM roles.
• Ansible конфігурує те, що на ній лежить: software installs, users, config files, service state, application deployment кроки.

Конкретний приклад передачі

Припустимо, ви налаштовуєте три web servers позаду load balancer на 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 створює instances і виводить їхні IPs. Ви можете передати цей output до динамічного Ansible inventory (плагін amazon.aws.aws_ec2 inventory читає EC2 tags напряму, без ручного copy-paste) і потім запустити:

ansible-playbook -i aws_ec2.yml site.yml

де site.yml встановлює nginx, кидає app config, і стартує сервіс. Terraform ніколи не торкається nginx. Ansible ніколи не торкається VPC. Кожен інструмент залишається в своїй смузі, і кожен має свою модель state/idempotency, яка не конфліктує з іншою.

Поширені помилки, яких варто уникати

Зберігання Terraform state в git — це найпоширеніша рання помилка — файли стану можуть містити secrets у простому текстові та викликати merge conflicts, які пошкоджують вашу модель інфраструктури. Використовуйте remote backend з першого дня.

З Ansible помилка полягає в написанні playbooks, які насправді не є idempotent — використання shell або command modules для речей, які мають правильний module (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd), що вже правильно обробляє логіку check-then-act.

Якщо ви вирішуєте, що вчити першим: вчіть Terraform, якщо ви робите cloud provisioning і multi-environment setups, вчіть Ansible, якщо ви управляєте config drift на серверах, які у вас вже є. Більшість DevOps ролей очікують знайомства з обома протягом першого року.

Для більшої інформації про state management, dynamic inventories, та побудову повного CI/CD pipeline навколо цих інструментів, перевірте пов'язані DevOps і Cloud сегменти на Korra Studio.