Automação de infraestrutura: Terraform, Ansible e Infrastructure as Code

Configurar uma máquina virtual manualmente, criar uma rede, definir regras de firewall, preparar armazenamento e instalar serviços pode funcionar quando o ambiente é pequeno. O problema começa quando essa mesma infraestrutura precisa ser reproduzida, modificada ou administrada em escala.

Um ambiente de desenvolvimento precisa manter características semelhantes às de produção. Novos servidores precisam seguir padrões já definidos. Mudanças precisam ser rastreadas. Recursos criados hoje precisam continuar compreensíveis meses depois, mesmo que outra pessoa assuma a operação.

É nesse ponto que a automação de infraestrutura deixa de representar apenas economia de tempo e passa a fazer parte da arquitetura do ambiente.

Com Infrastructure as Code (IaC), redes, máquinas virtuais, regras de segurança, balanceadores, bancos de dados e diversos outros componentes podem ser descritos em arquivos versionáveis. Em vez de depender exclusivamente de configurações executadas manualmente em consoles administrativos, parte da infraestrutura passa a ser definida como código.

Ferramentas como Terraform, AWS CloudFormation e Azure Bicep trabalham diretamente nesse modelo. Já Ansible, PowerShell, Python e VCF PowerCLI podem assumir outras etapas da automação, como configuração de sistemas, administração de plataformas e execução de tarefas operacionais.

O ponto central não é utilizar o maior número possível de ferramentas. É entender qual problema cada uma delas resolve dentro do ciclo de infraestrutura.

Infrastructure as Code muda a forma de administrar ambientes

Infrastructure as Code não significa simplesmente substituir cliques por scripts.

Em uma abordagem declarativa, descrevemos o estado que esperamos encontrar no ambiente. A ferramenta compara essa definição com a infraestrutura existente e determina quais operações precisam ser realizadas para alcançar o estado desejado.

Esse modelo aparece claramente no Terraform, no AWS CloudFormation e no Azure Bicep.

Isso traz uma mudança importante para a operação.

Uma infraestrutura que antes existia apenas dentro de AWS, Azure, VMware ou outro console administrativo passa a ter também uma representação em arquivos que podem ser armazenados em Git, revisados e reutilizados.

A mudança deixa de ser somente:

“alguém alterou alguma coisa no ambiente”.

Ela pode passar a ser:

“este código representa a alteração proposta, este foi o impacto previsto e este é o histórico da mudança”.

Essa rastreabilidade é uma das principais diferenças entre simplesmente automatizar comandos e construir uma estratégia de infraestrutura como código.

Terraform e o provisionamento declarativo

O Terraform utiliza uma linguagem declarativa chamada HCL e trabalha com providers para interagir com diferentes plataformas.

Um provider disponibiliza os recursos que aquela plataforma permite administrar. Existem providers para AWS, Azure, VMware vSphere, Kubernetes, serviços SaaS e diversas outras tecnologias.

A partir deles, uma configuração pode descrever recursos como VPCs, VNets, subnets, máquinas virtuais, security groups, discos, balanceadores, bancos de dados e outros componentes.

O fluxo básico também introduz uma etapa importante de validação antes da mudança.

terraform init → terraform validate → terraform plan → revisão → terraform apply

O terraform init prepara o diretório e os providers necessários.

O terraform validate verifica a consistência da configuração.

O terraform plan calcula quais alterações seriam necessárias para aproximar a infraestrutura do estado definido pelo código.

Somente depois o terraform apply executa essas mudanças.

Esse processo é relevante porque permite avaliar antecipadamente operações como criação, alteração e remoção de recursos.

Em infraestrutura, saber o que será alterado antes da execução pode ser tão importante quanto automatizar a própria alteração.

O state é uma parte crítica do Terraform

Terraform precisa relacionar aquilo que foi declarado no código com os recursos existentes na infraestrutura.

Para isso existe o state.

Em ambientes simples, esse estado pode ser armazenado localmente no arquivo terraform.tfstate. Em equipes e ambientes corporativos, porém, deixar o state apenas na estação de um administrador cria problemas de colaboração, segurança e consistência.

Por isso, arquiteturas mais maduras normalmente utilizam remote state.

O armazenamento centralizado permite que diferentes execuções trabalhem com uma referência comum. Dependendo do backend utilizado, também podem existir mecanismos de locking para impedir que duas operações modifiquem o mesmo estado simultaneamente.

Esse cuidado é importante porque uma automação concorrente ou um state inconsistente pode resultar em alterações inesperadas.

Também existe uma questão de segurança: dependendo dos recursos utilizados, o state pode armazenar informações sensíveis.

Por isso ele precisa ser tratado como parte da infraestrutura e não simplesmente como um arquivo descartável gerado pelo Terraform.

Módulos ajudam a transformar código em padrão

Quando diferentes projetos começam a repetir as mesmas estruturas de Terraform, surge outro problema: duplicação.

É aí que entram os modules.

Um módulo pode encapsular um conjunto de recursos relacionados e expor apenas as variáveis necessárias para sua utilização.

Uma empresa pode, por exemplo, criar um padrão para uma aplicação contendo rede, security groups, instâncias, balanceador e outras dependências.

Em vez de recriar toda essa arquitetura em cada projeto, o módulo pode ser reutilizado com parâmetros diferentes para desenvolvimento, homologação ou produção.

Essa abordagem aproxima infraestrutura de práticas tradicionais de engenharia de software: reutilização, abstração, versionamento e revisão.

O benefício não está apenas em escrever menos código.

Está em reduzir diferenças desnecessárias entre ambientes e transformar decisões arquiteturais em componentes reutilizáveis.

AWS CloudFormation e a automação nativa da AWS

No ecossistema AWS, o CloudFormation oferece uma abordagem nativa de Infrastructure as Code.

Os recursos são descritos em templates e implantados utilizando stacks.

Uma stack pode representar um conjunto relacionado de componentes da infraestrutura: VPC, subnets, instâncias EC2, security groups, balanceadores, bancos de dados e outros recursos.

Um mecanismo particularmente importante são os Change Sets.

Antes de aplicar uma atualização em uma stack existente, é possível visualizar as alterações que o CloudFormation pretende executar.

Isso permite identificar previamente recursos que serão adicionados, alterados ou removidos.

Embora Terraform Plan e CloudFormation Change Sets tenham implementações diferentes, ambos introduzem uma prática importante:

avaliar o impacto da mudança antes de modificar a infraestrutura.

Azure Bicep e a infraestrutura como código no Azure

No Azure, a Microsoft oferece os tradicionais ARM Templates e o Bicep.

Bicep fornece uma linguagem declarativa específica para Azure Resource Manager e reduz significativamente a verbosidade encontrada nos templates ARM escritos diretamente em JSON.

Com ele é possível definir resource groups, redes virtuais, subnets, NSGs, máquinas virtuais, storage accounts e praticamente todo o conjunto de recursos disponibilizados pelo Azure Resource Manager.

Outra funcionalidade relevante é o what-if, que permite visualizar o impacto esperado de uma implantação antes de executá-la.

Terraform também pode administrar Azure através de seus providers.

Por isso, a escolha entre Terraform e Bicep não precisa ser tratada como uma disputa absoluta.

Uma organização fortemente concentrada em Azure pode aproveitar a integração nativa do Bicep. Já ambientes híbridos ou multicloud podem encontrar no Terraform uma camada comum para diferentes provedores.

Arquitetura, governança e experiência da equipe devem fazer parte dessa decisão.

VMware também pode fazer parte da automação

Automação de infraestrutura não pertence apenas à nuvem pública.

Datacenters baseados em VMware também podem ser integrados a processos de automação.

O provider VMware vSphere para Terraform permite trabalhar com diferentes componentes do ambiente e automatizar o provisionamento de máquinas virtuais e outros recursos administrados pelo vCenter.

Outra ferramenta importante nesse ecossistema é o VCF PowerCLI, baseado em PowerShell.

PowerCLI possui uma longa presença em ambientes VMware e permite automatizar tarefas relacionadas a VMs, hosts, clusters, datastores, redes e diversos outros componentes da plataforma.

Isso cria possibilidades interessantes em ambientes híbridos.

Terraform pode provisionar recursos no VMware e também em cloud pública, enquanto PowerCLI pode ser utilizado para operações específicas do ecossistema VMware.

Depois que a máquina virtual existe, outra camada de automação pode assumir sua configuração.

É aí que ferramentas como Ansible ganham importância.

Ansible resolve outra parte do problema

Terraform e Ansible aparecem frequentemente juntos, mas não precisam exercer exatamente a mesma função.

Terraform é muito utilizado para provisionar infraestrutura.

Ansible possui forte presença em configuration management, orquestração e automação operacional.

Imagine uma VM Linux recém-criada.

Terraform pode ter definido a máquina, sua rede, disco, endereço e regras de segurança.

Ansible pode então acessar esse servidor e garantir que determinados pacotes estejam instalados, usuários existam, arquivos de configuração possuam o conteúdo correto e serviços estejam iniciados.

Os inventories identificam hosts e grupos.

Os playbooks descrevem as tarefas.

Os modules realizam operações nos sistemas.

As roles ajudam a organizar tarefas, templates, handlers, arquivos e variáveis em estruturas reutilizáveis.

Ansible também trabalha com o conceito de idempotência em muitos de seus módulos: se o ambiente já possui o estado desejado, uma nova execução não precisa necessariamente repetir a alteração.

Isso é particularmente importante em automação.

Executar novamente um processo deveria aproximar o sistema do estado esperado, e não gerar configurações duplicadas ou resultados imprevisíveis.

Puppet e Chef também fazem parte desse ecossistema

Ansible não é a única ferramenta utilizada para gerenciamento de configuração. Puppet e Chef também tiveram papel importante na automação de servidores em larga escala e continuam presentes em ambientes corporativos.

Puppet trabalha com uma abordagem declarativa, definindo o estado esperado dos recursos administrados. Chef utiliza conceitos como recipes e cookbooks para organizar configurações e tarefas de automação.

Na prática, essas ferramentas ocupam um espaço semelhante ao Ansible dentro do gerenciamento de configuração, embora adotem arquiteturas e modelos operacionais diferentes.

Em ambientes atuais, Ansible aparece com bastante frequência por sua simplicidade de adoção e por permitir muitos cenários sem agentes permanentes nos hosts. Puppet e Chef, porém, continuam relevantes principalmente em infraestruturas onde já existe uma base consolidada dessas tecnologias.

O mais importante é separar os papéis:

Terraform, CloudFormation e Bicep atuam fortemente no provisionamento de infraestrutura.

Ansible, Puppet e Chef atuam principalmente na configuração e manutenção dos sistemas.

Automação também chega aos equipamentos de rede

Ansible não está restrito a servidores.

Existe um ecossistema específico para network automation, permitindo administrar diferentes plataformas de switches, roteadores, firewalls e outros equipamentos através de collections e módulos específicos.

Nesse cenário, configurações que anteriormente poderiam depender exclusivamente de acesso manual por SSH ou interfaces web podem fazer parte de processos estruturados de automação.

Isso não elimina a necessidade de compreender redes.

Na verdade, aumenta a importância desse conhecimento.

Quando uma alteração manual está errada, normalmente afeta aquilo que o administrador modificou.

Quando uma automação está errada, ela pode reproduzir o mesmo erro rapidamente em dezenas ou centenas de dispositivos.

Git transforma infraestrutura em processo de mudança

Um dos maiores ganhos aparece quando o código de infraestrutura passa a ser armazenado em Git.

Cada alteração pode gerar um commit.

Mudanças maiores podem passar por branches.

Pull Requests permitem revisão.

O histórico mostra quando determinada configuração foi alterada e por quem.

Isso cria uma sequência muito diferente de simplesmente acessar um console administrativo e modificar recursos diretamente:

Código → Git → Pull Request → validação → revisão → aprovação → implantação

Essa abordagem também prepara o caminho para CI/CD aplicado à infraestrutura.

CI/CD não serve apenas para aplicações

Ferramentas como GitHub Actions, GitLab CI, Jenkins e Azure DevOps podem executar processos de infraestrutura.

Uma mudança em Terraform, por exemplo, pode disparar automaticamente validações e gerar um terraform plan.

A equipe revisa o plano.

Depois da aprovação, outra etapa pode executar a implantação.

O mesmo princípio pode ser aplicado a CloudFormation, Bicep, Ansible e outras tecnologias.

Uma pipeline pode realizar verificações antes de permitir uma alteração em produção e executar validações depois do deployment.

Isso reduz a dependência de comandos executados manualmente em uma estação administrativa.

Mais importante: cria um processo reproduzível.

Drift mostra quando código e realidade deixam de representar a mesma coisa

Mesmo depois de adotar Infrastructure as Code, ainda existe um problema importante.

Alguém pode entrar no console e fazer uma alteração manual.

Uma regra de firewall pode ser modificada.

A capacidade de uma VM pode ser alterada.

Um recurso pode ser criado fora do código.

Quando a infraestrutura real começa a divergir da configuração esperada, ocorre configuration drift.

Isso é importante porque uma das premissas da infraestrutura como código é que a definição versionada represente o ambiente.

Se mudanças paralelas acontecem constantemente fora desse processo, o código deixa de ser uma referência confiável.

Por isso, organizações que amadurecem no uso de IaC normalmente também estabelecem regras sobre como alterações devem chegar ao ambiente.

Automação precisa considerar segurança desde o início

Uma pipeline de infraestrutura pode possuir privilégios para criar máquinas, alterar redes, modificar políticas e até remover recursos.

Portanto, sua capacidade de causar impacto também é significativa.

Credenciais não deveriam ser armazenadas diretamente em arquivos Terraform, playbooks ou repositórios Git.

IAM, segregação de funções, secrets management, revisão de código, logs de auditoria e controle de permissões precisam fazer parte da arquitetura.

Serviços como AWS Secrets Manager, Azure Key Vault e ferramentas especializadas de gerenciamento de secrets podem ser integrados ao processo.

Também existem ferramentas capazes de analisar arquivos IaC em busca de configurações inseguras antes que a infraestrutura seja implantada.

O objetivo não é transformar toda mudança em um processo burocrático.

É permitir velocidade sem eliminar controle.

Ferramentas diferentes podem fazer parte da mesma arquitetura

Uma estratégia madura não precisa escolher uma única tecnologia para resolver todos os problemas.

Terraform pode provisionar recursos em AWS, Azure e VMware.

CloudFormation pode administrar componentes profundamente integrados ao ecossistema AWS.

Bicep pode assumir recursos nativos do Azure.

VCF PowerCLI pode automatizar atividades específicas do VMware.

Ansible pode configurar sistemas operacionais, aplicações e equipamentos de rede.

PowerShell, Python e Bash continuam extremamente relevantes quando automações específicas precisam conversar com APIs, sistemas operacionais ou plataformas existentes.

Outras tecnologias também aparecem nesse ecossistema.

OpenTofu segue uma abordagem de IaC compatível com grande parte do ecossistema Terraform.

Pulumi permite definir infraestrutura utilizando linguagens de programação.

Terragrunt adiciona mecanismos para organizar e reutilizar configurações Terraform em determinados cenários.

Packer automatiza a construção de imagens.

Crossplane aproxima gerenciamento de infraestrutura do modelo declarativo do Kubernetes.

Em ambientes Kubernetes, ferramentas como Helm, Kustomize, Argo CD e Flux introduzem outras formas de automatizar configuração e deployment.

Cada uma resolve um problema específico.

O importante é não transformar arquitetura em uma coleção de ferramentas sem propósito definido.

Automação não termina quando o deployment termina

Uma pipeline pode informar que o deployment foi concluído com sucesso e o serviço continuar apresentando problemas.

Uma máquina virtual pode ter sido criada corretamente, mas sua aplicação não responder.

Uma nova configuração pode aumentar latência.

Uma alteração de rede pode produzir perda de pacotes.

Um serviço pode iniciar e falhar minutos depois.

É aqui que automação e monitoramento começam a se encontrar.

Provisionamento responde:

A infraestrutura foi criada?

Configuration management responde:

Ela foi configurada corretamente?

Monitoramento responde:

Ela continua funcionando dentro do comportamento esperado?

Uma arquitetura madura pode integrar essas etapas.

Depois do deployment, verificações automatizadas podem validar endpoints, disponibilidade de serviços e outros sinais antes que a mudança seja considerada concluída.

Esse processo conecta Infrastructure as Code diretamente à operação.

O valor da automação está na repetibilidade

Automação de infraestrutura não deveria ser medida apenas pela quantidade de cliques ou comandos manuais que foram eliminados.

O ganho mais importante aparece quando um ambiente pode ser reconstruído de forma previsível, uma mudança pode ser analisada antes da execução e diferentes ambientes conseguem seguir padrões conhecidos.

Infrastructure as Code também reduz a dependência do conhecimento individual.

A arquitetura deixa de existir exclusivamente na memória do profissional que configurou determinado ambiente.

Parte desse conhecimento passa a existir em código, documentação, histórico de Git, módulos, pipelines e processos reproduzíveis.

Terraform, CloudFormation, Bicep, Ansible, PowerCLI e outras tecnologias resolvem diferentes partes dessa jornada.

A maturidade não está em utilizar todas elas.

Está em construir um processo no qual infraestrutura, configuração e mudanças sejam previsíveis, rastreáveis e reproduzíveis.