Compartir vía

Migración de aplicaciones de WebSphere a JBoss EAP en Azure App Service

  • Artículo

En esta guía se describe lo que hay que tener en cuenta para migrar una aplicación de WebSphere existente para que se ejecute en Azure App Service mediante JBoss EAP.

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.

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. Necesitará esta información independientemente de la ruta de migración que elija. Es útil, por ejemplo, para ayudar a orientar la selección del plan de App Service.

La lista de niveles disponibles del plan de App Service muestra la información sobre memoria, núcleos de CPU, almacenamiento y precios. Tenga en cuenta que JBoss EAP en App Service solo está disponible en los niveles Premium V3 y Isolated V2 del plan de App Service.

Inventario de todos los secretos

Compruebe los secretos y las contraseñas en todas las propiedades y los archivos de configuración de los servidores o servidores de producción. Asegúrese de comprobar ibm-web-bnd.xm en sus archivos WAR. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. Estos archivos pueden incluir, para las aplicaciones de Spring Boot, archivos application.properties o application.yml.

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>

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

JBoss EAP en Azure App Service es compatible con Java 8 y 11. Por lo tanto, deberá comprobar que la aplicación puede ejecutarse correctamente con esa versión compatible. Esta validación es especialmente importante si el servidor actual se está utilizando un JDK 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. Algunos recursos, como los agentes de mensajes JMS, pueden requerir una migración o reconfiguración.

Dentro de la aplicación

Inspeccione el archivo WEB-INF/ibm-web-bnd.xml o el archivo WEB-INF/web.xml.

Determine si se usan bases de datos

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

  • El nombre de la fuente de datos.
  • La configuración del grupo de conexiones.
  • La ubicación del archivo JAR del controlador JDBC.

Determinación de si se usa el sistema de archivos y cómo

Para usar el sistema de archivos en el servidor de aplicaciones será necesario cambiar la configuración o, en raras ocasiones, la arquitectura. Los módulos compartidos de WebSphere o el código de su aplicación pueden usar el sistema de archivos. Puede identificar algunos o todos los escenarios siguientes.

Contenido estático de solo lectura

Si su aplicación actualmente sirve contenido estático, necesitará una ubicación alternativa para él. Quizás quiera considerar la posibilidad de mover el contenido estático a Azure Blob Storage y agregar Azure CDN para tener descargas de alta velocidad globalmente. Para más información, consulte Hospedaje de sitios web estáticos en Azure Storage e Inicio rápido: Integración de una cuenta de una instancia de Azure Storage con Azure CDN. También puede implementar directamente el contenido estático en una aplicación en el plan Enterprise de Azure Spring Apps. Para obtener más información, consulte Implementación de archivos estáticos web.

Contenido estático publicado dinámicamente

Si su aplicación permite que haya contenido estático que la aplicación carga o produce, pero que es inmutable una vez creado, puede usar Azure Blob Storage y Azure CDN con una función de Azure para controlar las cargas y la actualización de la red CDN. Hemos proporcionado una implementación de ejemplo para su uso en Cargar y carga previa en CDN de contenido estático con Azure Functions. También puede implementar directamente el contenido estático en una aplicación en el plan Enterprise de Azure Spring Apps. Para obtener más información, consulte Implementación de archivos estáticos web.

Contenido dinámico o interno

En el caso de los archivos que la aplicación lee y escribe con frecuencia (por ejemplo, los archivos de datos temporales) o los archivos estáticos que solo son visibles para la aplicación, puede montar recursos compartidos de Azure Storage en su sistema de archivos de App Service. Para obtener más información, consulte Montaje de Azure Storage como un recurso compartido local en App Service.

Determinación de si la aplicación se basa en trabajos programados

Los trabajos programados, como las tareas del programador de Quartz o los trabajos de cron de Unix, NO se deben usar con Azure App Service. App Service no le impedirá implementar una aplicación que contenga internamente tareas programadas. Sin embargo, si la aplicación se escala horizontalmente, un mismo trabajo programado se podría ejecutar más de una vez por cada período programado. Esta situación puede tener consecuencias no deseadas.

Para ejecutar trabajos programados en Azure, considere la posibilidad de usar Azure Functions con un desencadenador de temporizador. Para más información, consulte Desencadenador de temporizador de Azure Functions. No es necesario migrar el propio código de trabajo a una función. La función simplemente puede invocar una dirección URL en la aplicación para desencadenar el trabajo.

Nota:

Para evitar el uso malintencionado, asegúrese de que el punto de conexión de invocación del trabajo requiera credenciales. En este caso, la función de desencadenador deberá proporcionar las credenciales.

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 más información, consulte Connect an on-premises network to Azure (Conexión de 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 utiliza colas o temas de JMS, deberá migrarlos a un servidor de JMS hospedado externamente. Azure Service Bus y Advanced Message Queuing Protocol (AMQP) pueden ser una estrategia de migración excelente para los usuarios que usan JMS. Para obtener más información, consulte Uso de Java Message Service 1.1 con Azure Service Bus estándar 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.

Determinación de si la aplicación usa API específicas de WebSphere

Si su aplicación utiliza API específicas de WebSphere, necesitará refactorizar su aplicación para NO utilizarlas. El Red Hat Migration Toolkit for Apps puede ayudarle a eliminar y refactorizar estas dependencias.

Determinación de si las aplicaciones usa beans de Entity o beans de CMP del estilo de EJB 2.x.

Si su aplicación usa beans de Entity o de CMP del estilo de EJB 2.x, debe refactorizar la aplicación para quitar estas dependencias.

Determinación de si se usa la característica de cliente de aplicación de Java EE

Si tiene aplicaciones cliente que se conectan a la aplicación (servidor) mediante la característica de cliente de aplicación de Java EE, deberá refactorizar las aplicaciones cliente y la aplicación (servidor) para que usen las API HTTP.

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.

Determinación de si los temporizadores de EJB están en uso

Si la aplicación usa temporizadores de EJB, deberá validar que cada instancia de JBoss EAP pueda desencadenar el código del temporizador de EJB de manera independiente. Esta validación es necesaria porque cuando su App Service se escala horizontalmente, cada temporizador EJB se activará en su propia instancia JBoss EAP.

Determinación de si se están usando conectores de JCA

Si su aplicación usa conectores de JCA, tendrá que validar que el conector de JCA se puede usar en JBoss EAP. Si la implementación de JCA está vinculada a WebSphere, tendrá que refactorizar su aplicación para eliminar la dependencia del conector JCA. Si se puede usar el conector JCA, tendrá que agregar los JAR al classpath del servidor. También tendrá que colocar los archivos de configuración necesarios en la ubicación correcta en los directorios del servidor JBoss EAP para que esté disponible.

Determinación de si JAAS está en uso

Si su aplicación usa JAAS, deberá capturar cómo está configurado JAAS. Si utiliza una base de datos, puede convertirla en un dominio de JAAS en JBoss EAP. Si se trata de una implementación personalizada, deberá validar que se puede usar en JBoss EAP.

Determinación de si la aplicación usa un adaptador de recursos

Si la aplicación necesita un adaptador de recursos, debe ser compatible con JBoss EAP. Determine si el adaptador de recursos funciona correctamente en una instancia independiente de JBoss EAP; para ello, impleméntelo en el servidor y configúrelo correctamente. Si el RA funciona correctamente, tendrá que agregar los archivos JAR a la ruta de clase del servidor de instancia de App Service, y colocar los archivos de configuración necesarios en los directorios correspondientes del servidor de JBoss EAP para que esté disponible.

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 examinar los archivos application.xml y ibm-application-bnd.xm, y 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.

Migración

Kit de herramientas de migración para aplicaciones de Red Hat

El Kit de herramientas de migración para aplicaciones de Red Hat es una extensión gratuita para Visual Studio Code. Esta extensión analiza el código y la configuración de su aplicación para proporcionar recomendaciones para migrar sus aplicaciones Jakarta EE a JBoss EAP desde otros servidores de aplicaciones, como eliminar las dependencias de API propietarias. La extensión también proporcionará recomendaciones si estás migrando a la nube desde el entorno local. Para obtener más información, consulte Información general sobre el kit de herramientas de migración para aplicaciones.

El contenido de esta guía le ayudará a abordar los demás componentes del viaje de migración, como la elección del tipo de plan de App Service correcto, la externalización del estado de sesión y el uso de Azure para gestionar las instancias de EAP en lugar de la interfaz de gestión de JBoss.

Aprovisionamiento de un plan de App Service

En la lista de planes de servicio disponibles, seleccione el plan cuyas especificaciones sean igual o superiores a las especificaciones del hardware de producción actual.

Nota:

Si planea ejecutar implementaciones de ensayo o controladas, o usar espacios de implementación, el plan de App Service debe incluir esa funcionalidad adicional. Se recomienda usar planes Premium o superiores para las aplicaciones de Java.

Cree ese plan de App Service.

Creación e implementación de aplicaciones web

Tendrá que crear una Web App en su plan de App Service para cada archivo WAR implementado en el servidor de JBoss EAP.

Nota:

Aunque es posible implementar varios archivos WAR en una sola aplicación web, es muy poco recomendable. La implementación de varios archivos WAR en una sola aplicación web impide que cada aplicación escale según sus propias demandas de uso. También agrega complejidad a las posteriores canalizaciones de implementación. Si tiene que haber varias aplicaciones disponibles en una sola dirección URL, considere la posibilidad de usar una solución de enrutamiento como Azure Application Gateway.

Aplicaciones de Maven

Si la aplicación se ha creado a partir de un archivo POM de Maven, usaeel complemento Webapp para Maven para crear la aplicación web e implementarla. Para obtener más información, consulte la sección Configurar el plugin de Maven de Inicio rápido: Crear una aplicación Java en Azure App Service.

Aplicaciones que no son de Maven

Si no puede usar el complemento de Maven, debe aprovisionar la aplicación web con otros mecanismos, como:

Una vez creada la Web App, utilice uno de los mecanismos de despliegue disponibles para desplegar su aplicación. Para obtener más información, vea Implementación de archivos en App Service.

Migración de las opciones de tiempo de ejecución de JVM

Si la aplicación requiere opciones de tiempo de ejecución específicas, use el mecanismo más adecuado para especificarlas. Para obtener más información, consulte la sección Establecer opciones de tiempo de ejecución de Java de Implementación y configuración de una aplicación Tomcat, JBoss o Java SE en Azure App Service.

Relleno de secretos

Use la configuración de la aplicación para almacenar los secretos específicos de la aplicación. Si piensa utilizar el mismo secretos o secretos en varias aplicaciones o requiere funcionalidades de auditoría y directivas de acceso específicas, use referencias de Azure Key Vault en su lugar. Para obtener más información, consulte Uso de referencias de Key Vault como configuración de aplicaciones en Azure App Service y Azure Functions.

Configuración del dominio personalizado y SSL

Si la aplicación va a ser visible en un dominio personalizado, tendrá que asignarle su aplicación web. Para más información, consulte Tutorial: Asignación de un nombre DNS personalizado existente a Azure App Service.

Después, tendrá que enlazar el certificado TLS/SSL de ese dominio a la App Service Web App. Para más información, consulte Protección de un nombre DNS personalizado con un enlace TLS/SSL en Azure App Service.

Migración de orígenes de datos, bibliotecas y recursos de JNDI

Para migrar orígenes de datos, siga los pasos descritos en Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service.

Migre las dependencias adicionales de classpath de nivel de servidor. Para obtener más información, consulte Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service.

Migre otros recursos de JDNI adicionales compartidos en el nivel de servidor. Para obtener más información, consulte Configuración de orígenes de datos para una aplicación Tomcat, JBoss o Java SE en Azure App Service.

Nota:

Si está siguiendo la arquitectura recomendada de un archivo WAR por aplicación, considere la posibilidad de migrar las bibliotecas de CLASSPATH en el nivel de servidor y los recursos de JNDI a su aplicación. Hacerlo simplificará considerablemente la administración de cambios y la gobernanza de los componentes. Si desea implementar más de un WAR por aplicación, debería consultar una de nuestras guías complementarias mencionadas al principio de esta guía.

Migración de los trabajos programados

Como mínimo, debe mover los trabajos programados a una máquina virtual Azure para que dejen de formar parte de la aplicación. Como alternativa, puede optar por modernizarlos en Java controlado por eventos mediante servicios de Azure como Azure Functions, SQL Database y Event Hubs.

Reinicio y prueba de humo

Por último, tendrá que reiniciar la aplicación web para aplicar todos los cambios de la configuración. Tras completar el reinicio, compruebe que la aplicación se está ejecutando correctamente.

Después de la migración

Ahora que ha migrado la aplicación a Azure App Service, debe comprobar que funciona como se espera. Una vez hecho esto, tenemos algunas recomendaciones que pueden hacer que su aplicación sea más nativa de la nube.

Recomendaciones