Terraform do zero: Infrastructure as Code para devs que não são DevOps

Antes do Framework — Ep. 06

Você aprendeu a versionar código, configurar ambientes com Docker e trabalhar em time com Git — três etapas da ordem concluídas.

Mas tem uma parte do sistema que a maioria dos devs ignora até ser tarde demais: a infraestrutura onde tudo isso roda.

Servidor, banco de dados, rede, permissões, variáveis de ambiente de produção, tudo isso existe em algum lugar, e se você configurou tudo clicando no painel da AWS ou do GCP, parabéns: você criou um problema invisível que vai aparecer na pior hora possível.

AWS, GCP, Azure: onde os sistemas vivem

Antes de falar de IaC, vale entender o cenário. Quando você coloca um sistema em produção, ele precisa rodar em algum servidor, e esse servidor fica em um datacenter operado por uma das grandes plataformas de nuvem.

As três principais são:

• AWS (Amazon Web Services): a maior e mais completa, usada pela maioria das empresas no Brasil e no mundo
• GCP (Google Cloud Platform): forte em machine learning, big data e integração com produtos do Google
• Azure (Microsoft): dominante em empresas enterprise com infraestrutura Microsoft

Cada uma tem seu próprio painel de controle, sua própria forma de criar servidores, bancos, redes e permissões, e sua própria API por baixo. São plataformas completamente diferentes entre si.

O que elas têm em comum: todas oferecem uma interface web onde você pode clicar e configurar tudo manualmente. E é exatamente aí que começa o problema.

O problema da ClickOps

ClickOps é o nome que o mercado deu para configurar infraestrutura manualmente pelo painel web de uma plataforma, clique a clique.

Funciona. Até o dia que você precisa recriar tudo.

Cenários reais onde isso acontece:

• O servidor vai abaixo e você precisa provisionar um novo do zero
• O cliente quer um ambiente de staging idêntico ao de produção
• Você entra em um novo time e precisa entender o que está configurado
• Alguém clicou em algo errado e ninguém sabe o que era antes

Na ClickOps, a única documentação da sua infraestrutura é a sua memória, e memória é o pior sistema de versionamento que existe.

O que é Infrastructure as Code

IaC é a prática de descrever infraestrutura em arquivos de texto, da mesma forma que você descreve o comportamento de um sistema em código.

Em vez de entrar no painel e clicar em "criar servidor", você escreve:

resource "aws_instance" "app" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
}

E roda um comando que cria esse servidor para você, de forma idêntica, toda vez.

A infraestrutura passa a viver no Git: versionada, revisada em PRs, auditável, reproduzível em qualquer ambiente.

"Se não está no Git, não existe" vale para código. Com IaC, vale para servidor, banco, rede e permissões também.

Terraform: o padrão do mercado

Terraform é a ferramenta mais adotada para IaC, criada pela HashiCorp e mantida como open source. Ela funciona com praticamente qualquer plataforma de nuvem através de providers.

Providers: o que são e por que existem

Quando o Terraform foi criado, o objetivo era ser uma ferramenta única que funcionasse com qualquer plataforma de nuvem, sem que o usuário precisasse aprender uma ferramenta diferente para cada uma. O problema é que AWS, GCP, Azure e DigitalOcean têm APIs completamente diferentes entre si.

A solução foi o conceito de provider: um plugin separado que traduz os seus arquivos .tf para as chamadas específicas da API de cada plataforma. O Terraform em si não sabe criar um servidor na AWS, mas o provider aws sabe, e o Terraform delega essa responsabilidade para ele.

Na prática, você declara qual provider vai usar no topo do seu arquivo, o Terraform baixa o plugin certo no terraform init, e a partir daí você escreve configuração uma vez, independente de qual nuvem está por baixo. Trocar de AWS para GCP significa trocar o provider e adaptar os recursos, mas o fluxo de trabalho permanece idêntico.

Um provider é o plugin que conecta o Terraform à plataforma que você quer gerenciar:

Você não precisa escolher um e dominar todos. Aprenda os conceitos com qualquer um, porque a lógica é a mesma em todos.

Terraform na prática

Estrutura básica de um projeto

infra/
├── main.tf          # recursos principais
├── variables.tf     # variáveis de entrada
├── outputs.tf       # valores que o Terraform exporta após aplicar
└── terraform.tfvars # valores das variáveis (não vai pro Git se tiver segredos)

O ciclo de trabalho

Três comandos que você vai usar o tempo todo:

terraform init    # inicializa o projeto e baixa os providers
terraform plan    # mostra o que vai acontecer, sem aplicar nada
terraform apply   # aplica as mudanças

O plan é seu melhor amigo: antes de mudar qualquer coisa em produção, você vê exatamente o que vai ser criado, modificado ou destruído.

Exemplo real: servidor + banco na DigitalOcean

terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

resource "digitalocean_droplet" "app" {
  name   = "meu-app-prod"
  region = "nyc3"
  size   = "s-1vcpu-1gb"
  image  = "ubuntu-22-04-x64"
}

resource "digitalocean_database_cluster" "db" {
  name       = "meu-banco-prod"
  engine     = "pg"
  version    = "15"
  size       = "db-s-1vcpu-1gb"
  region     = "nyc3"
  node_count = 1
}

# variables.tf
variable "do_token" {
  description = "Token da DigitalOcean"
  sensitive   = true
}

# terraform.tfvars (no .gitignore)
do_token = "seu-token-aqui"

Rodando terraform apply, o Terraform cria o servidor e o banco na ordem certa, trata dependências automaticamente e salva o estado do que foi criado.

Estado e idempotência

Dois conceitos que fazem o Terraform funcionar de forma confiável:

Estado (terraform.tfstate): o Terraform mantém um arquivo que registra o que ele criou. Da próxima vez que você rodar apply, ele compara o estado atual com o que está nos arquivos .tf e aplica apenas o que mudou, sem recriar tudo do zero.

Idempotência: rodar terraform apply dez vezes seguidas com os mesmos arquivos produz o mesmo resultado que rodar uma vez. Não há duplicação, não há surpresa.

Essa combinação significa que você pode commitar a infra, abrir um PR, receber review e aplicar com confiança, sabendo exatamente o que vai mudar.

Atenção com o tfstate: esse arquivo pode conter informações sensíveis e deve ser armazenado remotamente (S3, GCS, Terraform Cloud) em projetos reais, nunca commitado no repositório.

O que vai pro Git e o que não vai

# .gitignore
terraform.tfvars       # contém segredos reais
.terraform/            # dependências baixadas pelo init
*.tfstate              # estado atual da infra
*.tfstate.backup       # backup do estado

O que fica no repositório são apenas os arquivos .tf e um terraform.tfvars.example com as chaves vazias, o mesmo padrão do .env.example que você já conhece.

Por que um dev iniciante em 2026 precisa saber isso

Não estou dizendo que você vai virar DevOps, estou dizendo que você não vai precisar esperar por um.

A maioria dos devs iniciantes nunca aprende infraestrutura porque parece "coisa de outra área", e é exatamente aí que está o diferencial. Quando todo mundo está no mesmo nível de código, o que te separa do resto é o quanto você entende do ciclo completo: do git push ao sistema rodando em produção, sem precisar parar e perguntar pra alguém como sobe isso.

Na prática, isso significa:

• Você consegue colocar seu projeto no ar sem depender de ninguém
• Em uma startup ou time pequeno, onde não existe DevOps dedicado, você é a pessoa que resolve
• Em uma empresa maior, você consegue conversar com a equipe de infra sem ser o dev que "só faz o código mas não entende o resto"
• No seu portfólio, um projeto com infra versionada em Terraform já diz muito mais do que um CRUD no Heroku

O mercado de 2026 tem excesso de devs que sabem escrever código, o que ainda é raro é o dev que entende o sistema inteiro. Não porque é difícil, mas porque a maioria não tem paciência para aprender o que não parece imediatamente necessário.

IaC é exatamente esse tipo de conhecimento: você não vai usar todo dia, mas no dia que precisar, vai fazer uma diferença enorme na sua capacidade de resolver problemas de forma autônoma.

Extra: repositório de referência e dica de quem trabalha com isso todo dia

Se você quer ver um exemplo real de projeto Terraform organizado, criei um repositório de infraestrutura reutilizável para backends Docker no Google Cloud:

github.com/vick1st/terraform-gcp-docker-backend

É um ponto de partida concreto: estrutura de arquivos, configuração de provider GCP, recursos para rodar containers no Cloud Run e tudo versionado do jeito que foi explicado nesse post.

Dica de um DevOps Sênior de FinOps

Enquanto estudava Terraform, conversei com um DevOps Sênior que opera infraestrutura de uma grande empresa de FinOps na América Latina, e ele fez uma recomendação simples que faz diferença real na organização de qualquer projeto:

Separe as configurações de provider em um arquivo dedicado.

Em vez de deixar tudo no main.tf, mova o bloco terraform {} e a configuração do provider para um providers.tf:

infra/
├── main.tf          # apenas os recursos (instâncias, bancos, redes)
├── providers.tf     # configuração do Terraform e dos providers
├── variables.tf     # variáveis de entrada
├── outputs.tf       # valores exportados
└── terraform.tfvars # valores reais (no .gitignore)

# providers.tf
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

# main.tf — só recursos, sem configuração de provider
resource "google_cloud_run_v2_service" "app" {
  name     = var.service_name
  location = var.region
  # ...
}

O motivo é separação de responsabilidades: main.tf descreve o que existe, providers.tf descreve com quem o Terraform conversa, e os dois mudam por razões completamente diferentes. Quando você precisa atualizar a versão do provider ou adicionar uma nova plataforma, sabe exatamente onde mexer sem precisar vasculhar o arquivo principal.

É o mesmo princípio do single responsibility que você já conhece no código, aplicado à infraestrutura.

→ Próximo episódio

Você tem a base técnica: redes, Linux, Git, Docker, trabalho em time e infraestrutura como código. Agora vem a pergunta que todo iniciante faz na hora errada: qual linguagem e qual stack eu escolho? A resposta muda completamente quando você já tem essa base.

Antes do Framework — Ep. 07: Como escolher sua primeira linguagem de programação e stack em 2026