Terraform vs. Ansible: какой инструмент вам действительно нужен?

Люди, новичков в Infrastructure as Code, обычно спрашивают об этом одним из двух способов: «какой инструмент мне учить первым» или «почему команды используют оба». Коротко говоря, Terraform и Ansible решают разные задачи, и большинство production setups используют их вместе, а не выбирают один.

Для чего Terraform действительно нужен

Terraform — инструмент provisioning. Он объявляет, какая инфраструктура должна существовать: VPC, три EC2 instance, база данных RDS, S3 bucket с определённой политикой. Вы пишете HCL, описывающий конечное состояние, запускаете terraform plan, чтобы увидеть, что изменится, потом terraform apply, чтобы это произошло. Terraform хранит state file (локально или в backend типа S3 bucket с DynamoDB locking), который связывает вашу конфигурацию с реальными ID ресурсов у облачного провайдера.

Сильная сторона здесь — разрешение зависимостей между провайдерами. Если вы скажете Terraform создать security group и затем прикрепить его к EC2 instance, он сам определит порядок. Он также работает с AWS, Azure, GCP, Cloudflare, Datadog и десятками других провайдеров через один и тот же workflow, что важно, когда ваша инфраструктура охватывает больше одного vendor.

Terraform плохо справляется с тем, что происходит внутри машины после её создания. Он не устанавливает пакеты, не редактирует конфиги, не перезагружает сервисы в каком-то постоянном режиме. Provisioners типа remote-exec существуют, но сама HashiCorp рекомендует их избегать для чего-либо, кроме bootstrapping.

Для чего Ansible действительно нужен

Ansible — инструмент configuration management. Он подключается по SSH (или WinRM для Windows) и запускает tasks на машинах, которые уже существуют: установить nginx, подставить config file, создать пользователя, перезагрузить сервис, убедиться, что cron job присутствует. Playbooks — это YAML, и modules спроектированы как idempotent, поэтому запуск одного playbook дважды не должен ничего менять со второго раза, если система уже соответствует нужному состоянию.

Ansible не требует установки агентов на целевых хостах, только Python и доступ по SSH, что упрощает добавление к существующей инфраструктуре. Он также хорош для orchestration tasks, которые не совсем «provisioning» — rolling restarts по флоту, blue-green deploy шаги, миграция базы данных на одном хосте и потом обновление load balancer.

Где они пересекаются и почему возникает путаница

Оба инструмента технически могут делать часть работы другого. Ansible имеет cloud modules (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine), которые могут поднять инфраструктуру. Terraform имеет provisioners, которые могут запустить shell команды на новом instance. Но использовать Ansible для provisioning означает потерять state tracking и plan/diff workflow Terraform, а использовать Terraform provisioners для configuration означает потерять idempotent, повторяемый configuration management.

Практическое разделение, на которое приходят большинство команд:

• Terraform строит инфраструктуру: сети, compute instances, load balancers, managed databases, IAM roles.
• Ansible конфигурирует, что на этом: software installs, пользователи, config files, service state, application deployment steps.

Конкретный пример handoff

Представьте, вы ставите три web server за 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 (inventory plugin amazon.aws.aws_ec2 читает EC2 tags напрямую, без ручного copy-paste) и затем запустить:

ansible-playbook -i aws_ec2.yml site.yml

где site.yml устанавливает nginx, кладёт config приложения и запускает сервис. Terraform не трогает nginx. Ansible не трогает VPC. Каждый инструмент остаётся в своём lane, и каждый имеет свой state/idempotency model, который не конфликтует с другим.

Распространённые ошибки, которых стоит избежать

Хранение Terraform state в git — самая частая ошибка новичков — state files могут содержать secrets в открытом виде и вызывать merge conflicts, которые портят вашу infrastructure model. Используйте 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 segments на Korra Studio.