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_PROFILEo 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)
- Verifique la existencia antes de crear;
create_bucketsin más fallará en la segunda ejecución. put_bucket_versioninges naturalmente idempotente, seguro de llamar cada vez.- Devuelva resultados estructurados (
createdvsupdated) 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
okconchanged=0; eso es idempotencia en acción. - Prefiera módulos (
file,copy,apt) sobreshellcrudo 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",
- 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
ENVIRONMENTo un flag de CLI, nunca codifiqueprodde 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
deleteinesperado 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
- 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"
- 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()
- CDKTF le proporciona bucles, funciones y pruebas sobre plantillas HCL.
- La salida de
cdktf synthsigue 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
- 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
ruffypytest. - 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+.