Estágio 03 · 03-06
LockedClickOps cresce até dor: ninguém lembra como aquele LB foi configurado; staging "esquece" um security group; reproduzir prod em outra região leva uma semana de cliques. IaC promete reverter isso, código declarativo, versionado, reviewable, automated. Mas adoção sem disciplina vira lava: state corrompido, drift entre código e cloud, módulos copy-paste com 2k linhas, secrets em state files git.
Este módulo é IaC com profundidade: Terraform (de fato standard), Pulumi (linguagens reais), AWS CDK, Crossplane (K8s-native). State management, módulos reutilizáveis, drift detection, multi-env, secrets, blast radius. Você sai sabendo desenhar IaC que sobrevive 2+ anos de mudança.
Sem IaC, infra é tribal knowledge.
Em 2026, Terraform/OpenTofu domina. Pulumi cresce em times JS/Python/Go. CDK forte em AWS-only shops. Crossplane em times K8s-heavy.
HashiCorp mudou licença (BSL) em 2023; comunidade forkou pra OpenTofu (Linux Foundation), drop-in compatible.
Em projetos novos: OpenTofu pra evitar lock-in. Compatibilidade com Terraform providers e modules é total.
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
backend "s3" {
bucket = "logistica-tfstate"
key = "prod/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "tflock"
}
}
provider "aws" { region = var.region }
resource "aws_s3_bucket" "uploads" {
bucket = "logistica-${var.env}-uploads"
}
Comandos:
terraform init, baixa providers, configura backend.terraform plan, diff entre código e state. Reviewa antes.terraform apply, aplica.terraform destroy, remove tudo (cuidado).State é a fonte de verdade do que Terraform criou. Mapeia código → resources reais. Sem state, Terraform não sabe se recurso já existe.
Backend:
terraform.tfstate no diretório. Não use em time.Locking: evita 2 apply simultâneos corromperem state.
Encryption: state pode conter secrets (passwords, etc.). Encripte at rest sempre.
Drift: state vs realidade. Alguém mudou no console → Terraform detecta no plan.
Reutilização. Módulo é diretório com main.tf, variables.tf, outputs.tf.
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.0.0"
cidr = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b", "us-east-1c"]
public_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
...
}
Module registry público (HashiCorp registry, GitHub) tem módulos battle-tested. Use antes de escrever próprio.
Módulo próprio quando: pattern recorrente do seu projeto que merece abstraction. Não vire arquiteto cego, module-of-modules virou anti-padrão famoso.
Terraform Workspaces: múltiplos states por module config. Útil pra envs simples.
Padrão melhor: directory per env (environments/dev/, environments/staging/, environments/prod/) cada um com seu state file e variables. Workspaces escondem ambiguidade. Directory explicit.
variable "env" { type = string }
locals { name_prefix = "logistica-${var.env}" }
output "vpc_id" { value = module.vpc.vpc_id }
Variable values:
terraform.tfvars (gitignored em alguns casos).*.auto.tfvars (auto-loaded).-var ou -var-file.TF_VAR_env=prod.Outputs expõem valores; outros modules consomem via data.terraform_remote_state ou via module.x.output.
Linguagens reais (TS, Python, Go, .NET, Java). Mesma abstração de resources, mas você usa loops, ifs, funções, types nativos.
import * as aws from "@pulumi/aws";
const bucket = new aws.s3.Bucket("uploads", {
bucket: `logistica-${env}-uploads`,
});
Pros:
Cons:
Em times TS/JS-heavy, Pulumi vira escolha natural.
CDK constrói CloudFormation templates a partir de código (TS, Python, Java, Go, .NET).
Layers:
Cons: locked em AWS. CFN tem limites (timeouts, error handling difícil). Drift detection fraca. Pros: integração profunda em AWS. Constructs ricas. Para AWS-only shops, vale.
CDKTF (CDK for Terraform): CDK que sai Terraform em vez de CFN. Híbrido.
K8s-native IaC. Você define resources como CRDs no cluster:
apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata: { name: prod-db }
spec:
forProvider:
region: us-east-1
engine: postgres
instanceClass: db.t4g.small
Controllers Crossplane reconciliam, mesmo modelo do K8s.
Pros: GitOps natural; uma plataforma pra app + infra; Compositions (módulos) reutilizáveis. Cons: curva de aprendizado; ecosystem menor que Terraform; nem todo provider tem qualidade Crossplane.
Anti-padrão #1: secret em .tf versionado.
Padrão:
Em CI: Terraform assume role via OIDC.
Drift: console mudou recurso → plan mostra. Decisão: trazer pra código ou reverter.
Import: trazer recurso existente pra state sem destruir/recriar. terraform import aws_s3_bucket.x bucket-name. Em Terraform 1.5+, import {} blocks declarativos.
Refactor: renomear resource sem destroy/recreate. moved {} block (Terraform 1.1+).
terraform plan: review humano é o teste primário.terraform validate: syntax checks.tflint: linter, regras best practices.tfsec, checkov: security scanners (overly permissive, encryption off, etc.).terraform-docs: gera docs.Em CI: validate + lint + scan em PR; plan visível; apply só com approval.
Cross-env data: outputs de "shared" stack lidos por env stacks via data.terraform_remote_state.
State único = mudança em 04-03 bucket pode forçar replan de DB. Separe por blast radius:
Cada layer com state separado. Apps não precisam re-plan VPC.
Gate típico: nenhum SG com 0.0.0.0/0 em porta 22. RDS sempre encrypted. Tags obrigatórias.
Visibilidade de custo no review evita surpresa.
Você precisa, sem consultar:
Reproduzir infra do 03-05 com Terraform/OpenTofu, dividida por blast radius e versionada.
infra/
bootstrap/ # cria backend bucket + DDB table
modules/
vpc/
ecs-service/
rds-postgres/
elasticache-redis/
environments/
staging/
networking/
data/
compute/
prod/
networking/
data/
compute/
terraform_remote_state.vpc: 3 AZs, pub/priv subnets, NAT controlado por flag.ecs-service: task definition, service, target group, security group, com inputs (image, cpu, memory, env vars, secrets ARNs).rds-postgres: instância Multi-AZ, password gerado random + Secrets Manager, parameter group.elasticache-redis: cluster + replicas.random_password, armazenado em Secrets Manager.moved {} renomeando recurso sem destroy.import {} trazendo um recurso "criado clickado" pro state.terraform apply em prod sem terraform plan review.plan mostrando mudança em compute sem afetar networking.moved e import aplicadas.plan mostra; reverte via apply.Destrava
03-06 é prereq dos seguintes módulos: