Migración de aplicaciones de WebLogic Server a JBoss EAP en App de Azure Service
En esta guía se describe lo que debe tener en cuenta cuando quiera migrar una aplicación webLogic Server existente para que se ejecute en App de Azure 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.
Si no puede cumplir ninguno de estos requisitos previos a la migración, consulte la guía de migración complementaria para migrar las aplicaciones a Virtual Machines en su lugar: Migración de aplicaciones de WebLogic Server a Azure Virtual Machines.
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 seleccionar el plan de App Service.
La lista de niveles de plan de App Service disponibles muestra la memoria, los núcleos de CPU, el almacenamiento y la información de precios. Tenga en cuenta que JBoss EAP en App Service solo está disponible en los niveles Premium V3 y Aislado del plan de App Service V2 .
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 WebLogic Server, estos secretos se encuentran en muchos archivos de configuración 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 weblogic.xml en sus WAR. 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.
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>
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 más información sobre los recursos y las bases de datos de JNDI, consulte Orígenes de datos de servidor de WebLogic en la documentación de Oracle. Otros recursos relacionados con JNDI, como los agentes de mensajes JMS, pueden requerir una migración o reconfiguración. Para obtener más información sobre la configuración de JMS, consulte Oracle WebLogic Server 12.2.1.4.0.
Inspección de la configuración del dominio
La unidad de configuración principal en WebLogic Server es el dominio. Como tal, el archivo config.xml contiene numerosas opciones de configuración que debe tener muy en cuenta para la migración. El archivo incluye referencias a archivos XML adicionales que se almacenan en subdirectorios. Oracle recomienda utilizar la consola de administración para configurar los objetos y servicios administrables de WebLogic Server, y dejar que WebLogic Server mantenga el archivo config.xml. Para más información, consulte Archivos de configuración de dominio.
Dentro de la aplicación
Inspeccione el archivo WEB-INF/weblogic.xml y el archivo WEB-INF/web.xml.
Determinación de si se usa la replicación de sesión
Si la aplicación utiliza replicación de sesión, con o sin Oracle Coherence*Web, tiene dos opciones:
- 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 WebLogic realiza la replicación del estado de sesión HTTP. Para más información, consulte Replicación del estado de sesión HTTP en la documentación de Oracle.
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 más información sobre los controladores JDBC en WebLogic, consulte Uso de controladores JDBC con WebLogic Server.
Determinación de si se ha personalizado WebLogic
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 son setDomainEnv, commEnv, startWebLogic y stopWebLogic.
- ¿Se han pasado parámetros específicos a JVM?
- ¿Se han agregado archivos JAR a la ruta de clases del servidor?
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 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 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.
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.
Determinación de si se usan agrupaciones OSGi
Si usaba agrupaciones OSGi en el servidor WebLogic, deberá agregar los archivos JAR equivalentes directamente a la aplicación web.
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 Oracle Service Bus está en uso
Si la aplicación usa Oracle Service Bus (OSB), deberá capturar cómo está configurado. Para más información, consulte Acerca de la instalación de Oracle Service Bus.
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 weblogic-application.xml, 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.
Comprobación de que la versión compatible de Java funciona correctamente
JBoss EAP en App de Azure Service admite 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
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 usa WebLogic Scripting Tool (WLST)
Si actualmente usa WLST para realizar la implementación, deberá evaluar lo que está haciendo. Si WLST cambia cualquier parámetro (runtime) de la aplicación como parte de la implementación, deberá asegurarse de que esos parámetros se ajustan a una de las siguientes opciones:
- Se han externalizado como configuración de la aplicación.
- Están insertados en la aplicación.
- Usan la CLI de JBoss durante la implementación.
Si WLST está haciendo más de lo que se mencionó anteriormente, tendrá algún trabajo adicional que realizar durante la migración.
Determinación de si la aplicación usa API específicas de WebLogic
Si la aplicación usa API específicas de WebLogic, deberá refactorizar la aplicación para no usarlas. Por ejemplo, si ha usado una clase mencionada en la referencia de la API de Java para Oracle WebLogic Server, ha utilizado una API específica de WebLogic en la aplicación. Red Hat Migration Toolkit for Apps puede ayudar a quitar 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 la aplicación usa Entity Beans o EJB 2.x estilo CMP beans, deberá refactorizar la aplicación para NO usarlas.
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 Cliente de aplicaciones java EE, deberá refactorizar las aplicaciones cliente y la aplicación (servidor) para usar las API HTTP.
Determinación de si se ha utilizado un plan de implementación
Si se usó un plan de implementación para realizar la implementación, deberá evaluar lo que hace el plan de implementación. Si el plan es una implementación directa, podrá implementar la aplicación web sin realizar ningún cambio. Si el plan de implementación es más elaborado, deberá determinar si puede usar la CLI de JBoss para configurar correctamente la aplicación como parte de la implementación. Si no es posible usar la CLI de JBoss, deberá refactorizar la aplicación para que no se necesite un plan de implementación.
Determinación de si los temporizadores de EJB están en uso
Si la aplicación usa temporizadores EJB, deberá validar que cada instancia de JBoss EAP puede desencadenar el código del temporizador EJB de forma independiente. Esta validación es necesaria porque cuando app Service se escala horizontalmente, cada temporizador EJB se desencadenará en su propia instancia de JBoss EAP.
Validar si y cómo se usa el sistema de archivos
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 WebLogic o el código de la aplicación pueden usar el sistema de archivos. Puede identificar algunos o todos los escenarios siguientes.
Contenido estático de solo lectura
Si la aplicación actualmente atiende contenido estático, se necesitará una ubicación alternativa para ese contenido estático. Es posible que desee considerar la posibilidad de mover contenido estático a Azure Blob Storage y agregar Azure CDN para descargas rápidas a nivel mundial.
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.
Contenido dinámico o interno
En el caso de los archivos escritos y leídos con frecuencia por la aplicación (como archivos de datos temporales) o archivos estáticos que solo son visibles para la aplicación, Azure Storage se puede montar en el sistema de archivos de App Service.
Determinación de si se están usando conectores de JCA
Si la aplicación usa conectores JCA, tendrá que validar que se puede usar el conector JCA en JBoss EAP. Si la implementación de JCA está vinculada a WebLogic, tendrá que refactorizar la aplicación para QUE NO use el conector JCA. Si se puede usar, tendrá que agregar los ARCHIVOS JAR a la ruta de clase de servidor y colocar los archivos de configuración necesarios en la ubicación correcta en los directorios de servidor de JBoss EAP para que esté disponible.
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 la ra funciona correctamente, tendrá que agregar los ARCHIVOS JAR a la ruta de clase de servidor de la instancia de App Service y colocar los archivos de configuración necesarios en la ubicación correcta en los directorios del servidor de JBoss EAP para que esté disponible.
Determinar si se usa JAAS
Si la aplicación usa JAAS, deberá capturar cómo se configura 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 se usa la agrupación en clústeres de WebLogic
Lo más probable es que haya implementado la aplicación en varios servidores de WebLogic para lograr alta disponibilidad. App de Azure Service es capaz de escalar, pero si ha usado webLogic Cluster API, deberá refactorizar el código para eliminar el uso de esa API.
Migración
Kit de herramientas de migración de Red Hat para aplicaciones
Red Hat Migration Toolkit for Applications es una extensión gratuita para Visual Studio Code. Esta extensión analiza el código y la configuración de la aplicación para proporcionar recomendaciones para migrar las aplicaciones de Jakarta EE a JBoss EAP desde otros servidores de aplicaciones, como quitar dependencias en las API propietarias. La extensión también proporcionará recomendaciones si va a migrar a la nube desde el entorno local. Para obtener más información, consulte Introducción al Kit de herramientas de migración para aplicaciones.
El contenido de esta guía le ayudará a abordar los otros componentes del recorrido de migración, como elegir el tipo de plan de App Service correcto, externalizar el estado de sesión y usar Azure para administrar las instancias de EAP en lugar de la interfaz de administración de JBoss.
Aprovisionamiento de un plan de App Service
En la lista de planes de servicio disponibles, seleccione el plan cuyas especificaciones cumplan o superen 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.
Creación e implementación de aplicaciones web
Deberá crear una aplicación web en el plan de App Service para cada archivo WAR implementado en el servidor 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 Configuración del complemento maven de Inicio rápido: Creación de una aplicación de Java en App de Azure 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:
Después de crear la aplicación web, use uno de los mecanismos de implementación disponibles para implementar la aplicación. Para más información, consulteImplementació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 Set Java runtime options (Establecer opciones en tiempo de ejecución de Java) de Configure a Java app for App de Azure Service (Configurar una aplicación java para App de Azure Service).
Migración de parámetros externos
Si necesita usar parámetros externos, deberá establecerlos como configuración de la aplicación. Para obtener más información, consulte Configuración de aplicaciones.
Migración de scripts de inicio
Si la aplicación original usó un script de inicio personalizado, deberá migrarla a un script de Bash. Para obtener más información, consulte Personalización de la configuración del servidor de aplicaciones.
Relleno de secretos
Use la configuración de la aplicación para almacenar los secretos específicos de la aplicación. Si piensa usar el mismo secreto o secretos entre varias aplicaciones, o bien necesita directivas de acceso específicas y funcionalidades de auditoría, use las referencias de Azure Key Vault en su lugar. Para obtener más información, consulte la sección Usar referencias de KeyVault de Configuración de una aplicación de Java para App de Azure Service.
Configuración de 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.
A continuación, deberá enlazar el certificado TLS/SSL para ese dominio a la aplicación web de App Service. 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 la sección Configurar orígenes de datos de Configuración de una aplicación Java para App de Azure Service.
Migre las dependencias adicionales de classpath de nivel de servidor siguiendo las instrucciones de la sección JBoss EAP de Configuración de una aplicación Java para App de Azure Service.
Migre los recursos JDNI de nivel de servidor compartido adicionales. Para obtener más información, consulte la sección JBoss EAP de Configuración de una aplicación de Java para App de Azure Service.
Migración de conectores JCA y módulos JAAS
Migre los conectores JCA y los módulos JAAS siguiendo las instrucciones de Instalación de módulos y dependencias.
Nota:
Si sigue la arquitectura recomendada de una WAR por aplicación, considere la posibilidad de migrar bibliotecas de ruta de clase de nivel de servidor y recursos JNDI a la aplicación. Al hacerlo, se simplificará significativamente la gobernanza de componentes y la administración de cambios. Si desea implementar más de una WAR por aplicación, debe revisar 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 de Azure para que ya no formen 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 para usted que pueden hacer que la aplicación sea más nativa de la nube.
Recomendaciones
Si ha optado por usar el directorio /home para el almacenamiento de archivos, considere la posibilidad de reemplazarlo por Azure Storage. Para más información, consulte Montaje de Azure Storage como un recurso compartido local en un contenedor personalizado en App Service.
Si tiene la configuración en el directorio /home que contiene cadena de conexión, claves SSL y otra información secreta, considere la posibilidad de usar una combinación de Azure Key Vault y la inserción de parámetros con la configuración de la aplicación siempre que sea posible. Para más información, consulte Uso de referencias de Key Vault para App Service y Azure Functions y Configuración de una aplicación de App Service.
Considere la posibilidad de usar ranuras de implementación para realizar implementaciones confiables sin tiempo de inactividad. Para más información, consulte Configuración de entornos de ensayo en Azure App Service.
Diseñe e implemente una estrategia de DevOps. Para mantener la confiabilidad y, al mismo tiempo, aumentar la velocidad de desarrollo, considere la posibilidad de automatizar las implementaciones y pruebas con Azure Pipelines. Para obtener más información, consulte Compilación e implementación en la aplicación web de Java. Si usa ranuras de implementación, puede automatizar la implementación en una ranura y el intercambio de ranuras posterior. Para más información, consulte la sección Implementación en una ranura de Implementación de una aplicación web de Azure.
Diseñe e implemente una estrategia de continuidad empresarial y recuperación ante desastres. En el caso de las aplicaciones críticas, considere la posibilidad de usar una arquitectura de implementación de varias regiones. Para más información, consulte Aplicación web de varias regiones de alta disponibilidad.
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta:Enviar y ver comentarios de