Compartir a través de

Migración de aplicaciones de WebLogic Server a Azure Virtual Machines

  • Artículo

En esta guía se describe lo que hay que tener en cuenta para migrar una aplicación de WebLogic existente para que se ejecute en Azure Virtual Machines. Para obtener información general sobre las soluciones de WebLogic Server disponibles en Azure Marketplace, consulte ¿Cuáles son las soluciones para ejecutar Oracle WebLogic Server en máquinas virtuales 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.

Definición del significado de "migración completa"

Esta guía, y las ofertas de Azure Marketplace correspondientes, son un punto de partida para acelerar la migración de las cargas de trabajo de WebLogic Server a Azure. Es importante definir el ámbito del trabajo de migración. Por ejemplo, ¿está realizando una migración lift-and-shift estricta de la infraestructura existente a Azure Virtual Machines? Si es así, es posible que se sienta la tentación de realizar algunas mejoras mientras realiza la migración.

En la medida de lo posible, es mejor centrarse en un traslado lift-and-shift, teniendo en cuenta los cambios necesarios que se indican en esta guía. Defina lo que quiere decir con "migración completa" para que sepa cuándo ha alcanzado el objetivo. Cuando haya realizado la "migración completa", puede hacer una instantánea de sus máquinas virtuales, tal y como se describe en Crear una instantánea. Cuando haya comprobado que puede realizar la restauración correctamente desde la instantánea, puede realizar las mejoras sin miedo a perder el progreso de la migración que ha conseguido hasta ahora.

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

El primer paso para migrar una aplicación WLS a Azure con éxito es seleccionar el destino de migración más adecuado. WLS funciona bien en máquinas virtuales (VM) de Azure o en Azure Kubernetes Service (AKS). El destino de la máquina virtual es la opción más fácil, ya que se asemeja más a una implementación local. La experiencia administrativa y de implementación de las máquinas virtuales es muy similar a la de las instalaciones locales. El inconveniente de esta facilidad es el coste económico. En términos generales, el coste por minuto de una solución basada en máquinas virtuales es mayor que el de AKS. Aunque cuesta menos ejecutar una solución basada en AKS, debe restringir su aplicación para que se ajuste a los requisitos de AKS. Si minimizar el cambio es el factor más importante para su esfuerzo de migración, considere una migración basada en máquinas virtuales. En este caso, consulte Migración de aplicaciones WebLogic a máquinas virtuales de Azure. Si puede convertir su aplicación para que se ejecute dentro de Kubernetes y así reducir el coste del tiempo de ejecución, considere una migración basada en AKS. En este caso, continúe con Migración de aplicaciones de WebLogic Server a Azure Kubernetes Service.

Determinación de si las ofertas de Azure Marketplace preconfiguradas son un buen punto de partida

Oracle y Microsoft se han asociado para incorporar a Azure Marketplace un conjunto de plantillas de soluciones de Azure que ofrecen un punto de partida sólido para la migración a Azure. Consulte la documentación de Oracle Fusion Middleware para obtener la lista de las ofertas, y elija la que mejor se ajuste a su implementación existente. Puede ver la lista de ofertas en el artículo de información general ¿Qué es Oracle WebLogic Server en Azure?

Si ninguna de las ofertas existentes es un buen punto de partida, tendrá que reproducir la implementación a mano con los recursos de Azure Virtual Machines. Puede encontrar la guía paso a paso en Instalar Oracle WebLogic Server en máquinas virtuales Azure manualmente. Para más información, consulte ¿Qué es IaaS?

Determinación de si la versión de WebLogic es compatible

La versión existente de WebLogic debe ser compatible con la versión de las ofertas de IaaS. Para ver las ofertas para WebLogic versión 12.2.1.4, consulte Azure Marketplace para Oracle WebLogic 12.2.1.4. Si la versión WebLogic existente no es compatible con esa versión, tendrá que reproducir la implementación a mano con los recursos de IaaS de Azure. Para más información, consulte la documentación de Azure.

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. Esta información se utilizará para elegir el tamaño de las máquinas virtuales. Para obtener más información, consulte Tamaños de Cloud Services.

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>

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

Todas las rutas de migración de WebLogic a Azure requieren una versión específica de Java, que varía para cada ruta de acceso. Deberá comprobar 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

Nota:

Al migrar a WLS en máquinas virtuales de Azure, los requisitos para las versiones específicas de Java vienen determinados por el Java instalado previamente en las máquinas virtuales. Al migrar a WLS en AKS, la versión específica de Java viene determinada por la imagen de contenedor elegida. Existe una gran variedad de opciones, pero todas ellas usan el JDK de Oracle.

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 tres opciones:

  • Coherence*Web puede ejecutarse junto con un servidor de WebLogic en las máquinas virtuales de Azure, pero debe configurar esta opción manualmente después de aprovisionar la oferta. Si usa la versión independiente de Coherence, también puede ejecutarla en una máquina virtual de Azure, pero debe configurar esta opción manualmente después de aprovisionar la oferta.
  • 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 usa la administración mediante REST

Si el ciclo de vida de la aplicación incluye el uso de administración mediante REST, debe capturar qué puertos se usan para tener acceso a la API REST y determinar cómo se autentican y exponen. Después de la migración, tendrá que asegurarse de que se exponen estos mismos puertos y mecanismos de autenticación para que el ciclo de vida de la aplicación funcione de manera similar a como funcionaba antes de la migración. Para más información, consulte Administración de Oracle WebLogic Server con servicios de administración RESTful.

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 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.

Si usa Oracle Message Broker, puede migrar este software a Azure Virtual Machines y usarlo tal cual.

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 del host, deberá refactorizarla para quitar esas dependencias. Por ejemplo, es posible que tenga que reemplazar cualquier uso de / o \ en las rutas del sistema de archivos con File.Separator o Paths.get si la aplicación se ejecuta en Windows.

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.

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 los parámetros (en tiempo de ejecución) de la aplicación como parte de la implementación, deberá asegurarse de que este comportamiento sigue funcionando cuando pruebe la aplicación después de la migración.

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

Los sistemas de archivos de las máquinas virtuales funcionan de la misma manera que los sistemas de archivos locales en cuanto a la persistencia, el inicio y el apagado. Sin embargo, es importante tener en cuenta las necesidades del sistema de archivos y asegurarse de que las máquinas virtuales tengan el tamaño y la capacidad de almacenamiento adecuados.

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.

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.

Determinación de la topología de red

El conjunto actual de ofertas de Azure Marketplace es un punto de partida para su migración. Si la oferta no cubre los aspectos de la arquitectura que necesita migrar, deberá capturar la topología de red de la implementación existente y reproducirla en Azure, incluso después de poner en marcha la oferta básica con una de las plantillas de solución.

Este es un tema muy amplio, pero las referencias siguientes pueden ayudar a dirigir los esfuerzos de migración por el camino correcto:

Cuenta para el uso de adaptadores de JCA y adaptadores de recursos

Si la aplicación existente utiliza adaptadores de JCA o adaptadores de recursos para conectarse a otros sistemas empresariales, asegúrese de que la configuración de estos artefactos se aplica al servidor de WebLogic que se ejecuta en Azure Virtual Machines. Para más información, consulte Creación y configuración de adaptadores de recursos.

Cuenta para el uso de proveedores de seguridad personalizados y JAAS

Si la aplicación usa JAAS, debe asegurarse de que la configuración de los proveedores de seguridad se ha migrado correctamente. Para más información, consulte Acerca de la configuración de los proveedores de seguridad de WebLogic en la documentación de Oracle.

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. Puede migrar estos clústeres directamente desde su instalación local a WebLogic para que se ejecuten en máquinas virtuales de Azure. Para más información, consulte Archivos de configuración de dominio en la documentación de Oracle.

Requisitos del equilibrio de carga

El equilibrio de carga es una parte esencial de la migración del clúster de Oracle WebLogic Server a Azure. La solución más sencilla consiste en usar la compatibilidad integrada con Azure Application Gateway que se proporciona en la oferta de Azure Marketplace para el clúster de Oracle WebLogic Server. Para un tutorial sobre este tema, consulte Tutorial: Migración de un clúster de WebLogic Server a Azure con Azure Application Gateway como equilibrador de carga.

Para ver un resumen de las funcionalidades de Azure Application Gateway en comparación con otras soluciones de equilibrio de carga de Azure, consulte Información general sobre las opciones de equilibrio de carga en Azure.

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

Si su aplicación usa la característica de cliente de aplicación de Java EE, debería continuar funcionando sin cambios después de migrar a Azure Virtual Machines. Para más información, consulte cómo usar los módulos de aplicación de cliente de Java EE.

Migración

Selección de una oferta de WebLogic en Azure Virtual Machines

Las siguientes ofertas están disponibles para WebLogic en Azure Virtual Machines.

Durante la implementación de una oferta, se le pedirá que elija el tamaño de máquina virtual para los nodos de WebLogic Server. Es importante tener en cuenta todos los aspectos (memoria, procesador y disco) a la hora de elegir el tamaño de la máquina virtual. Para más información, consulte Documentación de Azure sobre tamaños de máquina virtual.

Nodo único de WebLogic Server sin servidor de administración

Esta oferta crea una sola máquina virtual e instala WebLogic en ella, pero no configura ningún dominio, lo que resulta útil para escenarios en los que se tiene una configuración de dominio muy personalizada.

Nodo único de WebLogic Server con servidor de administración

Esta oferta aprovisiona una única máquina virtual e instala WebLogic Server en ella. Crea un dominio e inicia el servidor de administración.

Clúster de N nodos de WebLogic Server

Esta oferta crea un clúster de alta disponibilidad de máquinas virtuales de WebLogic Server.

Clúster dinámico N nodos de WebLogic Server

Esta oferta crea un clúster dinámico escalable y de alta disponibilidad de máquinas virtuales de WebLogic Server.

Aprovisionamiento de la oferta

Una vez seleccionada la oferta con la que quiere empezar, siga las instrucciones de la documentación de las ofertas para aprovisionar dicha oferta. Asegúrese de elegir el nombre de dominio que coincida con el nombre de dominio existente. Incluso puede hacer coincidir la contraseña de dominio con la contraseña de dominio existente.

Migración de los dominios

Una vez aprovisionada la oferta, puede examinar la configuración del dominio y seguir esta guía para obtener más información sobre cómo migrar los dominios.

Conexión de las bases de datos

Después de migrar los dominios, puede conectar las bases de datos siguiendo las instrucciones de la documentación de la oferta. Estas instrucciones ayudarán a tener en cuenta los secretos de las base de datos y las cadenas de acceso implicadas.

Cuenta de almacenes de claves

Debe tener en cuenta la migración de los almacenes de claves SSL que use la aplicación. Para más información, consulte Configuración de almacenes de claves.

Conexión de los orígenes de JMS

Una vez conectadas las bases de datos, puede configurar JMS. Para obtener más información, consulte Administración de recursos de JMS para Oracle WebLogic Server en la documentación de WebLogic.

Autenticación y autorización

La mayoría de las aplicaciones tienen algún tipo de autenticación y autorización. Si usa LDAP para la autenticación, puede configurar Microsoft Entra Domain Services con LDAP seguro y configurar las conexiones LDAP en WebLogic Server. Para obtener más información, consulte Crear y configurar un dominio administrado de Microsoft Entra Domain Services y Configurar LDAP seguro para un dominio administrado de Microsoft Entra Domain Services.

Cuenta para el registro

Use la integración con Elastic en Azure que ofrecen las plantillas de solución de Oracle WebLogic Server marketplace. Este enfoque es la forma más sencilla de contabilizar el registro. Puede ver la lista de ofertas en el artículo de información general ¿Cuáles son las soluciones para ejecutar Oracle WebLogic Server en máquinas virtuales de Azure? Los tutoriales completos para configurar Elastic se proporcionan en:

Si la integración de Elastic no es adecuada, debe conservar la configuración de registro existente al migrar el dominio. Para más información, consulte Configuración de los niveles de registrador de java.util.logging y Configuración de los archivos de registro y filtrado de los mensajes de registro para Oracle WebLogic Server.

Migración de las aplicaciones

Las técnicas que se usan para implementar las aplicaciones del equipo de desarrollo en servidores de prueba, de ensayo y de producción varían mucho en cada caso. En algunos casos, hay una plataforma de CI/CD muy evolucionada que permite implementar las aplicaciones en el servidor de WebLogic. En otros casos, el proceso puede ser más manual. Una ventaja de usar Azure Virtual Machines para migrar aplicaciones de WebLogic a la nube es que los procesos existentes seguirán funcionando.

Tendrá que configurar el grupo de seguridad de red que aprovisiona la oferta para poder acceder desde la canalización de CI/CD o el sistema de implementación manual. Para más información, consulteGrupo de seguridad de red.

Prueba

Todas las pruebas de las aplicaciones en el contenedor deben configurarse para tener acceso a los nuevos servidores que se ejecutan en Azure. Al igual que en el caso de CI/CD, debe asegurarse de que las reglas de seguridad de red necesarias permiten que las pruebas tengan acceso a las aplicaciones implementadas en Azure. Para más información, consulteGrupo de seguridad de red.

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 orientación sobre algunas posibles mejoras posteriores a la migración, consulte las siguientes recomendaciones: