Infraestrutura no Google Cloud com Terraform: uma base confiável

Infraestrutura como código começa a mostrar valor quando surge um segundo ambiente, uma revisão precisa explicar o que mudou ou uma configuração precisa ser reproduzida sem depender da memória de alguém. Esta é a base que uso para iniciar projetos no Google Cloud com Terraform.

O estado remoto vem primeiro — depois do bootstrap

O Terraform mantém um arquivo de estado com o mapeamento dos recursos que gerencia. Guardar esse arquivo apenas em uma máquina local cria risco de conflito, perda e divergência.

Existe, porém, uma dependência circular: o backend GCS precisa de um bucket que ainda não existe. Por isso, o primeiro passo é criar esse bucket com um pequeno módulo de bootstrap usando estado local. Depois da criação, o backend remoto é configurado e o estado é migrado com terraform init -migrate-state.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 7.39"
    }
  }
}

resource "google_storage_bucket" "terraform_state" {
  name                        = "my-project-terraform-state"
  location                    = "US"
  uniform_bucket_level_access = true

  versioning {
    enabled = true
  }
}

Com o bucket disponível, a configuração principal pode usar o backend GCS:

terraform {
  backend "gcs" {
    bucket = "my-project-terraform-state"
    prefix = "env/prod"
  }
}

Versionamento no bucket ajuda a recuperar alterações acidentais, mas não substitui permissões mínimas, retenção e uma estratégia de backup adequada ao projeto.

Uma estrutura que cresce sem esconder tudo

Mantenho a raiz pequena e extraio módulos quando existe uma fronteira reutilizável — não apenas para reduzir o tamanho de um arquivo.

infra/
├── main.tf
├── providers.tf
├── variables.tf
├── outputs.tf
└── modules/
    ├── network/
    └── cloud-run/

Uma chamada de serviço permanece explícita:

module "api" {
  source = "./modules/cloud-run"

  name    = "api"
  image   = var.api_image
  region  = var.region
  project = var.project_id
}

Duas regras evitam acoplamento desnecessário: toda variável possui descrição e módulos não fixam IDs de projeto ou ambiente.

Plan, review, apply

O ciclo local é curto e previsível:

1. terraform fmt -check para padronizar a configuração;
2. terraform validate para validar estrutura e tipos;
3. terraform plan -out=tfplan para materializar a mudança esperada;
4. revisão do plano antes de terraform apply tfplan.

No CI, o plano pode ser anexado à pull request. O apply fica restrito à branch principal e a ambientes protegidos. Para pipelines fora do Google Cloud, Workload Identity Federation evita chaves JSON permanentes e fornece credenciais de curta duração.

Um plano do Terraform merece a mesma atenção de um diff de código: se a mudança não está clara, ela ainda não está pronta para ser aplicada.

Próximos passos

Depois dessa base, os próximos ganhos costumam vir de estados separados por ambiente, detecção agendada de drift, políticas no CI e testes dos módulos. Mas não é necessário começar por uma plataforma complexa.

Um bootstrap explícito, estado remoto protegido, um módulo útil e um plano revisado já criam uma fundação confiável.