Terraform na prática: provisione servidores em nuvem com IaC

Provisionar um servidor clicando no console da nuvem funciona uma vez. Na segunda, na décima e na centésima vez, o processo vira fonte de erro humano e de “só eu sei como montei isso”. O Terraform resolve isso descrevendo a infraestrutura em arquivos de texto: você escreve o que quer, roda um comando, e a ferramenta cria, altera ou destrói recursos reais na nuvem para bater com essa descrição. Neste guia você instala o Terraform no Ubuntu, provisiona um servidor de verdade na Hetzner Cloud e sai entendendo o ciclo init → plan → apply → destroy.

Por que Infraestrutura como Código em vez do clique manual

Clicar em “criar servidor” no painel da nuvem não deixa rastro. Ninguém sabe, seis meses depois, por que aquela instância tem 4 vCPUs em vez de 2, ou se o firewall foi configurado igual ao das outras. Com Terraform, essa configuração vira arquivo .tf versionado no Git: dá para revisar em pull request antes de aplicar, reproduzir o mesmo ambiente em outra conta, e recriar um servidor destruído por acidente em minutos, com o mesmo estado exato de antes.

Um ponto que muda a leitura de “de graça”: desde 2023 o Terraform é distribuído sob a licença BUSL (Business Source License), não mais open source puro — a HashiCorp fechou o código para impedir provedores de nuvem de revenderem o produto como serviço concorrente. Para uso normal, em empresa ou como profissional de infraestrutura, isso não muda nada: o binário continua gratuito para baixar e usar. Quem quer a via 100% open source tem o OpenTofu, fork mantido pela Linux Foundation e compatível com a mesma sintaxe — a lógica deste tutorial vale para os dois.

Instalando o Terraform no Ubuntu Server

A HashiCorp mantém repositório apt oficial, então a instalação fica sob controle de atualização do sistema, sem baixar binário solto.

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common curl

wget -O- https://apt.releases.hashicorp.com/gpg | \
  gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list

sudo apt update && sudo apt install -y terraform

Confirme a instalação e o autocomplete do shell:

terraform -version
terraform -install-autocomplete

Criando o primeiro projeto: um servidor na Hetzner Cloud

O exemplo usa a Hetzner Cloud porque o provedor hcloud é simples, documentado e não exige cartão internacional para testar. A mesma lógica de blocos se aplica a AWS, Azure, GCP ou qualquer provedor com provider Terraform — só muda o nome dos recursos.

Gere um token de API em Console Hetzner → seu projeto → Security → API Tokens → Generate API Token com permissão de leitura e escrita. Depois crie a estrutura do projeto:

mkdir ~/terraform-hcloud && cd ~/terraform-hcloud
touch main.tf variables.tf terraform.tfvars .gitignore

Em variables.tf, declare o provedor e a variável que vai receber o token — nunca escreva o token direto no main.tf:

terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.48"
    }
  }
  required_version = ">= 1.5"
}

variable "hcloud_token" {
  sensitive = true
}

provider "hcloud" {
  token = var.hcloud_token
}

Em main.tf, descreva o servidor:

resource "hcloud_server" "web" {
  name        = "pulseit-lab-01"
  image       = "ubuntu-24.04"
  server_type = "cx22"
  location    = "nbg1"

  ssh_keys = ["minha-chave-ssh"]
}

output "ip_publico" {
  value = hcloud_server.web.ipv4_address
}

Em terraform.tfvars, cole o token gerado no console (esse arquivo nunca vai para o Git):

hcloud_token = "SEU_TOKEN_AQUI"

E no .gitignore:

*.tfvars
.terraform/
*.tfstate
*.tfstate.backup

O ciclo init, plan, apply e destroy

Com os arquivos prontos, o fluxo é sempre o mesmo, em qualquer provedor:

1. terraform init — baixa o plugin do provedor hcloud e prepara o diretório de trabalho.
2. terraform plan — mostra exatamente o que vai ser criado, alterado ou destruído, sem tocar em nada ainda. É o passo que evita surpresa em produção.
3. terraform apply — aplica o plano depois de pedir confirmação (digite yes).
4. terraform destroy — remove tudo que o Terraform criou, útil para laboratório e ambientes efêmeros.

terraform init
terraform plan
terraform apply

Depois do apply, o IP do servidor aparece no output:

Outputs:

ip_publico = "5.161.XX.XX"

Esse valor sai de um arquivo que o Terraform cria sozinho: o terraform.tfstate. Ele guarda o mapeamento entre o que está escrito no .tf e o que existe de verdade na nuvem. Nunca edite esse arquivo à mão — um campo alterado manualmente descola o estado da realidade, e o próximo apply pode tentar recriar ou destruir recurso que já existe. Para laboratório, o state local é suficiente; para equipe, o certo é state remoto (Terraform Cloud, S3 com DynamoDB, ou storage do próprio provedor), para dois computadores nunca aplicarem mudanças conflitantes ao mesmo tempo.

Terminou o teste? Derrube o servidor para não pagar por ele à toa:

terraform destroy

Boas práticas para não se queimar em produção

• Trave a versão do provider. O version = "~> 1.48" no required_providers evita que uma atualização do provedor mude o comportamento do seu código sem aviso. Sem isso, um init em outra máquina pode baixar uma versão mais nova com breaking change.
• Comite o .terraform.lock.hcl. Ele fixa o hash exato do provider baixado — sem ele, cada init pode resolver uma versão ligeiramente diferente dentro da faixa permitida.
• Nunca comite .tfvars nem .tfstate. Ambos podem conter token, senha ou IP interno em texto puro.
• Separe ambientes. Use workspaces do Terraform ou diretórios distintos (dev/, prod/) para nunca rodar um apply de teste contra o ambiente que está no ar.
• Revise o plano antes do apply, sempre. Em pipeline de CI/CD, isso vira aprovação manual obrigatória antes de aplicar em produção.

Perguntas frequentes

Terraform é gratuito?
O binário CLI é gratuito para baixar e usar, inclusive em empresa. A licença BUSL só restringe quem quer revender o Terraform embutido em um produto de nuvem concorrente da HashiCorp — não afeta o uso comum de provisionamento.

Terraform funciona só com AWS?
Não. Existem providers oficiais e da comunidade para praticamente todo provedor de nuvem — AWS, Azure, GCP, Hetzner, DigitalOcean, Oracle Cloud — além de serviços que não são nuvem, como Cloudflare, GitHub e até Kubernetes.

Preciso saber programar para usar Terraform?
Não. A linguagem HCL (HashiCorp Configuration Language) é declarativa, parecida com um arquivo de configuração — você descreve o resultado desejado, não o passo a passo de como chegar lá.

Qual a diferença entre Terraform e Ansible?
Terraform provisiona a infraestrutura em si (criar o servidor, a rede, o disco). Ansible configura o que roda dentro dela (instalar pacote, subir serviço, ajustar arquivo). Na prática, os dois são usados juntos: Terraform cria o servidor, Ansible entra depois para configurá-lo.

O que acontece se eu apagar o arquivo terraform.tfstate?
O Terraform perde a referência do que já existe na nuvem e, no próximo apply, pode tentar criar os recursos de novo, duplicando o que já está no ar. Sem backup do state (local ou remoto), a recuperação exige importar cada recurso manualmente com terraform import.

Conclusão

O ganho do Terraform não aparece no primeiro servidor — aparece no décimo, quando reconstruir um ambiente inteiro é rodar terraform apply em vez de seguir um checklist manual de trinta passos. Comece pequeno, com um recurso só, como neste guia, versione o código no Git desde o primeiro commit e migre o state para um backend remoto assim que mais de uma pessoa for aplicar mudança no mesmo ambiente.