Infraestrutura como código

Declarativo e imperativo

• Ferramentas declarativas (Terraform, CloudFormation, manifestos Kubernetes) descrevem o estado final desejado; a ferramenta descobre como chegar lá.
• Ferramentas e scripts imperativos descrevem os passos. São flexíveis, mas é mais fácil executá-los duas vezes com resultados diferentes.
• A gestão de configuração (Ansible, Chef) instala e configura software em máquinas; as ferramentas de provisionamento criam as máquinas e os recursos de nuvem. Muitas equipes usam as duas, ou evitam servidores mutáveis gerando imagens prontas.
• Prefira infraestrutura imutável: substitua em vez de aplicar patch no lugar.

O ciclo de plan e apply

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = "example-terraform-state"
    key            = "network/prod.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  tags                 = merge(var.tags, { Name = "main" })
}

terraform fmt -check && terraform validate
terraform plan -out=tfplan             # revise isto no pull request
terraform apply tfplan                 # executado pelo pipeline, não por um notebook

Práticas

• State remoto, com lock e criptografado; nunca faça commit de arquivos de state (podem conter segredos).
• Módulos pequenos com entradas e saídas claras, versionados e reutilizados; evite um único módulo raiz gigante.
• Separe ambientes por state e por conta, não por uma variável que você pode esquecer de mudar.
• Detecte e corrija o drift: agende um plan e alerte quando a realidade diferir do código.
• Faça scan do código e do plan em busca de configurações inseguras antes do apply (veja Infrastructure as code security no domínio Engineering).
• Mantenha segredos fora do código; referencie um gerenciador de segredos.

Armadilhas

• Mudanças manuais no console que o código depois sobrescreve ou com as quais briga.
• Um destroy escondido num plan grande: leia o que está sendo substituído, não só o que está sendo adicionado.
• Versões de provider e de módulo deixadas flutuantes, de modo que um plan muda sem mudança de código.
• Um único state para tudo: um pequeno erro bloqueia todas as equipes e o raio de impacto é a empresa inteira.