Terraform: o que é e exemplos com Hyper-V e Proxmox

Provisionar servidores manualmente, clicar em painéis de cloud e abrir tickets para cada nova VM é um modelo que não escala. Equipes de TI que ainda dependem desse fluxo convivem com drift de configuração, ambientes inconsistentes e dias inteiros perdidos em tarefas repetitivas que poderiam virar código versionado.

Terraform é a ferramenta open-source da HashiCorp que transforma essa rotina em infraestrutura como código. Em vez de operar manualmente cada provedor, você descreve o estado desejado em arquivos declarativos e deixa o Terraform calcular o caminho até lá. Funciona em AWS, Azure, GCP e, com providers community-maintained, também em hypervisors on-premise como Hyper-V em ambientes corporativos e Proxmox.

Este guia cobre o que é Terraform, o ciclo init/plan/apply, State File, módulos e boas práticas para produção. Inclui também dois exemplos práticos com HCL real para Hyper-V e Proxmox. Por fim, mostra como conectar a infraestrutura provisionada à camada de observabilidade que toda operação séria precisa.

O que é Terraform

Terraform é uma ferramenta declarativa de provisionamento de infraestrutura criada pela HashiCorp em 2014. Ela descreve recursos computacionais em arquivos .tf escritos em HCL (HashiCorp Configuration Language). Em seguida, aplica essa descrição em mais de 3.000 providers diferentes, da AWS ao Kubernetes, do GitHub ao Datadog. A documentação oficial da HashiCorp mantém o catálogo completo e referências de sintaxe atualizadas.

A proposta central é separar o que você quer do como chegar lá. Você declara “preciso de três VMs com 8 vCPUs e 16 GB de RAM” e o Terraform compara esse desejo com o estado atual da infraestrutura. Em seguida, calcula o delta e executa apenas as operações necessárias para convergir.

Esse modelo declarativo difere de scripts imperativos tradicionais. Bash, PowerShell ou mesmo Python descrevem passo a passo o que executar. O Terraform descreve o resultado e deixa a engine resolver a sequência. Por isso a comunidade classifica a categoria como IaC declarativa, em oposição à IaC procedural.

A natureza idempotente é outro diferencial. Rodar terraform apply cem vezes seguidas em uma configuração estável não cria cem ambientes: produz exatamente o estado declarado, sem efeitos colaterais. Como resultado, a ferramenta vira a fonte única de verdade da infraestrutura e elimina o drift entre o que está escrito e o que existe em produção.

Como funciona Terraform na prática (init, plan e apply)

O ciclo de trabalho do Terraform gira em torno de três comandos principais. Cada um cumpre uma fase específica e o conjunto forma o loop que toda equipe de DevOps repete dezenas de vezes por dia em ambientes maduros.

O terraform init é o ponto de partida. Ele lê o bloco required_providers, baixa os plugins necessários para a pasta .terraform/ e configura o backend de state remoto, se houver. Você roda esse comando uma vez por projeto e depois somente quando muda um provider ou adiciona um novo módulo.

Em seguida vem o terraform plan. Esse comando lê os arquivos .tf, compara o estado declarado com o state file atual e gera um diff legível: o famoso plano de execução. Nada é alterado na infraestrutura. O plan é a oportunidade de revisar mudanças antes de executá-las, ideal para code review e integração com pipelines de CI.

Por fim, terraform apply executa o plano aprovado. Ele cria, atualiza ou destrói recursos exatamente como descrito, registra o resultado no state file e devolve o controle. Quando algo dá errado no meio do caminho, o state preserva o progresso parcial e permite retomar de onde parou. Vale destacar que terraform destroy é o quarto comando relevante, usado para remover toda a infraestrutura gerenciada por aquele state.

State File: o coração do Terraform

O state file (terraform.tfstate) é um arquivo JSON que mapeia cada recurso declarado para o ID real no provider. Sem ele, o Terraform não saberia que aquela VM no Azure com ID vm-12345 corresponde à azurerm_virtual_machine.web do seu código. Por isso, perder o state significa perder o controle sobre a infraestrutura.

Em projetos individuais, o state vive localmente. Em times, isso vira problema rapidamente. Dois engenheiros rodando apply simultaneamente em estados desincronizados causam corrupção, recursos duplicados e horas de troubleshooting. A solução é o backend remoto.

Backends remotos como AWS S3, Azure Blob Storage, Google Cloud Storage ou Terraform Cloud guardam o state em local centralizado e oferecem state locking. O locking impede execuções concorrentes: quando alguém roda apply, o backend trava o arquivo até a operação terminar. DynamoDB é o serviço clássico de locking quando o backend é S3, mas Terraform Cloud e os backends nativos de Azure/GCP fazem isso sem dependência extra.

Outra prática crítica é nunca commitar terraform.tfstate no Git. O arquivo contém valores sensíveis em texto claro, incluindo senhas, tokens e chaves privadas geradas pelo Terraform. Em vez disso, configure o backend remoto desde o primeiro init e adicione .terraform/ e *.tfstate* ao .gitignore.

Módulos: reutilizando configurações em times

Um módulo Terraform é uma pasta com arquivos .tf que encapsulam um conjunto de recursos relacionados. Você passa variáveis de entrada, ele cria a infraestrutura e devolve outputs que outros módulos consomem. É o equivalente a uma função em programação tradicional, com a vantagem de ser declarativo e versionado em Git.

Em equipes médias, módulos transformam radicalmente a produtividade. Em vez de cada squad escrever do zero a stack de rede, balanceador e VMs, um módulo vpc-padrao oferece a topologia certificada pela equipe de plataforma. Outra equipe consome esse módulo apontando para a tag v2.1.0 no Git e ganha consistência sem perder autonomia.

O Terraform Registry público hospeda milhares de módulos prontos para AWS, Azure, GCP, Kubernetes e até para providers community como Proxmox. Cada módulo declara variáveis, outputs e a versão mínima de Terraform necessária. Antes de escrever um módulo próprio, vale conferir se já existe um maduro no Registry que cubra o caso de uso.

Para times grandes, a convenção mais adotada é manter um repositório dedicado por módulo, com semantic versioning e CI rodando terraform validate em cada PR. A documentação fica gerada automaticamente por ferramentas como terraform-docs. Esse pipeline garante que mudanças em módulos compartilhados não quebrem dezenas de stacks downstream.

Exemplo prático: provisionando VMs no Hyper-V com Terraform

A grande maioria dos tutoriais brasileiros de Terraform foca em AWS, Azure ou GCP. Porém, muitas operações de TI no Brasil rodam workloads críticos em Hyper-V on-premise, especialmente em organizações financeiras, governo e indústria. O provider community taliesins/hyperv permite gerenciar essas máquinas com o mesmo workflow declarativo.

O snippet abaixo declara o provider, define a conexão WinRM com o host Hyper-V e cria uma VM Linux de exemplo. Em ambientes reais, você combinaria esse recurso com módulos que orquestram switches virtuais, discos VHDX e clusters de virtualização em alta disponibilidade.

# Provider community-maintained para Hyper-V via WinRM
terraform {
  required_providers {
    hyperv = {
      source  = "taliesins/hyperv"
      version = "1.2.1"
    }
  }
}

provider "hyperv" {
  user     = "Administrator"
  password = var.hyperv_password
  host     = "hv-host01.exemplo.local"
  port     = 5986
  https    = true
  insecure = false
}

resource "hyperv_machine_instance" "web01" {
  name                   = "vm-web01"
  generation             = 2
  processor_count        = 4
  static_memory          = true
  memory_startup_bytes   = 8589934592
  automatic_start_action = "StartIfRunning"
}

Esse provider conversa com o Hyper-V via WinRM sobre HTTPS, então o host precisa ter WinRM habilitado e um certificado válido. Em produção, prefira armazenar hyperv_password em um secret backend como Vault ou Azure Key Vault em vez de variável de ambiente local. Como o taliesins/hyperv é community-maintained, fixe a versão no required_providers e revise o .terraform.lock.hcl antes de cada release.

Exemplo prático: provisionando VMs no Proxmox com Terraform

Proxmox VE virou a alternativa open-source padrão para virtualização KVM em organizações que querem fugir do licenciamento VMware. O provider mais ativo hoje é o bpg/proxmox, que cobre VMs QEMU, containers LXC, storage, redes e users. Conforme a documentação do provider bpg/proxmox no Registry, a integração usa a API REST oficial do Proxmox e suporta API tokens em vez de credenciais root.

O exemplo a seguir define o provider, autentica com API token e provisiona uma VM Ubuntu 24.04 a partir de um template clonado. Esse padrão é a base para automatizar a expansão de ciclo de vida de máquinas virtuais em clusters Proxmox sem depender da interface web.

# Provider bpg/proxmox via API REST + API token
terraform {
  required_providers {
    proxmox = {
      source  = "bpg/proxmox"
      version = "0.66.2"
    }
  }
}

provider "proxmox" {
  endpoint  = "https://pve01.exemplo.local:8006/"
  api_token = var.proxmox_api_token
  insecure  = false
}

resource "proxmox_virtual_environment_vm" "app01" {
  name      = "vm-app01"
  node_name = "pve01"

  clone {
    vm_id = 9000
    full  = true
  }

  cpu {
    cores = 4
    type  = "host"
  }

  memory {
    dedicated = 8192
  }
}

A VM ID 9000 referenciada no bloco clone representa um template prévio com cloud-init pré-configurado. Esse padrão acelera o provisionamento porque evita reinstalar o sistema do zero a cada apply. Em virtualização de servidores com Proxmox, a combinação template + cloud-init + Terraform reduz para minutos um processo que tradicionalmente levava horas em fluxos manuais.

Terraform vs Ansible: provisionamento ou configuração?

Uma dúvida recorrente em equipes que adotam IaC é se Terraform substitui Ansible. A resposta curta é não. As duas ferramentas resolvem problemas diferentes do ciclo de vida da infraestrutura e funcionam melhor em conjunto.

Terraform é especialista em provisionamento: cria, modifica e destrói recursos no provider. Ele entrega uma VM, uma VPC ou um cluster Kubernetes, mas não configura o software interno dessas máquinas. O Ansible para configuração de servidores entra exatamente nesse ponto, instalando pacotes, ajustando arquivos de configuração e garantindo o estado dos serviços rodando dentro do sistema operacional.

O fluxo combinado mais comum tem três etapas. Terraform provisiona a infra no Day 0; Ansible configura o sistema operacional e aplicações no Day 1; ferramentas de monitoração assumem o Day 2 em diante. Equipes com cultura DevOps madura orquestram essa cadeia em pipelines únicos, onde o output do Terraform vira o inventory dinâmico do Ansible.

Boas práticas para ambientes produtivos

Mover Terraform do laptop do desenvolvedor para produção exige disciplina. As práticas a seguir são consenso entre equipes que operam centenas de stacks em escala e evitam os erros mais caros do ecossistema.

Primeiro, separe estados por ambiente. Cada ambiente (dev, staging, produção) deve ter seu próprio state file em backend remoto isolado. Isso evita que um apply errado em dev destrua recursos em produção. Use workspaces apenas para variações pequenas dentro do mesmo ambiente.

Segundo, fixe versões de tudo. Declare required_version no bloco terraform, fixe a versão de cada provider em required_providers e commite o .terraform.lock.hcl. Sem essas amarras, um novo membro do time pode aplicar uma versão diferente do provider e gerar drift sem perceber.

Terceiro, padronize o fluxo via CI. Cada PR roda terraform fmt -check, terraform validate, terraform plan e publica o plano como comentário no PR. O apply só roda após aprovação humana e merge na branch principal. Esse padrão elimina aplicações inadvertidas e cria trilha de auditoria automática.

Por fim, trate segredos com seriedade. Nunca hardcode tokens, senhas ou chaves em .tf. Use variáveis sem default declaradas como sensitive = true e injete os valores via secret manager. Vault, AWS Secrets Manager, Azure Key Vault ou variáveis de ambiente do runner de CI são as opções padrão. Combine isso com revisões de PR obrigatórias para mudanças em produção. Como resultado, você terá uma operação de automação de TI auditável.

Monitoramento da infraestrutura provisionada com Terraform

Terraform entrega a infraestrutura, mas não entrega visibilidade. Uma VM criada por apply pode estar rodando degradada, com disco cheio ou serviço travado e o state file continuará reportando tudo “ok”. É por isso que IaC sem monitoração contínua é apenas metade da equação.

A ponte natural entre os dois mundos é transformar o apply em um trigger de inventário no monitoramento de TI proativo. Quando uma nova VM nasce no Hyper-V ou no Proxmox, o pipeline registra automaticamente o host na plataforma de observabilidade. Em seguida, aplica o template de checks adequado e começa a coletar métricas em segundos. Sem essa automação, cada nova VM é uma cegueira potencial.

A plataforma OpMon consome a saída do Terraform via API e cadastra os hosts recém-criados sem intervenção manual. Métricas de CPU, memória, disco e serviços críticos passam a ser coletadas no mesmo ciclo em que a infraestrutura sobe. Quando uma VM é destruída por terraform destroy, o host é desativado automaticamente, eliminando alertas órfãos que poluem o painel da equipe de operações.

Essa integração resolve um problema real. Equipes que adotam IaC sem revisar a camada de monitoração frequentemente operam às cegas em ambientes que crescem cinco vezes em um trimestre. Conectar Terraform a uma plataforma madura preserva a velocidade do provisionamento. Por outro lado, devolve aos gestores o controle operacional sobre cada ativo em produção.

Conclusão

Terraform deixou de ser uma ferramenta de nicho e virou o padrão de fato para provisionamento de infraestrutura em equipes sérias de TI. Ele cobre desde cloud pública até hypervisors on-premise como Hyper-V e Proxmox, mantém o estado real da infraestrutura sob controle e permite revisar mudanças antes de aplicá-las.

Adotar Terraform muda mais do que ferramentas: muda o jeito como a equipe pensa infraestrutura. Recursos viram código, mudanças viram pull requests e a auditoria deixa de ser uma planilha desatualizada. Em ambientes híbridos, isso significa eliminar drift, reduzir tempo de provisionamento de dias para minutos e dar aos gestores a previsibilidade que a operação manual nunca entregou.

O ponto que poucos abordam é o que vem depois do apply. Sem monitoração contínua, cada nova VM é um ativo invisível. Por isso, conectar IaC a uma camada robusta de observabilidade fecha o ciclo e transforma provisionamento rápido em operação confiável. Quer entender como integrar Terraform à sua estratégia de monitoração? Fale com um especialista da OpServices e descubra o caminho mais curto até uma operação previsível em ambientes híbridos.