Migración de aplicaciones de WebLogic Server a Azure Kubernetes Service

En esta guía se describe lo que debe tener en cuenta cuando quiera migrar una aplicación existente de WebLogic Server (WLS) para que se ejecute en Azure Kubernetes Service (AKS).

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 de una migración correcta de una aplicación WLS a Azure es seleccionar el destino de migración más adecuado. WLS se ejecuta bien en máquinas virtuales (VM) de Azure o Azure Kubernetes Service (AKS). 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 muy análoga a lo que tiene en el entorno local. El inconveniente de esta facilidad es el costo económico. Por lo general, el costo por minuto de una solución basada en máquinas virtuales es mayor en comparación con AKS. Aunque una solución basada en AKS cuesta menos que ejecutarse, debe restringir la aplicación para que se ajuste a los requisitos de AKS. 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 WebLogic a Azure Virtual Machines. Si puede tolerar la conversión de la aplicación para que se ejecute en Kubernetes para reducir el costo en tiempo de ejecución, considere la posibilidad de realizar una migración basada en AKS. En este caso, continúe con Migración de aplicaciones de WebLogic Server a Azure Kubernetes Service.

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

Una vez que haya decidido que AKS es el destino de implementación adecuado, debe aceptar que el operador de Kubernetes de Oracle WLS (el operador) es la única manera de ejecutar WLS en Kubernetes. Después de aceptar este hecho, debe decidir si la oferta precompilada de Azure Marketplace es un buen punto de partida. Estos son algunos aspectos que se deben tener en cuenta sobre la oferta precompilada de Azure Marketplace.

• Oracle y Microsoft crearon esta oferta para permitirle aprovisionar rápidamente WLS en AKS mediante el modelo en el tipo de origen principal dominio de imagen . Este concepto se explica con más detalle más adelante en este artículo.
• En un nivel alto, la oferta automatiza los pasos siguientes.
  • Realice una implementación WAR o EAR existente, si lo desea.
  • Encapsularlo en un contenedor mediante webLogic Image Tool (WIT). Para obtener más información, consulte WebLogic Image Tool en la documentación de Oracle.
  • Instale y configure el operador de Kubernetes de WebLogic en AKS.
  • Use el operador para ejecutar todo. El operador invoca a WebLogic Deploy Tooling (WDT) para defender los entornos de WebLogic y realizar operaciones de ciclo de vida de dominio de forma repetible en función de un modelo de metadatos. Para obtener más información, consulte Herramientas de webLogic Deploy en la documentación de Oracle.
• Aunque la oferta precompilada proporciona numerosas integraciones de servicios de Azure, como App Gateway, registro elástico, integración de bases de datos, etc., hace muchas suposiciones de simplificación. Estas suposiciones hacen que la oferta no sea tan flexible como maestro y uso del operador usted mismo.

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

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

Decidir si se va a usar la oferta precompilada de Azure Marketplace

En primer lugar, debe comprender el concepto del "dominio" de WLS. Un dominio es un grupo relacionado lógicamente de recursos de WLS. Para obtener la definición canónica del dominio WLS, consulte la documentación de Oracle. La ejecución de WLS en AKS requiere decidir cómo AKS se ocupa de los dominios. Las distintas opciones se conocen como "tipo de origen principal de dominio". El operador de Kubernetes WLS admite tres opciones de tipo de origen principal de dominio. La oferta precompilada de Azure Marketplace usa la primera de esta tabla.

Tipo de origen principal de dominio	Descripción	Aspectos positivos	Aspectos negativos
Modelo en imagen	WLS y las aplicaciones se encuentran en la imagen de contenedor y todo lo demás se mantiene fuera de esa imagen.	Compatible con la oferta precompilada. Documentado como ejemplo oficial; consulte Oracle. La mayoría usa WDT. La mayoría de las opciones "nativas de la nube". Integración de CI/CD más sencilla.	Curva de aprendizaje más grande.
Dominio en PV	El dominio reside en un volumen persistente de Kubernetes.	Conceptualmente similar a la ejecución en máquinas virtuales. Puede usar la consola de WLS para realizar cambios y esos cambios persisten en los reinicios del pod de AKS. Documentado como ejemplo oficial; consulte Oracle.	Se deben mitigar algunos desafíos relacionados con NFS. Para obtener más información, consulte Oracle. Este enfoque es la técnica menos "nativa de la nube"; el estado reside completamente fuera del clúster de AKS.
Dominio en la imagen	El dominio reside en una imagen de contenedor. Las aplicaciones están contenidas en una imagen de contenedor superpuesta en la imagen de dominio.	Más "nativo de la nube" que el dominio en PV. Más fácil para CI/CD.	No se puede usar la consola WLS. Debe mantener más imágenes de contenedor.

Importante

Si elige el dominio en el tipo de origen PV , se recomienda encarecidamente NFS en lugar de SMB. NFS evolucionó desde el sistema operativo UNIX y otras variantes como GNU/Linux. Por este motivo, al usar NFS con tecnologías de contenedor como Docker, es menos probable que tenga problemas para las lecturas simultáneas y el bloqueo de archivos.

Asegúrese de habilitar NFS v4.1. Las versiones inferiores a v4.1 tendrán problemas.

La documentación del operador también incluye una tabla útil que compara las distintas opciones. Para obtener más información, consulte Elegir un tipo de origen principal de dominio.

Para obtener una idea de la oferta precompilada de Azure Marketplace, consulte Inicio rápido: Implementación de WebLogic Server en Azure Kubernetes Service mediante Azure Portal. Para obtener la documentación de referencia sobre la oferta precompilada de Azure Marketplace, consulte Oracle.

Para obtener una sensación de usar el operador directamente, pruebe los ejemplos en la documentación del operador.

Ahora que se ha introducido en las distintas formas de controlar los dominios de WLS en AKS, es mejor que pueda elegir si va a usar la oferta precompilada de Azure Marketplace o para hacerlo usted mismo mediante el operador directamente.

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

La versión existente de WLS debe ser una de las versiones compatibles con el operador. Oracle mantiene estas versiones en Oracle Container Registry (OCR). Siga estos pasos para ver la lista de versiones admitidas.

1. Visite el sitio web de Oracle Container Registry e inicie sesión. Para obtener más información, vea https://container-registry.oracle.com/.
2. Si tiene derechos de soporte técnico, seleccione Middleware y busque weblogic_cpu. Seleccione weblogic_cpu.
3. Si no tiene derecho de soporte técnico de Oracle, seleccione Middleware y busque weblogic. Seleccione weblogic.

Nota:

Obtenga un derecho de soporte técnico de Oracle antes de ir a la producción. Si no lo hace, se ejecutan imágenes no seguras que no se revisan para detectar errores críticos de seguridad. Para obtener más información sobre las actualizaciones de revisiones críticas de Oracle, consulte Critical Patch Novedades, Security Alerts and Bulletins( Alertas de seguridad y boletines).

La oferta precompilada de Azure Marketplace permite seleccionar las imágenes de WLS de OCR y Azure Container Registry (ACR) y, por tanto, admite implícitamente todas las versiones disponibles en OCR. Si dirige la oferta para extraer una imagen de ACR, asegúrese de que se deriva de una de las versiones admitidas enumeradas en OCR.

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, ayudar a guiar la selección del tamaño de las máquinas virtuales del grupo de nodos, la cantidad de memoria que usará el contenedor y el número de recursos compartidos de CPU que necesita el contenedor.

Es posible cambiar el tamaño de los grupos de nodos en AKS. Para más información, consulte Cambio de tamaño de los grupos de nodos en Azure Kubernetes Service (AKS).

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.

Una vez que tenga un inventario sólido de secretos, consulte la documentación del operador sobre los secretos. Para más información, vea Secretos.

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 instalarlos directamente con la oferta precompilada de Azure Marketplace. Para más información, consulte Configuración de TLS/SSL. Si usa el operador directamente, consulte Actualización de certificados externos del operador.

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 de las versiones específicas de Java se determinan mediante el Java preinstalado 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. Hay una amplia 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.

Si usa la oferta precompilada de Azure Marketplace, el conjunto de recursos JNDI que puede personalizar en el momento de la implementación se limita a lo que admite la oferta. Busque JNDI en la documentación de la oferta. Si usa el operador directamente, los recursos JDNI se pueden definir en función del tipo de origen de inicio del dominio elegido. Para Dominio en PV, puede establecerlos de la manera habitual, con WLST o con la consola de administración. Para dominio en imagen o modelo en imagen, consulte Invalidaciones típicas.

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.

La oferta precompilada de Azure Marketplace crea automáticamente un recurso de dominio. Si usa el operador directamente, puede personalizar completamente cómo se representa el dominio. Para obtener información completa, consulte Recurso de dominio.

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.

La oferta precompilada de Azure Marketplace admite la afinidad de sesión a través del controlador de entrada de Application Gateway. Al implementar la oferta, seleccione Habilitar afinidad basada en cookies. Busque la afinidad basada en cookies en la documentación de la oferta.

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.

La oferta precompilada de Azure Marketplace admite bases de datos más populares. Para obtener más información, consulte Base de datos. Para Dominio en PV, puede establecerlos de la manera habitual, con WLST o con la consola de administración. Para dominio en imagen o modelo en imagen, consulte Invalidaciones típicas.

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?

Debe capturar estas personalizaciones en la imagen de contenedor que ejecuta AKS. Para la oferta precompilada de Azure Marketplace, estas personalizaciones se controlan mejor mediante la creación de una imagen de contenedor personalizada y la puesta a disposición en Azure Container Registry y, a continuación, apunta a ese registro en el momento de la implementación. Para obtener más información, consulte Selección de imágenes. Si usa el operador directamente, consulte Variables de entorno de memoria de JVM y Java.

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.

El único tipo de origen principal de dominio en el que tiene sentido seguir usando la administración a través de REST es Dominio en PV. Es posible usarlo con los otros tipos de origen de inicio del dominio, pero los cambios realizados son efímeros y no se conservan en los reinicios del pod.

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

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.

Estas bibliotecas se pueden controlar mediante las mismas técnicas que se describen en Determinar si WebLogic se ha personalizado.

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.

Puede incluirlos en war o EAR proporcionados a la oferta precompilada de Azure Marketplace o mediante el operador directamente.

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.

WLS en AKS se ejecuta en Oracle Linux. Cualquier código específico del sistema operativo debe ser compatible con Oracle Linux. Para obtener información sobre cómo detectar información específica del sistema operativo, siga los pasos descritos en Determinar si la versión de WebLogic es compatible.

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.

OSB no se admite directamente en la oferta precompilada de Azure Marketplace. Si debe usar OSB, debe usar el operador directamente.

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.

La oferta precompilada de Azure Marketplace admite WAR y EAR. El uso del operador directamente también admite WAR y EAR.

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.

El único tipo de origen principal de dominio que es compatible con el uso de WLST es Dominio en PV. Para obtener más información, consulte Dominio principal en un PV.

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

Kubernetes se ocupa de sistemas de archivos con volúmenes persistentes (PV). El montaje de volúmenes persistentes se admite en la oferta precompilada de Azure Marketplace y al usar el operador directamente. Si usa Dominio en PV, el sistema de archivos es un aspecto central de la configuración.

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.

Determinación de la topología de red

El conjunto actual de ofertas de Azure Marketplace es un punto de partida para la 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:

• Esta referencia enumera los temas generales relacionados con la migración de la topología de red a Azure: Guía de implementación de seguimiento rápido.
• En esta referencia se describen aspectos importantes relacionados con la agrupación en clústeres, que afecta a la topología de red: Agrupación en clústeres de servidores de WebLogic.
• Dado que los orígenes de datos son servidores independientes en un sistema WebLogic, debe incluirlos en el análisis de la topología de red. Orígenes de datos de servidores de WebLogic.
• Los orígenes de mensajería también son servidores independientes. Mensajería de servidor de WebLogic.
• El equilibrio de carga es un requisito fundamental. Esta referencia abarca el lado del servidor de WebLogic del equilibrio de carga: Equilibrio de carga en un clúster.

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

Si la implementación se basa en adaptadores de recursos, la opción más compatible es Dominio principal en un PV.

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.

Si la implementación se basa en proveedores de seguridad, la opción más compatible es Dominio principal en un PV.

Determinación de si se usa la agrupación en clústeres de WebLogic

El operador controla la agrupación en clústeres para todas las formas posibles de ejecutar WLS en AKS.

Inspección de la agrupación en clústeres ejb

Si la aplicación usa EJB local, debe migrarlas a EJB agrupado. Para obtener más información, consulte Agrupación en clúster frente a EJB local.

Requisitos del equilibrio de carga

La mejor manera de tener en cuenta el equilibrio de carga es usar la integración de App Gateway proporcionada por la oferta integrada de Azure Marketplace. Para más información, consulte Tutorial: Migración de un clúster de WebLogic Server a Azure con App de Azure lication Gateway como equilibrador de carga.

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

Si la implementación se basa en los clientes de aplicaciones de Java EE, es mejor usar el operador directamente. Para obtener más información, consulte Clientes externos.

Determinar si se necesitan varias imágenes de contenedor

Un dominio de WebLogic Server puede contener varios clústeres. Por ejemplo, una aplicación de varios niveles se puede representar en un solo dominio, pero tiene dos clústeres, por ejemplo, "front-end" y "back-end". Es útil poder actualizar el front-end, sin actualizar el back-end y viceversa. Sin embargo, con el tipo de origen modelo en el dominio de imagen principal, todo el dominio se representa en una imagen de contenedor. Para dar cabida a este caso de uso, debe separar los clústeres en sus propios dominios, cada uno con su propia imagen de contenedor. El operador puede administrar varios dominios en varios espacios de nombres. Para obtener más información, consulte Elegir una estrategia de selección de espacio de nombres de dominio.

La adopción de varios dominios puede presentar problemas de acceso T3 entre dominios. Para resolver estos problemas, habilite un canal personalizado como se describe en Determinar si es necesario habilitar el acceso desconocido al host.

Determinar si se necesita habilitar el acceso desconocido al host

Es posible que tenga que habilitar el acceso de host desconocido aplicando una revisión a WebLogic para los escenarios siguientes:

• Permitir el acceso de T3 desde clientes externos fuera de AKS a clústeres de WLS en AKS a través de un canal personalizado.
• Permitir el acceso de T3 entre diferentes dominios de WLS en AKS a través de un canal personalizado.

Para obtener los detalles de la revisión, siga las instrucciones de How to Use the Patch Search in My Oracle Support(MOS) and search for patch (Cómo usar la búsqueda de revisiones en My Oracle Support(MOS) y busque patch 30656708.

Una vez aplicada la revisión, consulte Habilitación del acceso desconocido al host.

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 https://aka.ms/wlsaks. Seleccione Crear y siga las instrucciones de la documentación de la oferta. Use la información recopilada en los pasos anteriores para ayudar a rellenar los campos de la oferta.

Migración de los dominios

Después de aprovisionar la oferta, siga estos pasos para generar el dominio.

Si ha navegado lejos de la página La implementación está en curso, los pasos siguientes le muestran cómo volver a esa página. Si todavía está en la página que muestra La implementación se ha completado, puede ir directamente al paso 5.

1. En la parte superior izquierda de cualquier página del portal, seleccione el menú hamburguesa y seleccione Grupos de recursos.

2. En el cuadro con el texto Filtrar para cualquier campo, escriba los primeros caracteres del grupo de recursos que creó anteriormente. Si ha seguido la convención recomendada, escriba sus iniciales y, a continuación, seleccione el grupo de recursos adecuado.

3. En el panel de navegación izquierdo, en la sección Configuración, seleccione Implementaciones para ver una lista ordenada de las implementaciones en este grupo de recursos, con la más reciente primero.

4. Desplácese hasta la entrada más antigua de esta lista. Esta entrada corresponde a la implementación que inició en la sección anterior. Seleccione la implementación más antigua, como se muestra en la captura de pantalla siguiente.

   

5. En el panel de la izquierda, seleccione Salidas. Esta lista muestra los valores de salida de la implementación. Se incluye información útil en las salidas. Estamos interesados en las salidas que nos permiten inspeccionar el dominio e interactuar con el operador. Los demás valores de las salidas se explican con detalle en la guía de usuario de WebLogic en AKS.

6. Busque la salida denominada shellCmdtoConnectAks. Pegue el valor de la salida en un shell de Bash y ejecute el comando . Este comando le permite usar kubectl como se describe en Conectar al clúster.

7. Busque la salida denominada shellCmdtoOutputWlsDomainYaml. Pegue el valor de la salida en un shell de Bash y ejecute el comando . Este comando genera el recurso de dominio como un archivo YAML.

8. Ahora que tiene el dominio YAML de la implementación actual, puede aplicar el conocimiento en Implementación de archivos YAML de recursos de dominio y revisar esta guía para obtener más pistas sobre cómo migrar los dominios. Esta guía requiere la adaptación para aplicar a la forma de hacer cosas de Kubernetes, pero sigue siendo útil saberlo.

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 siguiendo las instrucciones que se indican en Fusion Middleware: administración de recursos de JMS para Oracle WebLogic Server, en la documentación de WebLogic.

Cuenta para el registro

No se puede realizar la nube sin el registro de maestros. El operador proporciona ejemplos para usar Elasticsearch y Kibana. Para obtener más información, consulte la documentación del operador. Azure proporciona una excelente compatibilidad con Elastic. Para más información, consulte ¿Qué es la integración elástica con Azure?. Puede combinar los conocimientos de estos dos recursos para lograr una solución de registro optimizada para Azure para WLS en AKS.

Migración de las aplicaciones

Tanto si ha elegido proporcionar un archivo WAR o EAR en el momento de la implementación, debe actualizar la aplicación a través de CI/CD. La documentación del operador tiene un ejemplo que muestra cómo realizar esta actualización. Para obtener más información, consulte Update 3. Los otros ejemplos de actualización son relevantes para la migración y merece la pena explorar.

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

• Escalado. El escalado dinámico es una propuesta de valor clave para justificar la complejidad del uso de Kubernetes. Combine los conocimientos de Tutorial: Escalado de aplicaciones en Azure Kubernetes Service (AKS) con la sección de documentación del operador Escalado para lograr una solución de escalado optimizada para Kubernetes nativa de WLS. Es perfectamente posible usar soluciones populares fuera de la estantería, como Prometheus y Grafana para el escalado con WLS en AKS. Para obtener más información, consulte Uso de Prometheus y Grafana para supervisar WebLogic Server en Kubernetes. Azure tiene un servicio Grafana administrado. Para más información, consulte ¿Qué es Azure Managed Grafana?.

• Si ha implementado WebLogic Server con App de Azure lication Gateway siguiendo los pasos de la oferta, puede que quiera realizar más configuración en Application Gateway. Para más información, consulte Introducción a la configuración de Application Gateway.

• Mejorar la topología de red con servicios avanzados de equilibrio de carga. Para más información, consulte Uso de servicios de equilibrio de carga en Azure.

• Obtenga la supervisión del rendimiento de aplicaciones optimizadas para Java con Azure Monitor y Application Ideas. Para más información, consulte Supervisión de aplicaciones de instrumentación cero para Kubernetes- Azure Monitor Application Ideas.

• Use Azure Storage para proporcionar contenido estático montado en AKS. Para obtener más información, consulte Opciones de almacenamiento de aplicaciones en Azure Kubernetes Service (AKS). Combine este conocimiento con la sección de documentación del operador Proporcionar acceso a una notificación de volumen persistente.

• Implementar las aplicaciones en el clúster de WebLogic migrado con Azure DevOps. Para más información, consulte la documentación de introducción a Azure DevOps.

• Use Identidades administradas de Azure para administrar secretos y asignar acceso basado en roles a los recursos de Azure. Para más información, consulte ¿Qué es Managed Identities for Azure Resources?

• Integre la autenticación y autorización de Java EE de WebLogic con microsoft Entra ID. Para obtener más información, consulte Guía de introducción a la integración de Microsoft Entra.