Noções Básicas de Automação de Infraestrutura

10 exemplos para você começar com Automação de Infraestrutura - 7 básicos e 3 intermediários.

Pré-requisitos

uv venv && source .venv/bin/activate
uv pip install "ansible>=10.0" "pulumi>=3.0" "cdktf>=0.20"

• Python 3.14.0 com um ambiente virtual isolado.
• Credenciais AWS via AWS_PROFILE ou função IAM para exemplos na nuvem (opcional para execuções apenas locais).

Exemplos Básicos

1. Defina o Estado Desejado em Código

A automação de infraestrutura começa descrevendo o que deve existir, não como clicar em um console.

# desired_state.py
from dataclasses import dataclass
 
@dataclass(frozen=True)
class BucketSpec:
    name: str
    versioning: bool = True
 
DESIRED = BucketSpec(name="app-logs-prod", versioning=True)

• Trate o estado desejado como estruturas de dados que você pode comparar, testar e revisar em PRs.
• Mudanças no console se desviam do repositório - o código é a fonte da verdade.
• Comece pequeno: um tipo de recurso antes de orquestrar uma VPC inteira.

Relacionado: Gerenciamento de Configuração - templates e ambientes

2. Criação/Atualização Idempotente

Execute o mesmo script duas vezes e termine no mesmo estado - sem recursos duplicados.

import boto3
 
def ensure_bucket(s3, name: str) -> None:
    buckets = [b["Name"] for b in s3.list_buckets().get("Buckets", [])]
    if name not in buckets:
        s3.create_bucket(Bucket=name)
    s3.put_bucket_versioning(
        Bucket=name,
        VersioningConfiguration={"Status": "Enabled"},
    )
 
session = boto3.Session()
ensure_bucket(session.client("s3"), "demo-idempotent-bucket")

• Verifique a existência antes de criar - create_bucket simples falha na segunda execução.
• put_bucket_versioning é naturalmente idempotente - seguro de chamar todas as vezes.
• Retorne resultados estruturados (criado vs atualizado) para logs e auditorias.

Relacionado: Provisionamento de Recursos na Nuvem - provisionamento repetível

3. Idempotência Ad-Hoc do Ansible

Módulos Ansible convergem para o estado declarado automaticamente.

ansible localhost -m ansible.builtin.file -a "path=/tmp/iac-demo state=directory mode=0755"
ansible localhost -m ansible.builtin.file -a "path=/tmp/iac-demo state=directory mode=0755"

• A segunda execução relata ok com changed=0 - isso é idempotência em ação.
• Prefira módulos (file, copy, apt) em vez de shell puro, a menos que não exista módulo.
• Use -C (modo de verificação) para pré-visualizar mudanças sem aplicá-las.

Relacionado: Ansible - playbooks, inventários e roles

4. Versionar Definições de Infraestrutura

Armazene o código de infraestrutura no git com o mesmo rigor do código de aplicação.

git init infra-demo && cd infra-demo
mkdir -p stacks/prod
echo 'name = "prod"' > stacks/prod/Pulumi.yaml
git add . && git commit -m "chore: initial prod stack"

• Cada aplicação deve corresponder a um SHA de commit para rollback e rastreamento.
• Marque releases (infra-v2026.07.09) ao promover para produção.
• Nunca edite recursos de nuvem ao vivo sem uma mudança de código correspondente.

Relacionado: Pulumi (IaC com Python) - Python real para recursos de nuvem

5. Separar Ambientes

Mantenha as configurações de dev, staging e prod distintas, mas estruturalmente idênticas.

from dataclasses import dataclass
 
@dataclass(frozen=True)
class EnvConfig:
    name: str
    bucket_suffix: str
    enable_deletion_protection: bool
 
ENVS = {
    "dev": EnvConfig("dev", "-dev", False),
    "prod": EnvConfig("prod", "-prod", True),
}

• Parametrize nomes e flags - não crie forks de stacks inteiras por ambiente.
• Salvaguardas exclusivas para produção (deletion_protection=True) pertencem à configuração, não a comentários.
• Carregue a configuração do ambiente a partir da variável ENVIRONMENT ou de um flag de CLI, nunca codifique prod diretamente.

Relacionado: Gerenciamento de Configuração - segredos e templates

6. Planeje Antes de Aplicar

Visualize as mudanças antes de mutar a infraestrutura compartilhada.

cd stacks/prod
pulumi preview   # ou: terraform plan

• Planos mostram criações, atualizações e exclusões - revise mudanças destrutivas explicitamente.
• Bloqueie aplicações quando a saída do plano incluir delete inesperado em recursos com estado.
• Salve artefatos de plano em logs de CI para investigação de incidentes.

Relacionado: Testando Código de Infraestrutura - dry-runs e verificações de política

7. Logging Estruturado de Automação

Registre o que mudou, quem executou, e o resultado - não apenas sucesso/falha.

import json
import logging
 
logging.basicConfig(level=logging.INFO, format="%(message)s")
log = logging.getLogger("iac")
 
def apply(spec: dict) -> dict:
    result = {"resource": spec["name"], "action": "updated", "changed": True}
    log.info(json.dumps({"event": "iac_apply", **result}))
    return result
 
apply({"name": "app-logs-prod"})

• Logs JSON são analisados de forma limpa em CloudWatch, Loki ou ELK.
• Inclua IDs de correlação quando a automação for acionada a partir de pipelines de CI.
• Nunca registre segredos, tokens ou blobs completos de estado do Terraform.

Relacionado: Melhores Práticas de Automação de Infraestrutura - regras de infra auditáveis

Exemplos Intermediários

8. Detecção de Drift com boto3

Compare o estado ao vivo da AWS com sua especificação declarada.

import boto3
 
def detect_versioning_drift(bucket: str, expected: str = "Enabled") -> bool:
    s3 = boto3.client("s3")
    resp = s3.get_bucket_versioning(Bucket=bucket)
    actual = resp.get("Status", "Suspended")
    return actual != expected
 
if detect_versioning_drift("app-logs-prod"):
    raise SystemExit("drift detected: versioning mismatch")

• Execute verificações de drift em uma programação, não apenas no momento da implantação.
• Emita métricas ou alertas quando o drift for encontrado - drift silencioso se torna débito de indisponibilidade.
• Emparelhe a detecção com trabalhos de reconciliação automatizados onde for seguro.

Relacionado: Provisionamento de Recursos na Nuvem - infraestrutura revisável

9. Envolva o Terraform com Python (CDKTF)

Gere JSON do Terraform a partir de construtos Python tipados.

from cdktf import App, TerraformStack
from constructs import Construct
 
class MiniStack(TerraformStack):
    def __init__(self, scope: Construct, ns: str):
        super().__init__(scope, ns)
        # Adicione provedores e recursos aqui - cdktf synth escreve JSON do terraform
 
app = App()
MiniStack(app, "mini")
app.synth()

• CDKTF oferece loops, funções e testes sobre templates HCL.
• A saída de cdktf synth ainda é Terraform puro - equipes de operações podem inspecioná-la.
• Fixe versões de provedores na configuração gerada para planos reproduzíveis.

Relacionado: Terraform com Python - CDKTF e envolvendo o Terraform

10. Verificação de Política Antes de Aplicar

Rejeite planos não conformes em CI antes que eles toquem nas contas de nuvem.

def validate_tags(tags: dict) -> list[str]:
    required = {"Environment", "Owner", "CostCenter"}
    missing = required - set(tags)
    return [f"missing tag: {t}" for t in sorted(missing)]
 
errors = validate_tags({"Environment": "prod"})
assert errors, "policy should fail without Owner and CostCenter"

• Codifique políticas organizacionais como funções Python puras - testes unitários rápidos, sem chamadas à nuvem.
• Execute verificações de política em JSON de plano em gates de CI junto com ruff e pytest.
• Falhe fechando: bloqueie a aplicação quando a validação de política retornar erros.

Relacionado: Testando Código de Infraestrutura - linting e verificações de política

Versões de Stack: Esta página foi escrita para Python 3.14.0 (estável 3.14, manutenção 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, e uv 0.6+.