Planificación de tu actualización a Ansible Automation Platform 2.6

El lanzamiento de Red Hat Ansible Automation Platform 2.6 marca un hito fundamental. Antes de comenzar tu actualización, hay tres aspectos clave que tienes que conocer para que tu transición sea más sencilla:

• Esta es la última versión con un instalador basado en RPM. Red Hat Ansible Automation Platform 2.6 con el método RPM solo está disponible para Red Hat Enterprise Linux (RHEL) 9, y el instalador RPM se retirará después de este lanzamiento. Ansible Automation Platform 2.7 solo admitirá un método de instalación en contenedores, el operador de Red Hat OpenShift o nuestros servicios de nube, así que ahora es el momento de comenzar la transición.
• Ansible Automation Platform 2.6 es una versión fundamental. Cada ruta de actualización a las versiones futuras de la plataforma debe pasar por la versión 2.6. No hay forma de evitarlo.
• RHEL 8 ya no es compatible. Si todavía utilizas RHEL 8, tendrás que migrar a RHEL 9 (o RHEL 10) antes de actualizar a Ansible Automation Platform 2.6.

Planificación de tu actualización

A medida que planificas tu transición a Ansible Automation Platform 2.6, dos consideraciones importantes deben dar forma a tu plan de actualización:

Solo se puede cambiar una cosa a la vez. Ya sea el sistema operativo (SO) subyacente, el método de instalación o la versión del producto, el instalador solo gestiona un cambio por ejecución. Eso significa que es posible que tengas que ejecutarlo varias veces. Consulta la documentación oficial para obtener más información al respecto.

En la mayoría de los casos, necesitarás una instalación nueva. Fuera de algunos casos específicos, como la actualización de la versión 2.5 a la 2.6 en la misma arquitectura o ciertas implementaciones del operador de Red Hat OpenShift, tendrás que implementar una nueva instancia de Ansible Automation Platform 2.6 y luego migrar tu configuración a ella.

Esto plantea la pregunta clave: ¿Cómo incorporas tu configuración actual a la nueva instancia? La respuesta comienza al comprender que la configuración de Ansible Automation Platform reside en una base de datos PostgreSQL. Tu estrategia de actualización trata sobre cómo trasladas esos datos.

Enfoques para la actualización

Hay dos rutas para Ansible Automation Platform 2.6: una migración centrada en la base de datos o una migración centrada en las API. La elección correcta depende de tu entorno, tus requisitos y lo que estés dispuesto a sacrificar.

Un enfoque centrado en la base de datos trata a Ansible Automation Platform como un sistema con estado en el que los datos son la fuente de verdad. Un enfoque centrado en las API trata a la plataforma como configuración como código (CaC), donde la fuente de verdad se encuentra en los archivos de configuración. Consulta la siguiente tabla para evaluar las consideraciones técnicas de cada enfoque:

Migraciones centradas en la base de datos

Las migraciones centradas en las bases de datos son el camino documentado y con soporte completo que conserva y migra toda tu base de datos durante el proceso de actualización. ¿Cuál es el desafío? El "baile de las actualizaciones" Puedes pasar de RHEL 8 a RHEL 9, de RPM a contenedores y de Ansible Automation Platform 2.4 o 2.5 a 2.6; cada uno de estos es un paso independiente que requiere su propia infraestructura. 

Esto representa potencialmente muchos entornos intermedios que debes preparar y gestionar. Según el punto de partida y el objetivo final de las iniciativas de migración, así como la escala del entorno (y, por lo tanto, el tamaño de la base de datos), puede ser una tarea que consuma mucho tiempo.

Una advertencia importante: Si esta complejidad te impulsa a optar por las ofertas de servicios de nube gestionados de Ansible Automation Platform, ten en cuenta que para cargar una base de datos en los servicios gestionados, necesitarás una solicitud de soporte. Puedes encontrar este proceso documentado aquí. Para que lo hagas tú mismo, deberás utilizar el enfoque centrado en la API.

Migración centrada en la API

Red Hat no ofrece soporte oficial para este enfoque (aunque sí admite los componentes individuales que permiten esta técnica de migración). Dicho esto, puede ser mucho más rápido, especialmente para entornos grandes. Como se trata de un solo traslado a la plataforma de destino, no son necesarias las instalaciones intermedias.

En este método, exportarías la configuración de tu Ansible Automation Platform mediante llamadas a la API para almacenarla de forma local, como en archivos de configuración o en una base de datos temporal. Puedes modificar estos archivos según sea necesario y, luego, restaurarlos también a través de la API en otra plataforma. Este método también tiene un beneficio adicional interesante: Incorpora la configuración como código (CaC) en tu flujo de trabajo. Esto te brinda una base para gestionar la plataforma con métodos de CaC en el futuro.

¿Cuáles son las desventajas? Perderás el historial de tareas (lo cual se mitiga con un agregador de registros externo) y tendrás que manejar los secretos con cuidado (lo cual se mitiga con un administrador de secretos externo). También es posible que debas editar los archivos de configuración exportados para que tengan el formato correcto para la importación, especialmente para los objetos de private automation hub y Event-Driven Ansible.

Una nota sobre los secretos

Los secretos de credenciales y notificaciones se almacenan en la base de datos de configuración y se cifran con la SECRET_KEY de la base de datos. Como están cifrados, sus valores no se exportan en absoluto a través de la API. Por lo tanto, para obtener acceso a los secretos de tu configuración, se requiere acceso de superusuario al servidor de la base de datos. Dado que esto expondría tus secretos en texto sin formato, deberás manejarlos con mucho cuidado, como volver a cifrarlos en un Ansible vault. 

Sin embargo, si usas un administrador de secretos externo, como HashiCorp Vault, esto no será un problema, ya que esos secretos no residen en Ansible Automation Platform. Por otro lado, si solo hay que gestionar unos pocos secretos, puede ser igual de sencillo completar los secretos en la nueva plataforma.

Consideraciones para ambos métodos

Independientemente del camino que elijas, ten en cuenta lo siguiente: Es probable que debas prestar atención a las integraciones externas y los tokens de API. 

Ansible Automation Platform 2.5 introdujo la puerta de enlace de automatización, un frontend unificado que conecta el controlador de automatización, Ansible automation hub y el controlador de Event-Driven Ansible en una sola interfaz. Esto desplazó muchos endpoints de la API hacia nuevas rutas. Si bien se mantiene la compatibilidad con versiones anteriores de estos endpoints de integración para la versión 2.6, tendrás que actualizarlos para versiones futuras. Además, tendrás que volver a generar y redistribuir la mayoría de los tokens que emite la plataforma, aprovisionar servidores adicionales y actualizar los equilibradores de carga al nuevo servicio de puerta de enlace.

Bases de datos gestionadas de forma externa

Para los clientes con bases de datos gestionadas de forma externa, existen consideraciones adicionales.  En primer lugar, Red Hat Ansible Automation Platform 2.4 utiliza Postgres 13. Esta se actualiza a Postgres 15 para la versión 2.5 y a PostgreSQL 15 para la versión 2.6. También existe soporte para bases de datos de PostgreSQL 16 y 17 proporcionadas por el cliente en Red Hat Ansible Automation Platform 2.6. Este procedimiento de actualización de la base de datos es un aspecto clave en la migración y el proceso de actualización; además, explica por qué los clientes no pueden reutilizar su base de datos actual sin pasar por este proceso de actualización.  Específicamente para Red Hat Ansible Automation Platform 2.5 y versiones posteriores, debes habilitar los International Components for Unicode (ICU) en las bases de datos proporcionadas por el cliente. Esta opción está disponible, pero no habilitada de manera predeterminada, en la mayoría de los proveedores de bases de datos principales, como EDB, Amazon Web Services Relational Database Service (AWS RDS) y Azure SQL Database. Esta compatibilidad de las bases de datos es la razón por la cual no podemos simplemente actualizar el esquema en una base de datos existente.

Compatibilidad con los playbooks

Cuando actualizas Red Hat Ansible Automation Platform, también se actualiza la versión de ansible-core que se incluye en el entorno de ejecución predeterminado. La buena noticia es que siempre puedes ejecutar entornos de ejecución más antiguos en versiones más nuevas de la plataforma para mantener la compatibilidad con versiones anteriores. Sin embargo, te recomendamos encarecidamente actualizar para aprovechar las nuevas funciones y las correcciones de seguridad.

Si actualizas tus entornos de ejecución, estarás actualizando a una nueva versión de ansible-core, lo cual puede generar algunos cambios.  Esto es lo que puedes esperar:

Red Hat Ansible Automation Platform 2.4 pasa a 2.6 (ansible-core 2.15 pasa a 2.16)

Esta es una actualización menor. El cambio más notable es que ahora algunas advertencias en las declaraciones condicionales se tratan como errores. Más allá de eso, el impacto es mínimo.

Migración a ansible-core 2.18 (entorno de ejecución opcional en Red Hat Ansible Automation Platform 2.6) Esta actualización, que es un entorno de ejecución opcional y compatible para Red Hat Ansible Automation Platform 2.6, aporta cambios significativamente mayores. En concreto:

• Python 2.7 y 3.6 en los nodos de destino ya no son versiones compatibles. Esto significa que ya no puedes utilizar este entorno de ejecución con hosts de RHEL 6. Los hosts de RHEL 7 necesitarán Python 3.8 (disponible a través de Red Hat Software Collections) para automatizarse con Red Hat Ansible Automation Platform.
• Python 3.11 es ahora la versión de Python incluida en tu entorno de ejecución. Debes actualizar las bibliotecas de Python personalizadas y de terceros a bibliotecas compatibles con la versión 3.11.
• La limpieza de las "dead batteries" de Python está en marcha. PEP 594 eliminará de la biblioteca estándar las bibliotecas sin mantenimiento, poco seguras y obsoletas en las próximas versiones de Python. Las advertencias de desuso comienzan con Python 3.11; algunas bibliotecas se eliminan en la versión 3.12, y la eliminación masiva ocurre en la versión 3.13.

Para la gran mayoría de los clientes, esta no es una preocupación inmediata, pero vale la pena que prestes atención a las advertencias de desuso ahora para que te puedas preparar.

Para obtener toda la información sobre las versiones de ansible-core compatibles, consulta la política de soporte oficial de Red Hat .

La transición a Ansible Automation Platform 2.6 es más que una simple actualización de versión: es un movimiento estratégico que sienta las bases para la próxima generación de automatización. Si eliges el plan de migración que mejor se adapte a tu infraestructura actual, puedes mantener la resiliencia de tu automatización, centrarte en la seguridad y estar listo para lo que venga después.

Recursos adicionales

• Artículo: Automatización de las actualizaciones de Ansible Automation Platform 2.6 con Python, AsyncIO y operaciones masivas
• Notas de la versión de Ansible Automation Platform y documentación.
• Novedades de Ansible Automation Platform