Terraform vs. Ansible: Qual você realmente precisa?

Pessoas novas em Infrastructure as Code geralmente fazem essa pergunta de uma de duas formas: "qual ferramenta devo aprender primeiro" ou "por que times usam as duas." A resposta rápida é que Terraform e Ansible resolvem problemas diferentes, e a maioria das configurações de produção usa as duas juntas em vez de escolher uma.

Para o que Terraform é realmente

Terraform é uma ferramenta de provisioning. Declara que infraestrutura deve existir: uma VPC, três instâncias EC2, um banco de dados RDS, um bucket S3 com uma política específica. Você escreve HCL descrevendo o estado final, executa terraform plan para ver o que vai mudar, depois terraform apply para fazer acontecer. Terraform mantém um arquivo de estado (localmente ou em um backend como um bucket S3 com DynamoDB locking) que mapeia sua configuração para IDs de recurso reais no provedor de nuvem.

O ponto forte aqui é a resolução de dependências entre provedores. Se você disser ao Terraform para criar um security group e depois anexá-lo a uma instância EC2, ele descobre a ordem automaticamente. Também funciona em AWS, Azure, GCP, Cloudflare, Datadog e dezenas de outros provedores pelo mesmo workflow, o que importa quando sua infraestrutura abrange mais de um vendedor.

Terraform é ruim em tudo que acontece dentro da máquina quando ela existe. Não instala pacotes, edita arquivos de config ou reinicia serviços de forma contínua significativa. Provisioners como remote-exec existem mas a própria HashiCorp recomenda evitá-los para qualquer coisa além de bootstrap.

Para o que Ansible é realmente

Ansible é uma ferramenta de configuration management. Conecta via SSH (ou WinRM para Windows) e executa tarefas em máquinas que já existem: instalar nginx, templatar um arquivo de config, criar um usuário, reiniciar um serviço, garantir que um cron job esteja presente. Playbooks são YAML, e módulos são idempotentes por design, então executar o mesmo playbook duas vezes não deve mudar nada na segunda vez se o sistema já corresponde ao estado desejado.

Ansible não precisa de agentes instalados nos hosts alvo, apenas Python e acesso SSH, o que torna fácil anexar em infraestrutura existente. Também é bom em tarefas de orquestração que não são estritamente "provisioning" — reinicializações rolling em uma frota, passos de deploy azul-verde, executar uma migração de banco de dados em um host e depois atualizar um load balancer.

Onde se sobrepõem e onde as pessoas ficam confusas

Ambas as ferramentas podem tecnicamente fazer um pouco do trabalho uma da outra. Ansible tem módulos de nuvem (amazon.aws.ec2_instance, azure.azcollection.azure_rm_virtualmachine) que podem criar infraestrutura. Terraform tem provisioners que podem executar comandos shell em uma nova instância. Mas usar Ansible para provisioning significa abrir mão do rastreamento de estado do Terraform e do workflow plan/diff, e usar Terraform provisioners para configuração significa abrir mão de configuration management idempotente e repetível.

A divisão prática em que a maioria dos times acaba:

• Terraform constrói a infraestrutura: redes, instâncias compute, load balancers, bancos de dados gerenciados, papéis IAM.
• Ansible configura o que fica em cima: installs de software, usuários, arquivos de config, estado de serviço, passos de deploy de aplicação.

Um exemplo concreto do handoff

Digamos que você está levantando três web servers atrás de um load balancer em 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 cria as instâncias e retorna seus IPs. Você pode alimentar esse output em um inventário Ansible dinâmico (o plugin de inventário amazon.aws.aws_ec2 lê tags EC2 direto, sem necessidade de copiar manualmente) e depois executar:

ansible-playbook -i aws_ec2.yml site.yml

onde site.yml instala nginx, coloca o app config, e inicia o serviço. Terraform nunca toca em nginx. Ansible nunca toca na VPC. Cada ferramenta fica em sua área, e cada uma tem seu próprio modelo de estado/idempotência que não entra em conflito com o da outra.

Erros comuns que valem a pena evitar

Armazenar state do Terraform em git é o erro inicial mais comum — arquivos de estado podem conter secrets em plaintext e causar merge conflicts que corrompem seu modelo de infraestrutura. Use um remote backend desde o início.

Com Ansible, o erro é escrever playbooks que não são realmente idempotentes — usando módulos shell ou command para coisas que têm um módulo apropriado (ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd) que já lida com a lógica check-then-act corretamente.

Se está decidindo o que aprender primeiro: aprenda Terraform se está fazendo provisioning de nuvem e setups multi-ambiente, aprenda Ansible se está gerenciando config drift em servidores que você já tem. A maioria dos papéis DevOps espera familiaridade com ambas dentro do primeiro ano.

Para mais sobre state management, inventários dinâmicos e construir um pipeline CI/CD completo ao redor dessas ferramentas, confira os segmentos relacionados DevOps e Cloud no Korra Studio.