Ansible Automation Platform 2.7: seis decisiones antes de saltar de version

Red Hat ha publicado la segunda parte de su guía para actualizar a Ansible Automation Platform 2.7, y el aviso central no va de funciones nuevas sino de cómo planificar el salto: según la instalación de partida puede ser una tarde de trabajo o varias semanas de migración. La versión añade orquestación de IA a través de un servidor MCP, un constructor visual de entornos de ejecución y autenticación OIDC nativa contra Hashicorp Vault. Quien siga instalando Ansible desde paquetes RPM en las ramas 2.4 o 2.5 es justo el perfil al que apunta el texto.

Tres modelos de despliegue

El primer punto que hay que cerrar es dónde vive la plataforma. Red Hat plantea tres caminos: autogestionado sobre máquinas virtuales con RHEL, para quien quiere control total y aprovechar su experiencia operativa; gestionado por operador sobre OpenShift o Kubernetes, con la escalabilidad y la resiliencia del orquestador de contenedores; o servicio gestionado en Azure o AWS, donde Red Hat pone sus propios SRE y el cliente se queda solo con el contenido de automatización.

Los tres conviven sin problema. Los entornos de ejecución mantienen el mismo comportamiento del contenido sobre cualquiera de ellos, y desarrollo y producción no tienen por qué ser idénticos. Definir los despliegues como infraestructura como código es lo que da repetibilidad.

Entornos, resiliencia y secretos

El segundo eje es la estrategia de entornos. Con el contenido de automatización creciendo en complejidad, tener pruebas fuera de producción deja de ser opcional. La guía admite que no hay fórmula única: una plataforma de producción multiinquilino con automation mesh para separar redes, o varias plataformas distribuidas. El criterio es cuántas aportan valor real frente al coste de operarlas, y ahí entran también las infraestructuras de prueba efímeras.

El tercero es disponibilidad y recuperación ante desastres. La automatización ha pasado de utilidad de apoyo a infraestructura crítica, así que eliminar puntos únicos de fallo, decidir el failover y fijar objetivos de tiempo de recuperación se vuelven obligatorios. Algunos lo resolverán en la base de datos; otros, con Configuration as Code. El enfoque depende del modelo de despliegue elegido antes.

El cuarto punto es la gestión de secretos: cifrado nativo de Ansible o un proveedor externo. La 2.7 se integra con Hashicorp Vault mediante OIDC, y hay una guía aparte sobre acceso just-in-time a Vault en la documentación para desarrolladores.

Ahí se corta el texto publicado, que anunciaba seis decisiones y solo desarrolla cuatro. Es material de Red Hat sobre su propio producto, sin comparativas ni cifras de rendimiento, y de momento no hay más demostración del servidor MCP que un vídeo colgado por la compañía. Para quien tenga que mover una instalación RPM de 2.4 o 2.5, la lista de comprobaciones es razonable antes de tocar nada.