De AWX a Ansible Automation Platform 2.7: lo que aprendí montando una PoC completa

Hace unos años implementé AWX sobre GKE (Kubernetes en Google Cloud) para automatizar una flota grande y heterogénea: servidores Linux de distintas distribuciones y versiones, y servidores Windows. Funcionó, y aprendí mucho operándolo, pero era "mi" AWX: virtualenvs armados a mano para cada combinación de versiones, credenciales que dependían de la disciplina del equipo, actualizaciones de la comunidad que había que probar con cuidado y una trazabilidad que se reconstruía a mano cuando alguien preguntaba qué había cambiado. Quería entender a fondo qué ofrece hoy Red Hat Ansible Automation Platform (AAP) frente a eso, y la única forma honesta de saberlo era montar una prueba de concepto completa, con mis manos y en mi propia nube: instalarla, configurarla, romperla y dejar todo escrito.

Este artículo resume qué construí, qué cambió desde AWX y, sobre todo, qué salió mal, porque ahí estuvo el verdadero aprendizaje.

Qué construí

• ·AAP 2.7 containerizado sobre RHEL en Google Cloud, en topología growth (todo en una VM), con tres servidores gestionados.
• ·Toda la infraestructura en Terraform, con pruebas de seguridad que fallan si alguien abre un puerto a internet.
• ·Toda la configuración de AAP como código: organización, equipos, usuarios, credenciales, inventarios, plantillas, workflows, RBAC y Event-Driven Ansible. Un solo comando reconstruye la plataforma.
• ·Siete casos de uso, cada uno con una prueba automática que lo verifica de extremo a extremo.

Qué cambió desde AWX

1. Un solo punto de entrada. AAP 2.5 introdujo el platform gateway: una sola UI, una sola autenticación y un solo RBAC para controller, hub y Event-Driven Ansible. Mi primer error fue suponer que el gateway escuchaba en el puerto 8446, porque así aparece en la documentación del instalador. La UI cargaba, pero todo lo demás devolvía 404. El punto de entrada real es Envoy en el 443; el 8446 es un backend interno. Lo encontré con un ss -ltnp y una consulta a la API del propio gateway.

2. Execution Environments en lugar de virtualenvs. Con AWX en GKE, mantener dependencias para Linux de varias versiones y para Windows (WinRM) era de las tareas más frágiles. Ahora cada job corre en una imagen de contenedor versionada. Construí la mía con ansible-builder, la publiqué en el hub privado y ahora puedo responder exactamente qué código corrió en cada job, algo que con virtualenvs nunca pude afirmar con certeza.

3. Dónde se instala. Mi AWX vivía en GKE porque el AWX Operator corre en cualquier Kubernetes. AAP con soporte solo corre sobre Kubernetes si ese Kubernetes es OpenShift; en GKE, EKS o AKS no tiene soporte. La alternativa, y la que usé en la PoC, es la instalación containerizada en RHEL: el instalador RPM quedó deprecado. Ahora todo corre en Podman sin root, gestionado por systemd, y vuelve a levantar solo después de un reinicio.

4. Event-Driven Ansible. Esto no existía en AWX. Detuve nginx a mano en un servidor y, unos 90 segundos después, AAP lo había reparado solo, con una cuenta de servicio que solo tiene permiso para esa remediación.

Los siete casos

• ·Inventario dinámico de GCP sin llaves JSON: Los servidores se agrupan solos por etiquetas; el que se apaga desaparece
• ·Hardening CIS con evidencia: Medición antes y después con OpenSCAP; reportes en almacenamiento independiente
• ·Parcheo con aprobación: Quien ejecuta no puede aprobar; si algo falla, rollback automático y prod intacto
• ·RBAC por equipos: Operaciones ejecuta, Seguridad aprueba, Auditoría solo lee
• ·Execution Environment propio: En el hub privado, sin secretos dentro de la imagen
• ·Remediación por eventos: Servicio caído → reparado sin intervención humana
• ·Trazabilidad: El auditor exporta quién ejecutó y quién aprobó cada cambio

Lo que salió mal (y por qué me alegro)

Estos son los errores que más me enseñaron:

Un token expuesto en un log. Al construir el Execution Environment pasé el token de Automation Hub como argumento de línea de comandos. Con verbosidad alta, la herramienta imprimió el comando completo, token incluido, y el log terminó donde no debía. Lo contuve (borré las copias), lo revoqué y generé uno nuevo. La regla que me quedó es simple: un secreto nunca va en la línea de comandos. Va en variables de entorno o en archivos de un solo uso, y los logs se filtran donde se generan y donde se leen.

El auditor que veía cero. Asigné el rol "Organization Auditor" al equipo de auditoría. La API respondía 200, la prueba pasaba... y el auditor no veía nada. AAP 2.7 tiene dos roles casi homónimos: Organization Audit (el que sirve) y Organization Auditor. La lección no fue el rol, sino la prueba: una prueba que solo mira el código HTTP puede dar un falso verde. Ahora verifico el contenido.

El rollback que no pudo volver atrás. Forcé un fallo en el parcheo para probar el rollback. El rollback corrió... y falló: uno de los 18 paquetes venía de un repositorio que solo conserva la última versión. El rollback por paquetes depende de los repositorios. En producción, un snapshot de disco antes de parchear no es opcional.

El rollback que podía hacer daño. Antes de que nada fallara, diseñé el rollback para que nunca deshaga una transacción que no creó el propio parcheo. Un dnf history undo last ingenuo puede revertir una instalación legítima de hace días. Lo probé explícitamente: sin cambios nuevos, el rollback no toca nada.

Cuando la documentación no coincide con el código. Una de las colecciones oficiales ignoraba las variables de entorno que su propia documentación describía, y además leía variables sin renderizar las plantillas Jinja. La solución estuvo en leer el código del plugin. La tentación era pasar la contraseña con -e en la línea de comandos; no lo hice, por la lección del token.

Mi red tiene cuatro IPs públicas. Restringí la consola a "mi IP /32" y de un día para otro dejó de responder. Mi red sale por varias IPs públicas balanceadas. Terminé permitiendo dos rangos /28, validados por Terraform.

Decisiones que llevaría tal cual a producción

• ·Cero llaves de larga duración: identidades de nube desde el metadata server, cuentas de servicio para el registry de Red Hat, la suscripción y las integraciones.
• ·Configuración como código e idempotente: la segunda ejecución debe decir changed=0. Un "changed" falso ensucia la trazabilidad.
• ·Mínimo privilegio a nivel de objeto y cuentas de servicio por integración.
• ·Listas de servicios permitidos en las remediaciones por eventos, en la regla y otra vez en el playbook.
• ·Evidencia fuera de la plataforma, en almacenamiento independiente y con retención.

Lo que haría distinto en producción

La PoC es una VM. Producción es otra cosa: topología enterprise con dos nodos por componente, base de datos externa con alta disponibilidad, Redis en clúster, almacenamiento compartido para el hub y un balanceador interno. A eso se suman la integración con el directorio corporativo, el ITSM, el SIEM y un vault de secretos. Lo que agrega esa topología está descrito al final del README del blueprint, y es mi siguiente ejercicio.

Un blueprint para reutilizar

Toda la PoC (Terraform, instalación, configuración como código, playbooks, rulebooks, pruebas automáticas, la guía paso a paso y lo que agrega la topología enterprise) está publicada como un blueprint reutilizable y parametrizado, para que cualquier equipo pueda montar el mismo laboratorio en su propio proyecto de nube: platform-blueprints/automation/aap.

Cierre

Lo más valioso de esta PoC no es que funcione, sino lo que se rompió por el camino. Los quince errores que más tiempo me costaron están en el README del blueprint, cada uno contado como qué pasa y qué hacer.

Si estás evaluando AAP, mi consejo es el mismo que me di a mí: móntalo tú mismo, rómpelo, y escribe todo.