Migración de aplicaciones de JBoss EAP a Red Hat OpenShift en Azure

  • Artículo

En esta guía se describe lo que debe tener en cuenta cuando quiera migrar una aplicación JBoss EAP existente para que se ejecute en Red Hat OpenShift en Azure.

Antes de la migración

Para asegurarse de que la migración se realiza correctamente, antes de empezar, complete los pasos de evaluación e inventario descritos en las secciones siguientes.

Asegúrese de que el destino es el destino adecuado para el esfuerzo de migración.

El primer paso en una migración correcta de una aplicación de JBoss EAP a Azure está seleccionando el destino de migración más adecuado. JBoss EAP funciona bien en máquinas virtuales (VM) de Azure o Red Hat OpenShift en Azure.

El destino de la máquina virtual es la opción más sencilla, ya que se parece más a una implementación local. La experiencia administrativa e de implementación de las máquinas virtuales es análoga a lo que tiene en el entorno local. La selección de máquinas virtuales le permite aplazar la modernización.

Red Hat OpenShift reúne servicios probados y de confianza para reducir la fricción del desarrollo, modernización, implementación, ejecución y administración de aplicaciones. Red Hat OpenShift en Azure se basa en Kubernetes. Red Hat OpenShift en Azure ofrece una experiencia coherente en la nube pública, en el entorno local, en la nube híbrida o en la arquitectura perimetral.

Si minimizar el cambio es el factor más importante para el esfuerzo de migración, considere la posibilidad de realizar una migración basada en máquinas virtuales. En este caso, consulte Migración de aplicaciones de JBoss EAP a JBoss EAP en máquinas virtuales de Azure. Si puede tolerar la conversión de la aplicación para que se ejecute en Red Hat OpenShift para reducir el costo en tiempo de ejecución, considere la posibilidad de realizar una migración basada en Red Hat OpenShift en Azure. En este caso, continúe con Migración de aplicaciones de JBoss EAP a JBoss EAP en Red Hat OpenShift en Azure. Para comprender las diferencias entre JBoss EAP y JBoss EAP para OpenShift, consulte Comparación: JBoss EAP y JBoss EAP para OpenShift.

Determinar si la oferta de Azure Marketplace precompilada es un buen punto de partida

En primer lugar, decida que Red Hat OpenShift en Azure es el destino de implementación adecuado. A continuación, decida si la oferta precompilada de Azure Marketplace es un buen punto de partida. Tenga en cuenta los siguientes puntos sobre la oferta precompilada de Azure Marketplace:

  • Red Hat y Microsoft crearon esta oferta para permitir el aprovisionamiento rápido de JBoss EAP en Red Hat OpenShift en Azure.
  • En un nivel alto, la oferta automatiza los pasos siguientes.
    • Instale el operador EAP en Red Hat OpenShift en Azure.
    • Compile una imagen de aplicación mediante la plantilla eap-s2i-build. Para obtener más información sobre el origen a la imagen (S2I), consulte Uso de OpenJDK 11 source-to-image para OpenShift.
    • Implemente la aplicación Java mediante el operador EAP. Para obtener más información, consulte la documentación de referencia para el operador EAP en Red Hat.

Si no usa la oferta precompilada de Azure Marketplace, debe aprender a usar el operador EAP directamente. Dominar el operador está fuera del ámbito de este artículo. La documentación completa del operador EAP está disponible en Red Hat.

En el resto de esta sección se proporcionan algunas consideraciones para decidir usar la oferta precompilada de Azure Marketplace o el operador directamente.

Determinar si la versión de JBoss EAP es compatible

La versión existente de JBoss EAP debe ser una de las versiones compatibles con el operador . Para obtener más información, consulte Compatibilidad de versiones y soporte técnico en la documentación de Red Hat.

Capacidad del servidor de inventario

Documente el hardware (memoria, CPU, disco) de los servidores de producción actuales, así como el promedio y máximo del número de solicitudes y el uso de recursos. Necesita esta información independientemente de la ruta de migración que elija. Los siguientes aspectos, y mucho más, se benefician de tener un inventario detallado de la capacidad del servidor.

  • Para ayudar a guiar la selección del tamaño de las máquinas virtuales del grupo de nodos.
  • Para comprender la cantidad de memoria que va a usar el contenedor.
  • Para saber cuántos recursos compartidos de CPU necesita el contenedor.

Es posible cambiar el tamaño de los grupos de nodos en Red Hat OpenShift en Azure. Para más información, consulte Cambio del tamaño de un clúster de Microsoft Azure en la documentación de Red Hat.

Inventario de todos los secretos

Antes de la llegada de las tecnologías de "configuración como servicio", como Azure Key Vault, no había un concepto bien definido de "secretos". En su lugar, hay un conjunto dispar de opciones de configuración que funcionaban de forma eficaz como lo que ahora llamamos "secretos". Con los servidores de aplicaciones como JBoss EAP, estos secretos se encuentran en muchos archivos y almacenes de configuración diferentes. Compruebe los secretos y las contraseñas en todas las propiedades y los archivos de configuración de los servidores de producción. Asegúrese de comprobar los archivos de configuración como custom-config.xml o jboss-web.xml en las aplicaciones. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. Para más información, consulte Conceptos básicos de Azure Key Vault.

Una vez que tenga un inventario sólido de secretos, consulte la documentación del operador de EAP con respecto a los secretos. Para obtener más información, consulte Creación de un secreto en la documentación de Red Hat.

Inventario de todos los certificados

Documente todos los certificados usados para los puntos de conexión SSL públicos. Para ver todos los certificados de los servidores de producción, ejecute el siguiente comando:

keytool -list -v -keystore <path to keystore>

Una vez que tenga un inventario sólido de certificados, puede configurarlos en Red Hat OpenShift en Azure. Para más información, consulte Configuración de TLS en OpenShift Container Platform(replace) en la documentación de Red Hat.

Comprobación de que la versión compatible de Java funciona correctamente

Todas las rutas de migración de JBoss EAP a Red Hat OpenShift en Azure requieren una versión específica de Java, que varía para cada ruta de acceso. Debe validar que la aplicación puede ejecutarse correctamente con esa versión compatible.

Nota:

Esta validación es especialmente importante si el servidor actual se está ejecutando en un JDK no compatible (como Oracle JDK o IBM OpenJ9).

Para obtener la versión actual de Java, inicie sesión en el servidor de producción y ejecute el siguiente comando:

java -version

Inventario de los recursos de JNDI

Realice un inventario de todos los recursos de JNDI. Por ejemplo, los orígenes de datos tales como las bases de datos pueden tener un nombre de JNDI asociado que permita a JPA enlazar correctamente instancias de EntityManager con una base de datos determinada. Para obtener más información sobre los recursos y las bases de datos de JNDI, consulte Administración de orígenes de datos en la documentación de Red Hat. Otros recursos relacionados con JNDI, como los agentes de mensajes ActiveMQ Artemis, pueden requerir migración o reconfiguración. Para obtener más información sobre la configuración de ActiveMQ Artemis, consulte Configuración de mensajería en la documentación de Red Hat.

Determinación de si se usa la replicación de sesión

Si la aplicación se basa en la replicación de sesión, con o sin Infinispan, tiene tres opciones:

  • Infinispan funciona bien en máquinas virtuales de Azure, pero si usa un perfil que proporciona funcionalidades de alta disponibilidad, tenga en cuenta la configuración de JGroups . Determine si el sistema funciona como un dominio administrado o un servidor independiente.
    • Si se encuentra en un dominio administrado, los perfiles de alta disponibilidad o alta disponibilidad se ocupan de JGroups.
    • Si se encuentra en un servidor independiente, los archivos de configuración standalone-ha.xml o standalone-full-ha.xml se ocupan de JGroups.
    • Microsoft Azure no admite protocolos de detección de JGroups basados en multidifusión UDP. Para más información, consulte Uso de la alta disponibilidad de JBoss EAP en Microsoft Azure en la documentación de Red Hat.
  • Refactorice la aplicación para utilizar una base de datos para la administración de sesiones.
  • Refactorice la aplicación para externalizar la sesión en el servicio Azure Redis. Para más información, consulte Azure Cache for Redis.

Para todas estas opciones, es una buena idea dominar cómo JBoss EAP realiza la replicación de estado de sesión HTTP. Para obtener más información, consulte Acerca de la replicación de sesión HTTP en la documentación de Red Hat.

Orígenes de datos de documentos

Si su aplicación usa bases de datos, debe capturar la siguiente información:

  • ¿Cuál es el nombre del origen de datos?
  • ¿Cuál es la configuración del grupo de conexiones?
  • ¿Dónde puedo encontrar el archivo JAR del controlador JDBC?

Para obtener más información sobre los controladores JDBC en JBoss EAP, consulte Administración de orígenes de datos en la documentación de Red Hat.

Determinar si JBoss EAP se ha personalizado

Determine cuáles de las siguientes personalizaciones se han realizado y capture lo que se ha hecho.

  • ¿Se han cambiado los scripts de inicio? Estos scripts incluyen host, eap_env, independiente y dominio.
  • ¿Se han pasado parámetros específicos a JVM?
  • ¿Se han agregado archivos JAR a la ruta de clases del servidor?

Estas personalizaciones deben capturarse en la imagen de contenedor que se ejecuta en Red Hat OpenShift en Azure. Para obtener más información, consulte Configuring the JBoss EAP for OpenShift Image for Your Java Application en la documentación de Red Hat.

Determinación de si se necesita una conexión al entorno local

Si su aplicación necesita acceder a cualquiera de los servicios locales, deberá aprovisionar uno de los servicios de conectividad de Azure. Para obtener más información, consulte. Elección de una solución para conectar una red local a Azure. También tendrá que refactorizar la aplicación para que use las API disponibles públicamente que exponen los recursos locales.

Determinación de si las colas o los temas de Java Message Service (JMS) están en uso

Si la aplicación usa colas o temas de JMS, es posible que quiera migrarlas a un servidor JMS hospedado externamente. Azure Service Bus y Advanced Message Queuing Protocol pueden ser una estrategia de migración excelente para los usuarios que usan JMS. Para más información, consulte Uso de JMS con Azure Service Bus y AMQP 1.0.

Si se han configurado almacenes persistentes de JMS, debe capturar su configuración y aplicarla después de la migración.

Para obtener más información, consulte Configuración de mensajería en la documentación de Red Hat.

Determinación de si usa sus propias bibliotecas de Java EE compartidas personalizadas

Si utiliza la característica de biblioteca de Java EE compartida, tiene dos opciones:

  • Refactorizar el código de la aplicación para quitar todas las dependencias de las bibliotecas y, en su lugar, incorpore la funcionalidad directamente a la aplicación.
  • Agregar las bibliotecas a la ruta de clases del servidor.

Puede controlar estas bibliotecas con las mismas técnicas que se describen en la sección Determinar si JBoss EAP se ha personalizado .

Determinación de si la aplicación contiene código específico del sistema operativo

Si la aplicación contiene código con dependencias en el sistema operativo host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, puede que necesite reemplazar el uso de / o \ en las rutas de acceso del sistema de archivos por File.Separator o Paths.get.

Red Hat OpenShift en Azure se ejecuta en OpenShift 4 con Red Hat Enterprise Linux CoreOS (RHCOS) como sistema operativo para todos los nodos de trabajo y del plano de control. Cualquier código específico del sistema operativo debe ser compatible con RHCOS.

Determinación de si la aplicación se compone de varios WAR

Si la aplicación se compone de varios WAR, debe tratar cada uno como aplicaciones independientes y seguir esta guía para cada una de ellas.

Determinación de si la aplicación está empaquetada como EAR

Si la aplicación está empaquetada como un archivo EAR, asegúrese de capturar sus configuraciones.

Identificación de todos los procesos externos y los demonios que se ejecutan en los servidores de producción

Si tiene procesos que se ejecutan fuera del servidor de aplicaciones, como los demonios de supervisión, tendrá que eliminarlos o migrarlos a otro lugar.

Requisitos del equilibrio de carga

La mejor manera de tener en cuenta el equilibrio de carga es usar la integración de App Gateway. Para más información, consulte ¿Qué es Azure Application Gateway?.

Migración

En los pasos de esta sección se supone que el análisis le ha llevado a decidir usar la oferta precompilada de Azure Marketplace.

Aprovisionamiento de la oferta

Para abrir la oferta en Azure Portal, consulte JBoss EAP en Red Hat OpenShift en Azure. Seleccione Crear y siga las instrucciones de la oferta.

Migración de las aplicaciones

La oferta admite el proceso de origen a imagen (S2I) para compilar y ejecutar una aplicación Java en la imagen de JBoss EAP para OpenShift. Red Hat tiene un ejemplo que muestra cómo hacerlo manualmente si desea realizar la implementación más adelante por su cuenta. Para obtener más información, consulte el capítulo 2. Compile y ejecute una aplicación Java en JBoss EAP for OpenShift Image en la documentación de Red Hat.

Después de la migración

Una vez alcanzados los objetivos de migración que se han definido antes de la migración, realice pruebas integrales de aceptación para comprobar que todo funciona según lo previsto. Para obtener información sobre algunas posibles mejoras posteriores a la migración, consulte los siguientes artículos: