Compartir a través de

Migración de aplicaciones de WebLogic Server a Azure Kubernetes Service (AKS)

  • Artículo

En esta guía se describe lo que hay que tener en cuenta para migrar una aplicación de WebLogic Server (WLS) existente a un contenedor de 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 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 la oferta de Azure Marketplace preconfigurada es un buen punto de partida

Una vez que haya decidido que AKS es el objetivo de implementación adecuado, debe aceptar que el operador Oracle WLS Kubernetes (el operador) es la única forma de ejecutar WLS en Kubernetes. Después de aceptar este hecho, debe decidir si la oferta preconstruida de Azure Marketplace es o no un buen punto de partida. Aquí hay algunas cosas a tener en cuenta sobre la oferta preconstruida de Azure Marketplace.

  • Oracle y Microsoft crearon esta oferta para permitirle aprovisionar rápidamente WLS en AKS utilizando el tipo de origen de dominio Modelo en imagen. Este concepto se explica con más detalle más adelante en este artículo.
  • A alto nivel, la oferta automatiza los siguientes pasos para usted.
    • Realice una implementación WAR o EAR existente, si lo desea.
    • Encapsúlelo 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 WebLogic Kubernetes Operator en AKS.
    • Use el operador para ejecutarlo todo. El operador invoca WebLogic Deploy Tooling (WDT) para levantar entornos WebLogic y realizar operaciones de ciclo de vida de dominio de forma repetible basadas en un modelo de metadatos. Para obtener más información, consulte WebLogic Deploy Tooling en la documentación de Oracle.
  • Aunque la oferta prediseñada proporciona numerosas integraciones de servicios Azure, como App Gateway, Elastic logging, integración de bases de datos, etc., hace muchas suposiciones de simplificación. Estas suposiciones hacen que la oferta no sea tan flexible como dominar y utilizar el operador uno mismo.

Si no utiliza la oferta prediseñada de Azure Marketplace, deberá aprender a utilizar el operador directamente. Dominar el operador está más allá del alcance de este artículo. La documentación completa del operador WLS Kubernetes está disponible en Oracle.

El resto de esta sección proporciona algunas consideraciones para decidir si utilizar la oferta prediseñada de Azure Marketplace o utilizar el operador directamente.

Decidir si utilizar la oferta prediseñada de Azure Marketplace

En primer lugar, hay que entender el concepto de "dominio" WLS. Un dominio es un grupo de recursos WLS relacionados lógicamente. Para la definición canónica de dominio WLS, consulte la documentación de Oracle. La ejecución de WLS en AKS requiere decidir cómo trata AKS los dominios. Las distintas opciones se denominan "tipo de origen de dominio". El operador WLS Kubernetes admite tres opciones de tipo de origen de dominio. La oferta prediseñada de Azure Marketplace utiliza la primera de esta tabla.

Tipo de origen principal de dominio Descripción Aspectos positivos Aspectos negativos
Modelo en imagen WLS y aplicaciones se encuentran en la imagen del contenedor, y todo lo demás se mantiene fuera de esa imagen. Compatible con la oferta prediseñada. Documentado como muestra oficial; consulte Oracle. Usa en mayor medida WDT. La opción más "nativa en la nube". Integración CI/CD más sencilla. Mayor curva de aprendizaje.
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 WLS para realizar cambios y esos cambios persisten a través de los reinicios del pod AKS. Documentado como muestra oficial; consulte Oracle. Deben mitigarse algunos retos 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 imagen El dominio reside en una imagen de contenedor. Las aplicaciones están contenidas en una imagen de contenedor superpuesta a la imagen del dominio. Más "nativo en la nube" que 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 tipo de origen Dominio en PV, recomendamos encarecidamente NFS en lugar de SMB. NFS evolucionó a partir del sistema operativo UNIX y otras variantes como GNU/Linux. Por este motivo, cuando se usa NFS con tecnologías de contenedor como Docker, es menos probable que tenga problemas para lecturas simultáneas y 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 hacerse una idea de la oferta preconstruida 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 preconstruida de Azure Marketplace, consulte Oracle.

Para familiarizarse con el uso directo del operador, pruebe los ejemplos de la documentación del operador.

Ahora que ya conoce las distintas formas de gestionar dominios WLS en AKS, podrá elegir mejor si usar la oferta prediseñada de Azure Marketplace o hacerlo usted mismo directamente desde el operador.

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

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

  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 dispone de un derecho de soporte, seleccione Middleware y, a continuación, busque weblogic_cpu. Seleccione weblogic_cpu.
  3. Si no tiene un derecho de soporte técnico para Oracle, seleccione Middleware y, a continuación, 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 parches críticos de Oracle, consulte Actualizaciones de parches críticos, alertas de seguridad y boletines.

La oferta prediseñada de Azure Marketplace le permite seleccionar las imágenes WLS de OCR y Azure Container Registry (ACR), por lo que es compatible de forma implícita con todas las versiones disponibles de OCR. Si indica a la oferta que extraiga una imagen de ACR, asegúrese de que se deriva de una de las versiones compatibles 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. Por ejemplo, resulta útil para guiar la selección del tamaño de las máquinas virtuales en el grupo de nodos, la cantidad de memoria que va a usar el contenedor y el número de recursos compartidos de CPU que necesitará el contenedor.

Es posible cambiar el tamaño de los grupos de nodos en AKS. Para obtener información sobre cómo hacerlo, consulte Cambio del 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 relativa a 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 prediseñada 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 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.

Si usa la oferta prediseñada de Azure Marketplace, el conjunto de recursos JNDI que puede personalizar en el momento de la implantación se limita a con lo que la oferta es compatible. 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 principal de dominio elegido. Para Dominio en PV, puede configurarlos de la forma habitual, con WLST o con la consola de administración. Para Dominio en imagen o Modelo en imagen, consulte Anulaciones 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 prediseñada de Azure Marketplace crea automáticamente un recurso de dominio. Si usa el operador directamente, puede personalizar completamente cómo se representa su 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 prediseñada de Azure Marketplace es compatible con la afinidad de sesión a través del controlador de entrada de Application Gateway. La afinidad basada en cookies está activada de forma predeterminada. Puede seleccionar Desactivar afinidad basada en cookies para desactivarla. 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 prediseñada de Azure Marketplace es compatible con las bases de datos más populares. Para obtener más información, consulte Base de datos. Para Dominio en PV, puede configurarlos de la forma habitual, con WLST o con la consola de administración. Para Dominio en imagen o Modelo en imagen, consulte Anulaciones 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 ejecutada por AKS. Para la oferta prediseñada de Azure Marketplace, estas personalizaciones se gestionan mejor creando una imagen de contenedor personalizada y poniéndola a disposición en Azure Container Registry, y luego apuntando a ese registro en el momento de la implementación. Para obtener más información, consulte Selección de imagen. Si usa el operador directamente, consulte Memoria JVM y variables de entorno de la opción 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 gestión a través de REST es Dominio en PV. Es posible usarlo con los otros tipos de origen de dominio, pero los cambios realizados son efímeros y no persisten en los reinicios de pods.

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.

Estas bibliotecas se pueden gestionar utilizando 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 incluirlas en el WAR o EAR suministrado a la oferta prediseñada de Azure Marketplace o a través del 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 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.

WLS en AKS se ejecuta en Oracle Linux. Cualquier código específico del SO debe ser compatible con Oracle Linux. Para saber cómo descubrir información específica del SO, siga los pasos indicados en Determine 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 prediseñada 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 prediseñada de Azure Marketplace es compatible con WAR y EAR. El uso directo del operador también es compatible con 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 de origen en un PV.

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

Kubernetes maneja sistemas de archivos con volúmenes persistentes (PV). El montaje de volúmenes persistentes es compatible con la oferta prediseñada de Azure Marketplace y cuando se usa 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.

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 su 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 su 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 se encarga de 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 su aplicación utiliza EJB locales, debe migrarlos a EJB en agrupados en clústeres. Para obtener más información, consulte EJB agrupado en clústeres frente a EJB locales.

Requisitos del equilibrio de carga

La mejor forma 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 obtener más información, consulte Tutorial: Migración de un clúster de WebLogic Server a Azure con Azure Application Gateway como equilibrador de carga.

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

Si su implementación depende de clientes de aplicaciones 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 puede representarse en un único dominio, pero tener dos clústeres, "frontend" y "backend". Es útil poder actualizar el frontend, sin actualizar el backend, y viceversa. Sin embargo, con el tipo de origen de dominio Modelo en imagen, todo el dominio se representa en una imagen contenedora. Para dar cabida a este caso práctico, debe separar los clústeres en sus propios dominios, cada uno con su propia imagen de contenedor. El operador puede gestionar 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 múltiples dominios puede introducir 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 de un host desconocido.

Determinar si es necesario habilitar el acceso de host desconocido

Es posible que tenga que habilitar el acceso de host desconocido aplicando un parche a WebLogic en los siguientes casos:

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

Para conocer los detalles del parche, siga las instrucciones de Cómo utilizar la búsqueda de parches en My Oracle Support(MOS) y busque el parche 30656708.

Una vez aplicado el parche, consulte Habilitación del acceso a host desconocido.

Migración

Los pasos de esta sección suponen que su análisis le ha llevado a decidir usar la oferta prediseñada 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 rellenar los campos de la oferta.

Migración de los dominios

Una vez que haya aprovisionado la oferta, genere el dominio siguiendo estos pasos.

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 el más reciente en primer lugar.

  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.

    Captura de pantalla de Azure Portal que muestra la lista de implementaciones del grupo de recursos.

  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. Nos interesan las salidas que nos permiten inspeccionar el dominio e interactuar con el operador. Los demás valores de las salidas se explican detalladamente en la guía del usuario de WebLogic en AKS.

  6. Localice la salida denominada shellCmdtoConnectAks. Pegue el valor de la salida en un intérprete de comandos Bash y ejecute el comando. Este comando le permite usar kubectl como se describe en Conexión al clúster.

  7. Localice la salida denominada shellCmdtoOutputWlsDomainYaml. Pegue el valor de la salida en un intérprete de comandos Bash y ejecute el comando. Este comando genera el recurso de dominio como un archivo YAML.

  8. Ahora que dispone del YAML de dominio de la implementación actual, puede aplicar los conocimientos de Implementación de archivos YAML de recursos de dominio y revisar esta guía para obtener más pistas sobre la migración de dominios. Esta guía requiere adaptación para aplicarse a la forma de hacer las cosas de Kubernetes, pero sigue siendo útil conocerla.

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 trabajar en la nube sin dominar el registro. El operador proporciona ejemplos para usar Elasticsearch y Kibana. Para obtener más información, consulte la documentación del operador. Azure proporciona un gran soporte para Elastic. Para obtener detalles completos, consulte ¿Qué es la integración de Elastic con Azure?. Puede combinar los conocimientos de estos dos recursos para conseguir una solución de registro optimizada para Azure para WLS en AKS.

Migración de las aplicaciones

Tanto si ha optado por proporcionar un archivo WAR o EAR en el momento de la implementación como si no, deberá 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 Actualización 3. Los otros ejemplos de actualización son relevantes para la migración y merece la pena explorarlos.

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: