AAP 2.4 llegó al fin del soporte de mantenimiento el 30 de junio de 2026, según el anuncio de Red Hat. Tu automatización sigue funcionando, pero la cobertura cambia: ya no se aplican a 2.4 correcciones de errores ni parches de seguridad, y el riesgo operativo crece cada mes. Tienes dos caminos: actualizar a AAP 2.6 o, si no llegas a tiempo, hablar con tu equipo de cuenta sobre Extended Lifecycle Support (ELS). Esta entrada explica qué cambia, cómo planificar la actualización y qué conviene revisar primero.
Qué significa "fin de mantenimiento"
Según el anuncio de Red Hat, al terminar el soporte de mantenimiento:
- Ya no se aplican a 2.4 las correcciones de errores habituales ni los parches de seguridad (CVE).
- Puedes seguir abriendo casos de soporte, pero la solución de la mayoría será recomendar la actualización a una versión con soporte.
- No hay mejoras nuevas; estas ya terminaron al acabar el soporte completo.
La política de ciclo de vida de AAP divide la vida de una versión en soporte completo, Mantenimiento 1 y Mantenimiento 2, con un complemento de ciclo de vida extendido (ELS) aparte.
Para los equipos de operaciones, esto obliga a decidir cuánto tiempo puede seguir la automatización de producción en una versión envejecida. Seguridad tiene que valorar la exposición, y los responsables de servicio tienen que saber qué procesos de negocio dependen de ella. Si no puedes actualizar ya, confirma con Red Hat si tienes acceso a ELS, qué cubre y durante cuánto tiempo, como recomienda su página de actualización: no des por hecho que tu suscripción actual lo incluye.
Las opciones, en una tabla
| Opción | Qué implica | Cuándo encaja |
|---|---|---|
| Actualizar a AAP 2.6 | Ruta documentada por Red Hat desde 2.4 | Tienes ventana de cambio y entorno de pruebas |
| Ampliar con ELS | Cobertura extendida a través de tu equipo de cuenta de Red Hat | La actualización no cabe antes de tu siguiente ventana |
| No hacer nada | Sin correcciones nuevas para 2.4 | Solo como decisión consciente y con fecha |
Los términos y el precio de ELS dependen de tu contrato: Red Hat remite a tu equipo de cuenta, así que esta entrada no cita cifras.
Cómo planificar la actualización de 2.4 a 2.6
Empieza por saber qué tienes de verdad: versiones de cada componente, sistema operativo, base de datos, método de instalación, topología, integraciones y entornos de ejecución. Según la guía de actualización de AAP 2.6, primero hay que estar en la última versión de 2.4. La actualización directa a 2.6 se admite en instalaciones por RPM sobre RHEL 9 y en despliegues en OpenShift. Una instalación por RPM sobre RHEL 8 exige copiarla y restaurarla antes en hosts nuevos con RHEL 9, porque no se admite actualizar el sistema operativo de versión mayor en el mismo host. Tampoco se admite actualizar desde el despliegue contenerizado de 2.4 que se publicó como Technology Preview.
El plan tiene que incluir la pasarela de la plataforma (platform gateway): capacidad de infraestructura, acceso de red, certificados, autenticación y permisos. Según la misma guía:
- Revisa las configuraciones SAML: las claves privadas cifradas impiden migrar los autenticadores.
- Event-Driven Ansible 2.4 necesita un trato aparte: su base de datos no se puede migrar a 2.6 y hay que eliminarla antes de actualizar.
- Algunas API pasan a estar obsoletas en 2.6: revisa las integraciones y el uso de tokens frente a la versión de destino.
Ensaya en un entorno representativo, prueba la restauración y valida los trabajos críticos, las planificaciones, las credenciales, la sincronización de proyectos y el acceso de los usuarios. Mide por separado la preparación, la migración, la parada y la recuperación, y define antes los criterios de aceptación y los motivos para dar marcha atrás.
Después de la 2.6
Piensa ya en la siguiente actualización: según la guía de Red Hat, la 2.6 es la última versión para instalaciones por RPM, y pasar a la 2.7 o posterior exige migrar antes a un despliegue contenerizado o en OpenShift. La página de actualización añade que no hay ruta directa de 2.4 a 2.7.
Qué revisaría primero en tu entorno
Qué suele encontrar una revisión de ciclo de vida
Una revisión de ciclo de vida mira más allá de la versión de la plataforma. Estos son patrones que conviene investigar, no hallazgos de una organización concreta: entornos de ejecución anticuados, dependencias sin soporte, integraciones sin documentar y procedimientos que ya no coinciden con la configuración desplegada.
El soporte de cada componente puede diferir del de la plataforma. Por ejemplo, la página de ciclo de vida de Red Hat indica que ansible-core 2.15 deja de tener soporte después de junio de 2026, también para quien amplíe la cobertura de AAP 2.4, y recomienda pasar al menos a la 2.16. Las colecciones tienen además su propio ciclo de vida.
También conviene buscar copias de seguridad sin una restauración probada, permisos excesivos, cuentas de servicio sin responsable y trabajos críticos sin pruebas de regresión. El resultado útil es un registro de remediación priorizado: cada dependencia con su estado de soporte, su impacto en el negocio, su responsable y su fecha límite. Así la fecha de fin de mantenimiento se convierte en un plan de transición que se puede ejecutar.
Si no sabes qué versión tienes o nadie en tu equipo ha hecho una actualización de AAP, la revisión de ciclo de vida de RHEL y AAP cubre versiones, fechas de soporte, parcheo y playbooks en tres días.