Migración de aplicaciones de WebSphere a Red Hat OpenShift en Azure

  • Artículo

En esta guía se describe lo que debe tener en cuenta cuando desee migrar una carga de trabajo existente de WebSphere Application Server (WAS) a IBM WebSphere Liberty o Open Liberty que se ejecuta en Red Hat OpenShift en 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.

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 WAS a Azure es seleccionar el destino de migración más adecuado.

WAS tradicional se ejecuta bien en Azure Virtual Machines. El destino de la máquina virtual (VM) 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 análoga a lo que tiene en el entorno local.

Otra opción es migrar a contenedores mediante la conversión de la carga de trabajo tradicional was en contenedores de aplicaciones. Puede ejecutar el destino del contenedor en Azure Kubernetes Service (AKS) y Red Hat OpenShift en Azure. 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 los contenedores. Aunque una solución basada en contenedores cuesta menos ejecutarse, debe restringir la aplicación para que se ajuste a los requisitos de la plataforma de orquestación de contenedores.

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 de WebSphere a Azure Virtual Machines.

Si puede tolerar la conversión de la aplicación para que se ejecute dentro de contenedores para reducir el costo en tiempo de ejecución, considere la posibilidad de una migración basada en AKS o basada en Red Hat OpenShift en Azure.

Para la migración basada en AKS, puede empezar a usar el nivel Gratis. Obtenga la administración gratuita de clústeres y pague solo por las máquinas virtuales, el almacenamiento asociado y los recursos de red consumidos. En este caso, consulte Migración de aplicaciones de WebSphere a Azure Kubernetes Service.

Para la migración basada en Red Hat OpenShift de Azure, además de los costos de proceso e infraestructura, los nodos de aplicación tienen otro costo para el componente de licencia de OpenShift. Este costo se factura en función del número de nodos de aplicación y del tipo de instancia. Use los precios a petición o las instancias reservadas, lo que mejor satisfaga la necesidad de la carga de trabajo y la empresa. En este caso, consulte Migración de aplicaciones de WebSphere a Red Hat OpenShift en Azure.

Las guías paso a paso de la documentación de Red Hat OpenShift de Azure tratan algunos aspectos relevantes para la migración. Para obtener la lista completa de guías paso a paso, consulte la documentación de Red Hat OpenShift de Azure.

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

Después de decidir que Red Hat OpenShift en Azure es el destino de implementación adecuado, debe aceptar que el operador IBM WebSphere Liberty o open Liberty Operator (el operador) es la única manera de ejecutar Liberty 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:

  • IBM y Microsoft crearon esta oferta para permitirle aprovisionar rápidamente Liberty en Red Hat OpenShift en Azure. Este concepto se explica con más detalle en el siguiente contenido.
  • En un nivel alto, la oferta automatiza los pasos siguientes.
    • Tome una imagen de aplicación existente, si lo desea.
    • Aprovisione un clúster de Red Hat OpenShift de Azure, si lo desea.
    • Instale y configure el operador IBM WebSphere Liberty o el operador Open Liberty en Red Hat OpenShift en Azure.
    • Use el operador para ejecutar todo. El operador implementa y administra aplicaciones de Liberty en contenedor en Red Hat OpenShift en Azure. Puede encontrar la documentación de referencia en el operador IBM WebSphere Liberty y el operador Open Liberty.

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 está disponible en el operador IBM WebSphere Liberty y el operador Open Liberty.

Ahora que se ha presentado a las distintas formas de controlar Liberty en Red Hat OpenShift en Azure, es mejor que pueda elegir si va a usar la oferta precompilada de Azure Marketplace o para hacerlo usted mismo mediante el operador directamente.

Determinar si la versión de Liberty es compatible

Necesita el operador open Liberty o el operador de WebSphere Liberty para implementar y administrar aplicaciones en clústeres basados en Kubernetes. Asegúrese de que la versión de Liberty existente es una de las versiones compatibles con el operador . Las versiones de Open Liberty se mantienen en GitHub OpenLiberty/open-liberty. IBM mantiene versiones de IBM WebSphere Application Server Liberty. Para obtener más información, consulte WebSphere Application Server Liberty.

La oferta precompilada de Azure Marketplace permite seleccionar las imágenes de aplicación del registro público y, por tanto, admite implícitamente todas las versiones.

Determinar si se necesita una licencia

Para IBM WebSphere Liberty, debe aceptar los términos del contrato de licencia correspondiente a la versión del programa IBM en el contenedor de aplicaciones. Para obtener el contrato de licencia aplicable a este programa IBM, consulte Visualización de la información de licencia para el operador webSphere Liberty. Para más información, consulte Ejecución de WebSphere Liberty en Microsoft Azure.

Si la edición del producto es algo distinto del valor predeterminado ibm WebSphere Application Server (base), debe especificar la .spec.license.edition value edición del producto. Otros valores disponibles son IBM WebSphere Application Server Liberty Core y IBM WebSphere Application Server Network Deployment. La oferta precompilada de Azure Marketplace permite seleccionar la edición del producto compatible.

Diferencias de inventario con las herramientas de migración de IBM

Para mover las aplicaciones a WebSphere Application Server Liberty o Open Liberty, debe planear la migración, analizar las aplicaciones y actualizar el código fuente. IBM proporciona herramientas de migración para ayudar a identificar las diferencias entre su entorno actual y las tecnologías del nuevo entorno Liberty, como Java EE 7 o Java EE 8, y Java SE 8 o Java SE 11. Para obtener más información, consulte Migración de aplicaciones a Liberty.

Capacidad del servidor de inventario

Documente el hardware (memoria, CPU, disco) de los servidores de producción actuales y el recuento medio y máximo de solicitudes y el uso de recursos. Necesita esta información independientemente de la ruta de migración que elija. Esta información es útil, por ejemplo, para ayudar a guiar la selección del tamaño de las máquinas virtuales del nodo, la cantidad de memoria que usará el contenedor y cuántos recursos compartidos de CPU necesitaría el contenedor.

Para aprovechar la capacidad sin usar con un ahorro significativo de costos, es posible usar máquinas virtuales de acceso puntual de Azure en Red Hat OpenShift en Azure. Para más información, consulte Uso de máquinas virtuales de acceso puntual de Azure en un clúster de Red Hat OpenShift en Azure.

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 servidores de aplicaciones como WAS, 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. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. WAS almacena datos de configuración en varios documentos en una jerarquía en cascada de directorios. La mayoría de los documentos de configuración tienen contenido XML. Para más información, consulte Los documentos de configuración y los conceptos básicos de Azure Key Vault.

Después de tener un inventario sólido de secretos, consulte la documentación del operador sobre los secretos. Para más información, consulte los siguientes artículos.

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>

Después de tener un inventario sólido de certificados, configúrelos mediante los siguientes artículos:

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

El uso de Liberty requiere una versión específica de Java, por lo que debe confirmar que la aplicación se ejecuta correctamente con esa versión compatible.

El tiempo de ejecución de WebSphere Application Server Liberty tiene requisitos específicos para el nivel mínimo de Java Runtime Environment (JRE). Para obtener más información, consulte Dependencias de versiones de Java para características.

Open Liberty requiere un entorno de ejecución de Java SE. Se puede ejecutar mediante una distribución de Java Runtime Environment (JRE) o java SE Development Kit (JDK). Para obtener más información, consulte Versiones de Java SE admitidas.

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 obtener más información sobre los recursos y bases de datos JNDI, consulte Orígenes de datos de WebSphere en la documentación de IBM. 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 Uso de recursos de JMS.

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. Para WebSphere Liberty en AKS, puede hacer que un objeto esté disponible en el espacio de nombres de Java Naming and Directory Interface (JNDI) predeterminado. Para obtener más información, consulte Desarrollo con el espacio de nombres predeterminado de JNDI en una característica Liberty. Para Open Liberty, consulte Java Naming and Directory Interface(Interfaz de directorio y nomenclatura de Java).

Inspección de la configuración del perfil

La unidad de configuración principal de WAS es el perfil. Por lo tanto, el archivo resources.xml contiene una gran cantidad de configuraciones que debe tener en cuenta cuidadosamente para la migración. El archivo incluye referencias a otros archivos XML que se almacenan en subdirectorios. Para obtener más información, consulte Administración de perfiles en sistemas operativos distribuidos e IBM i.

Dentro de la aplicación

Inspeccione el archivo deployment.xml o el archivo WEB-INF/web.xml .

Debe capturar estas personalizaciones en la imagen de contenedor que ejecuta Red Hat OpenShift en Azure. Cuando se usa 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 un registro público y, a continuación, apuntando a ese registro en el momento de la implementación.

Si usa una celda WebSphere Application Server Network Deployment, cada miembro del clúster se ejecuta en una instalación de WAS tradicional. Liberty es un perfil ligero de WebSphere Application Server. Es un perfil flexible y dinámico de WAS, que permite al servidor WAS implementar solo las características personalizadas necesarias en lugar de implementar un gran conjunto de componentes JEE disponibles.

Determinación de si se usa la replicación de sesión

Si la aplicación se basa en la replicación de sesión, tiene las siguientes opciones:

  • En el caso de las sesiones HTTP, según el nivel de administración de sesiones, puede usar la memoria caché o una base de datos para recopilar datos de sesión.
  • En el caso de las sesiones distribuidas, puede guardar sesiones en una base de datos mediante la persistencia de la sesión de base de datos.
  • En el caso de la caché dinámica, puede administrar los datos de sesión en la memoria caché o en una base de datos.
  • Puede refactorizar la aplicación para usar una base de datos para la administración de sesiones.
  • Puede refactorizar la aplicación para externalizar la sesión en Azure Redis Service. Para más información, consulte Azure Cache for Redis.

Para todas estas opciones, es una buena idea dominar cómo Liberty realiza la replicación de estado de sesión HTTP. Los siguientes documentos le ayudan a comprender cómo administrar sesiones HTTP en Liberty:

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 obtener más información sobre los controladores JDBC en WAS, consulte Uso de controladores JDBC con WebSphere Application Server.

La configuración de JDBC es una configuración de servidor principal en Liberty. Para obtener más información, vea Controlador JDBC.

La oferta precompilada de Azure Marketplace tiene compatibilidad limitada con bases de datos. Puede controlar la configuración en las imágenes de la aplicación y usar la imagen al implementar la oferta.

Determinar si WAS se ha personalizado

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 incluyen wsadmin, Administración Control, Administración Config, Administración App y Administración Task.
  • ¿Se han pasado parámetros específicos a JVM?
  • ¿Se han agregado archivos JAR a la ruta de clases del servidor?
  • ¿Se han usado instalaciones de nivel de sistema operativo como systemd para hacer que los componentes WAS se inicien automáticamente después de reiniciar un servidor?

Debe tener en cuenta las consideraciones de migración en función de las respuestas a estas preguntas.

Debe capturar estas personalizaciones en la imagen de contenedor que ejecuta Red Hat OpenShift en Azure. Cuando se usa 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 un registro público y, a continuación, apuntando a ese registro en el momento de la implementación.

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 usa colas o temas de JMS, debe migrarlas a un servidor JMS hospedado externamente. Una estrategia para aquellos que usan JMS es usar Azure Service Bus y advanced Message Queuing Protocol. Para más información, consulte Uso de JMS con Azure Service Bus y AMQP 1.0.

Si ha configurado almacenes persistentes de JMS, debe capturar su configuración y aplicarla después de la migración.

Si usa IBM MQ, puede migrar este software a Azure Virtual Machines y usarlo tal cual.

Microsoft tiene una solución para integrar IBM MQ con Logic Apps. Para más información, consulte Conectar a un servidor IBM MQ desde un flujo de trabajo en Azure Logic Apps.

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.

Puede controlar estas bibliotecas con las mismas técnicas que se describen en Acceso a las API de terceros desde una aplicación java EE.

Determinación de si se usan agrupaciones OSGi

Si ha usado agrupaciones de OSGi agregadas a WAS, debe agregar los archivos JAR equivalentes directamente a la aplicación web.

Puede incluir las agrupaciones en la imagen proporcionada a la oferta precompilada de Azure Marketplace. Para obtener más información, consulte Configuración de bibliotecas para aplicaciones OSGi.

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.

Liberty en Red Hat OpenShift en Azure se ejecuta en x86_64 linux. Cualquier código específico del sistema operativo debe ser compatible con Linux. Para obtener información sobre cómo detectar información específica del sistema operativo, siga los pasos descritos en la sección Determinar si la versión de Liberty es compatible .

Determinar si IBM Integration Bus está en uso

Si la aplicación usa IBM Integration Bus, debe capturar cómo se configura IBM Integration Bus. Para obtener más información, consulte la documentación de IBM Integration Bus.

IBM Integration Bus no se admite directamente en la oferta precompilada de Azure Marketplace. Para habilitar la característica, siga las instrucciones de Habilitación de la aplicación JMS en Liberty para conectarse al bus de integración de servicios en la documentación de IBM.

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, ibm-application-bnd.xmi e ibm-application-ext.xmi y capture sus configuraciones. Para obtener más información, consulte Creación del paquete de archivo empresarial (EAR) en WebSphere.

La oferta precompilada de Azure Marketplace permite usar una imagen de contenedor existente. Puede preparar la aplicación según sus requisitos empresariales.

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 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 no se admite en la oferta precompilada de Azure Marketplace. Para crear una clase StorageClass de Azure Files, siga las instrucciones de Creación de una clase StorageClass de Azure Files en Red Hat OpenShift 4 de Azure.

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 aspectos de la arquitectura que necesita migrar, debe capturar la topología de red de la implementación existente. A continuación, debe reproducir esa topología en Azure, incluso después de mantener la oferta básica con una de las plantillas de solución.

La topología de red es un tema amplio, pero las siguientes referencias pueden dar alguna dirección a los esfuerzos de migración:

  • Para obtener una enumeración de los temas de alto nivel relevantes para la migración de la topología de red a Azure, consulte Topologías de implementación de red de WebSphere Application Server.
  • Dado que los orígenes de datos son servidores independientes en un sistema Liberty, debe considerarlos como parte del análisis de topología de red. Para obtener más información, consulte Orígenes de datos de WebSphere Application Server Liberty.
  • Los orígenes de mensajería también son servidores independientes. Para obtener más información, consulte WebSphere Application Server Liberty: Mensajería de WebSphere MQ.
  • El equilibrio de carga es un requisito fundamental. Para obtener información sobre el lado Liberty del equilibrio de carga, consulte Arquitectura colectiva de WebSphere Application Server Liberty.

Tener en cuenta el uso de adaptadores y adaptadores de recursos de JCA

Si la aplicación existente usa adaptadores de JCA o adaptadores de recursos para conectarse a otros sistemas empresariales, asegúrese de aplicar la configuración de estos artefactos al servidor Liberty que se ejecuta en AKS. Para obtener más información, consulte Información general sobre los elementos de configuración de JCA y la arquitectura de Conectar or de Java.

Determinar si se usa la agrupación en clústeres

El operador controla la agrupación en clústeres para todas las formas posibles de ejecutar una carga de trabajo WAS en Red Hat OpenShift en Azure.

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

Si la aplicación usa Enterprise Java Beans (EJB) local, es posible que tenga que migrarlas a un EJB agrupado. Para obtener más información, consulte Desarrollo de aplicaciones EJB en Liberty.

Requisitos del equilibrio de carga

La oferta precompilada de Azure Marketplace usa una ruta integrada de OpenShift para hospedar la aplicación en una dirección URL pública y una cuenta para el equilibrio de carga. Para obtener más información, consulte Configuración de ruta de OpenShift.

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 IBM WebSphere Liberty y Open Liberty en Azure Red Hat OpenShift. Seleccione Crear y, a continuación, use la información recopilada en los pasos anteriores para ayudar a rellenar los campos de la oferta.

Cuenta de almacenes de claves

Debe tener en cuenta la migración de cualquier almacén de claves SSL/TLS 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

Después de conectar las bases de datos, puede configurar JMS siguiendo las instrucciones de Información general de los elementos de configuración de JCA en la documentación de IBM.

Cuenta para el registro

No se puede realizar la nube sin el registro de maestros. El operador proporciona diferentes enfoques para la supervisión. Para obtener más información, consulte Supervisión del entorno de tiempo de ejecución del servidor Liberty. Resulta útil dominar el registro y el sistema de supervisión en Red Hat OpenShift. Para obtener más información, consulte Descripción del subsistema de registro para Red Hat OpenShift y Acerca de la supervisión de OpenShift Container Platform. Puede configurar Azure Monitor Container Insights para Red Hat OpenShift en Azure. Para más información, consulte Configuración de Azure Monitor Container Insights para Red Hat OpenShift en Azure. Si prefiere usar Elastic Stack, 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 recursos para lograr una solución de registro optimizada para Azure para Liberty en Red Hat OpenShift en Azure.

Migre sus aplicaciones

Tanto si ha elegido proporcionar una imagen de aplicación en el momento de la implementación, debe actualizar la aplicación a través de CI/CD. La documentación de OpenShift tiene ejemplos que muestran cómo realizar esta actualización. Para obtener más información, consulte Introducción a CI/CD de OpenShift Container Platform.

Configuración de pruebas

Debe configurar las pruebas dentro del contenedor en las aplicaciones para acceder a los nuevos servidores que se ejecutan en Azure. Al igual que sucede con los problemas de CI/CD, debe asegurarse de que las reglas de seguridad de red necesarias permiten que las pruebas accedan 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. En los artículos siguientes se proporciona información sobre las mejoras posteriores a la migración: