Conceptos básicos de automatización de infraestructura

10 ejemplos para empezar con la automatización de infraestructura: 7 básicos y 3 intermedios.

Prerrequisitos

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

• Python 3.14.0 con un entorno virtual aislado.
• Credenciales de AWS a través de AWS_PROFILE o rol de IAM para ejemplos en la nube (opcional para ejecuciones solo locales).

Ejemplos básicos

1. Definir el estado deseado en código

La automatización de infraestructura comienza describiendo lo que debería existir, no cómo hacer clic en una consola.

# 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 el estado deseado como estructuras de datos que puede comparar, probar y revisar en PRs.
• Los cambios en la consola se desvían del repositorio; el código es la fuente de verdad.
• Empiece poco a poco: un tipo de recurso antes de orquestar una VPC completa.

Relacionado: Gestión de configuración - plantillas y entornos

2. Creación/actualización idempotente

Ejecute el mismo script dos veces y termine en el mismo estado, sin 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 la existencia antes de crear; create_bucket sin más fallará en la segunda ejecución.
• put_bucket_versioning es naturalmente idempotente, seguro de llamar cada vez.
• Devuelva resultados estructurados (created vs updated) para registro y auditorías.

Relacionado: Aprovisionamiento de recursos en la nube - aprovisionamiento repetible

3. Idempotencia Ad-Hoc de Ansible

Los módulos de Ansible convergen automáticamente hacia el estado declarado.

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"

• La segunda ejecución informa ok con changed=0; eso es idempotencia en acción.
• Prefiera módulos (file, copy, apt) sobre shell crudo a menos que no exista un módulo.
• Use -C (modo de verificación) para previsualizar cambios sin aplicarlos.

Relacionado: Ansible - playbooks, inventarios y roles

4. Versionar definiciones de infraestructura

Almacene el código de infraestructura en git con el mismo rigor que el código de aplicación.

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 aplicación debe mapearse a un SHA de commit para reversión y atribución.
• Etiquete lanzamientos (infra-v2026.07.09) al promocionar a producción.
• Nunca edite recursos de nube en vivo sin un cambio de código coincidente.

Relacionado: Pulumi (IaC con Python) - Python real para recursos en la nube

5. Separar entornos

Mantenga las configuraciones de desarrollo, staging y producción distintas pero estructuralmente 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),
}

• Parametrice nombres y flags; no duplique pilas completas por entorno.
• Las salvaguardas exclusivas para producción (deletion_protection=True) pertenecen a la configuración, no a los comentarios.
• Cargue la configuración del entorno desde la variable ENVIRONMENT o un flag de CLI, nunca codifique prod de forma rígida.

Relacionado: Gestión de configuración - secretos y plantillas

6. Planificar antes de aplicar

Previsualice los cambios antes de mutar la infraestructura compartida.

cd stacks/prod
pulumi preview   # o: terraform plan

• Los planes muestran creaciones, actualizaciones y eliminaciones; revise los cambios destructivos explícitamente.
• Bloquee aplicaciones cuando la salida del plan incluya delete inesperado en recursos con estado.
• Guarde artefactos de plan en los registros de CI para la investigación de incidentes.

Relacionado: Pruebas de código de infraestructura - ejecuciones en seco y verificaciones de políticas

7. Registro estructurado de automatización

Registre qué cambió, quién lo ejecutó y el resultado, no solo éxito/fracaso.

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"})

• Los registros JSON se analizan limpiamente en CloudWatch, Loki o ELK.
• Incluya IDs de correlación cuando la automatización se active desde pipelines de CI.
• Nunca registre secretos, tokens o blobs completos de estado de Terraform.

Relacionado: Mejores prácticas de automatización de infraestructura - reglas de infraestructura auditables

Ejemplos intermedios

8. Detección de desviaciones con boto3

Compare el estado en vivo de AWS con su especificación 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")

• Ejecute verificaciones de desviaciones según un horario, no solo en el momento de la implementación.
• Emita métricas o alertas cuando se encuentre una desviación; la desviación silenciosa se convierte en deuda de interrupción.
• Empareje la detección con trabajos de reconciliación automatizados cuando sea seguro.

Relacionado: Aprovisionamiento de recursos en la nube - infraestructura revisable

9. Envolver Terraform con Python (CDKTF)

Genere JSON de Terraform a partir de constructos tipados de Python.

from cdktf import App, TerraformStack
from constructs import Construct
 
class MiniStack(TerraformStack):
    def __init__(self, scope: Construct, ns: str):
        super().__init__(scope, ns)
        # Agregue proveedores y recursos aquí - cdktf synth escribe JSON de terraform
 
app = App()
MiniStack(app, "mini")
app.synth()

• CDKTF le proporciona bucles, funciones y pruebas sobre plantillas HCL.
• La salida de cdktf synth sigue siendo Terraform plano; los equipos de operaciones pueden inspeccionarla.
• Fije las versiones de los proveedores en la configuración generada para planes reproducibles.

Relacionado: Terraform con Python - CDKTF y envolver Terraform

10. Verificación de políticas antes de aplicar

Rechace planes no conformes en CI antes de que toquen las cuentas en la nube.

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 las políticas de la organización como funciones puras de Python: pruebas unitarias rápidas, sin llamadas a la nube.
• Ejecute verificaciones de políticas en el JSON del plan en las puertas de CI junto con ruff y pytest.
• Bloquee al cerrar: impida la aplicación cuando la validación de políticas devuelva errores.

Relacionado: Pruebas de código de infraestructura - linting y verificaciones de políticas

Versiones de pila: Esta página se escribió para Python 3.14.0 (estable 3.14, mantenimiento 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+ y uv 0.6+.