Buenas Prácticas de Automatización de Infraestructura
Una infraestructura idempotente, versionada y auditable mantiene predecibles los cambios en producción. Estas reglas se aplican ya sea que uses Ansible, Pulumi, Terraform/CDKTF o scripts de boto3.
Cómo Usar Esta Lista
- Adóptalas antes de la primera aplicación en producción; las adaptaciones posteriores son dolorosas una vez que se acumula la deriva.
- Convierte los elementos no verificados en tickets rastreables con responsables, no en excepciones silenciosas.
- Revisa trimestralmente a medida que cambian las cuentas, las reglas de cumplimiento y el tamaño del equipo.
- Combina con Testing Infrastructure Code para la aplicación en CI.
A - Fuente de Verdad
- Almacena todas las definiciones de infraestructura en git. Las correcciones rápidas en la consola deben ser retroportadas o revertidas dentro de un día hábil.
- Fija las versiones de las herramientas en archivos de bloqueo (lockfiles).
pulumi,cdktf,ansibley los paquetes de proveedores se instalan a partir de bloqueos deuv/pipen CI. - Un esquema de nomenclatura de recursos lógicos. Nombres lógicos estables evitan la rotación de reemplazos en los motores de IaC.
- Etiqueta cada recurso con Entorno, Propietario y Centro de Costos. La política de CI rechaza creaciones sin etiquetar.
- Documenta el mapeo de stack a cuenta en el README. Evita aplicar el stack
proda la cuenta AWS incorrecta.
B - Disciplina de Planificación y Aplicación
- Ejecuta
plan/previewen cada PR que toque la infraestructura. Adjunta la salida al PR o al almacén de artefactos de CI. - Bloquea cambios destructivos no revisados. Las eliminaciones en recursos con estado requieren un ticket de aprobación explícito.
- Usa archivos de plan guardados para la aplicación.
terraform apply tfplan- no un plan implícito fresco en el momento de la aplicación. - Separa el estado por entorno. Sin estado compartido de Terraform/Pulumi entre desarrollo y producción.
- Falla en modo cerrado ante errores de política. Los fallos de
pytest/OPA detienen el pipeline; sin anulaciones manuales sin registro de incidentes.
C - Secretos y Configuración
- Nunca confirmes secretos en
group_vars,tfvarso configuración de Pulumi. Usa configuración cifrada o referencias a gestores de secretos. - Renderiza plantillas a partir de YAML en capas, no de archivos bifurcados por entorno. Una plantilla, solo superposiciones de datos del entorno.
- Valida la configuración con Pydantic o pruebas de esquema antes de renderizar. Los errores tipográficos deben fallar en CI, no en despliegues de producción.
- Restringe los permisos de los archivos renderizados al usuario del servicio. Modo
0600para archivos que contienen credenciales. - Rota los secretos sin editar los IDs de recursos de IaC. Actualiza los valores de los secretos en el gestor, vuelve a renderizar la configuración de la aplicación.
D - Idempotencia y Deriva (Drift)
- Prefiere módulos sobre shell crudo en Ansible. Conserva el reporte
changed=0y la semántica de convergencia. - Implementa ayudantes
ensurepara código de pegamentoboto3. Comprueba la existencia antes de crear; converge etiquetas y configuraciones. - Programa trabajos de detección de deriva. Compara los atributos en vivo de AWS con la especificación declarada; alerta ante discrepancias.
- La segunda convergencia de Ansible debe reportar cero cambios. Molecule o CI demuestran idempotencia.
- Importa recursos adoptados al estado de IaC. No dejes recursos creados en la consola sin seguimiento.
E - Operaciones y Auditoría
- Emite logs estructurados en JSON desde la automatización. Incluye actor, stack, SHA del commit y recuentos de acciones.
- Usa federación OIDC para roles de AWS de CI. Sin
AWS_ACCESS_KEY_IDde larga duración en secretos de GitHub/GitLab. - Cuenta sandbox para pruebas de integración. Las credenciales de producción nunca alimentan los pipelines de PR.
- Ejecuta
ruffypytesten paquetes Python de infraestructura. El mismo nivel de calidad que el código de aplicación. - Mantén el acceso a la consola de "break-glass" raro y registrado. Después de un incidente, reconcilia los cambios de la consola en git.
Preguntas Frecuentes
¿Cuál es la configuración mínima viable de IaC?
Repositorio Git, plan en PR, estado aislado por entorno, etiquetas obligatorias y secretos fuera de git. Añade Molecule/OPA a medida que madures.
¿Pueden los equipos pequeños omitir Terraform?
Pulumi Python o scripts boto3 disciplinados con ensure funcionan para huellas pequeñas; aún requieren revisión similar a plan y seguimiento de estado.
¿Cómo hago cumplir las etiquetas?
Política de pytest sobre el JSON del plan, reglas de AWS Config o Políticas de Control de Servicios; defensa en profundidad supera una sola verificación.
¿Cuándo es aceptable un cambio manual en la consola?
Solo en incidentes de "break-glass". Abre un ticket para importar o revertir el cambio en IaC antes de la próxima aplicación programada.
¿Con qué frecuencia debo ejecutar la detección de deriva?
Diariamente para recursos críticos de producción, semanalmente para niveles inferiores; ajusta según el historial de incidentes y la velocidad de cambio.
¿Deberían los desarrolladores aplicar a producción?
Prefiere la promoción por CI con puertas de aprobación. Las aplicaciones directas a producción desde portátiles multiplican el riesgo de auditoría y mala contabilidad.
¿Cómo dividen la propiedad Ansible y Pulumi?
Pulumi/Terraform para primitivas de nube; Ansible para configuración a nivel de SO en instancias. Documenta la transferencia en los runbooks.
¿Qué pertenece a `pytest` y qué a OPA?
Reglas organizacionales simples (etiquetas, nombres) en pytest para velocidad. Políticas de grafos complejas (sin reglas de SG públicas) en OPA sobre el JSON completo del plan.
¿Cómo revierto infraestructura?
Revierte el commit de git y vuelve a aplicar, o restaura una instantánea del estado si el backend lo soporta; practica la reversión primero en sandbox.
¿Por qué logs estructurados?
Los incidentes necesitan saber quién cambió qué y cuándo. print("done") simple no sobrevive a la búsqueda centralizada de logs.
Relacionados
- Conceptos Básicos de Automatización de Infraestructura - Fundamentos de IaC
- Testing Infrastructure Code - Puertas de CI y políticas
- Configuration Management - Configuración en capas y secretos
- Pulumi (IaC con Python) - Provisionamiento nativo de Python
- Provisioning Cloud Resources - Configuración repetible en la nube
Versiones de Stack: Esta página fue escrita 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+.