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

En esta guía se describe lo que hay que tener en cuenta cuando desees migrar una aplicación de WebSphere Application Server (WAS) existente a IBM WebSphere Liberty u Open Liberty que se ejecute 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 adecuado para su esfuerzo de migración

El primer paso para migrar una aplicación WAS a Azure con éxito es seleccionar el destino de migración más adecuado.

WAS tradicional funciona bien en máquinas virtuales Azure. El destino de la máquina virtual (VM) 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 similar a la de las instalaciones locales.

Otra opción es migrar a contenedores convirtiendo la carga de trabajo tradicional de WAS en contenedores de aplicaciones. Puede ejecutar el destino de contenedor en Azure Kubernetes Service (AKS) y Red Hat OpenShift en Azure. El inconveniente de esta facilidad es el coste económico.

En general, el coste por minuto de una solución basada en VM es mayor en comparación con los contenedores. Mientras que una solución basada en contenedores cuesta menos de ejecutar, debe restringir su 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 su esfuerzo de migración, considere una migración basada en máquinas virtuales. En este caso, consulte Migración de aplicaciones WebSphere a máquinas virtuales de Azure.

Si puede tolerar convertir su aplicación para que se ejecute dentro de contenedores para reducir el coste del tiempo de ejecución, considere una migración basada en AKS o en Red Hat OpenShift en Azure.

Para la migración basada en AKS, puede empezar utilizando el nivel gratis. Obtenga una gestión de clúster gratuita y pague únicamente por las máquinas virtuales, el almacenamiento asociado y los recursos de conexión de red consumidos. En este caso, consulte Migración de aplicaciones WebSphere a Kubernetes Service de Azure.

Para la migración basada en Red Hat OpenShift en Azure, además de los costes de computación e infraestructura, los nodos de aplicación tienen otro coste por el componente de licencia de OpenShift. Este coste se factura en función del número de nodos de aplicación y del tipo de instancia. Utilice precios bajo demanda o instancias reservadas, según lo que mejor se adapte a las necesidades de su carga de trabajo y su empresa. En este caso, consulte Migración de aplicaciones WebSphere a Red Hat OpenShift en Azure.

Las guías prácticas de la documentación de Red Hat OpenShift en Azure cubren algunos aspectos relevantes para la migración. Para obtener la lista completa de guías prácticas, consulte la documentación de Red Hat OpenShift en Azure.

Determinación de si la oferta de Azure Marketplace preconfigurada es un buen punto de partida

Después de haber decidido que Red Hat OpenShift en Azure es el objetivo de despliegue adecuado, debe aceptar que el operador IBM WebSphere Liberty u Open Liberty Operator (el operador) es la única forma de ejecutar Liberty 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 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.
  • A alto nivel, la oferta automatiza los siguientes pasos para usted.
    • Use una imagen de aplicación existente, si lo desea.
    • Aprovisionar un clúster Red Hat OpenShift en 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 ejecutarlo todo. El operador implementa y administra aplicaciones de Liberty en contenedores en Red Hat OpenShift en Azure. Puede encontrar la documentación de referencia en operator IBM WebSphere Liberty y operador Open Liberty.

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

Ahora que ya conoce las distintas formas de manejar Liberty en Red Hat OpenShift en Azure, podrá elegir mejor si utilizar la oferta prediseñada de Azure Marketplace o hacerlo usted mismo con 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 su versión existente de Liberty 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 preconstruida de Azure Marketplace le permite seleccionar sus imágenes de aplicaciones del registro público y, por lo 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 identificar y ver el contrato de licencia aplicable, consulte Visualización de la información de licencia para el operador webSphere Liberty. Para más información, consulte Ejecutar WebSphere Liberty en Microsoft Azure.

Si su edición de producto es distinta de la predeterminada IBM WebSphere Application Server (base), .spec.license.edition value debe especificar su edición de producto. Otros valores disponibles son IBM WebSphere Application Server Liberty Core e IBM WebSphere Application Server Network Deployment. La oferta prediseñada de Azure Marketplace le permite seleccionar la edición de producto admitida.

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

Para trasladar sus aplicaciones a WebSphere Application Server Liberty u Open Liberty, debe planificar la migración, analizar sus aplicaciones y actualizar el código fuente. IBM proporciona herramientas de migración para ayudarle a identificar las diferencias entre su entorno actual y las tecnologías de su 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, 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. Esta información, 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.

Para aprovechar la capacidad no usada con un importante ahorro de costes, es posible utilizar Azure Spot Virtual Machines en Red Hat OpenShift en Azure. Para saber cómo hacerlo, consulte Uso de máquinas virtuales Azure Spot en un clúster Red Hat OpenShift en Azure.

Inventariar 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, tenías un conjunto heterogéneo de opciones de configuración que, en la práctica, funcionaban como lo que hoy llamamos "secretos". Con los servidores de aplicaciones como WAS, estos secretos se encuentran en muchos archivos y almacenes de configuración diferentes. Revise todos los archivos de propiedades y de configuración del/los servidor(es) de producción en busca de secretos y contraseñas. Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación. WAS almacena los datos de configuración en varios documentos en una jerarquía de directorios en cascada. La mayoría de los documentos de configuración tienen contenido XML. Para obtener más información, consulte Documentos de configuración y Conceptos básicos de Azure Key Vault.

Después de que tenga un inventario sólido de secretos, consulte la documentación del operador relativa a los secretos. Vea los siguientes artículos para más información:

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 disponga de 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 deberá 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 más información, consulte Dependencias de la versión de Java para las funciones.

Open Liberty requiere un tiempo de ejecución Java SE. Puede ejecutarse utilizando una distribución de Java Runtime Environment (JRE) o de Java SE Development Kit (JDK). Para más información, consulte Versiones de Java SE compatibles.

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 recursos JNDI y bases de datos, consulte Fuentes de datos 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 JMS.

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. Para WebSphere Liberty en Azure Kubernetes Service (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 de Liberty. Para Open Liberty, consulte Java Naming and Directory Interface.

Inspeccione la configuración de su perfil

La principal unidad de configuración en WAS es el perfil. Como tal, el archivo resources.xml contiene una gran cantidad de configuración que debe considerar 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.

En tu aplicación

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

Debe capturar estas personalizaciones en la imagen del contenedor que ejecuta Red Hat OpenShift en Azure. Cuando se utiliza la oferta prediseñada de Azure Marketplace, estas personalizaciones se manejan mejor creando una imagen de contenedor personalizada y haciéndola disponible en un registro público, luego apuntando a ese registro en el momento de la implementación.

Si utiliza una célula de implementación de red de WebSphere Application Server, 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 desplegar un gran conjunto de componentes JEE disponibles.

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

Si su aplicación depende de la replicación de sesiones, dispone de las siguientes opciones:

  • Para las sesiones HTTP, según el nivel de administración de la sesión, puede usar la caché o una base de datos para recopilar los datos de la sesión.
  • Para las Sesiones distribuidas, puede guardar las sesiones en una base de datos a través de la persistencia de sesión de base de datos.
  • Para la Caché dinámica, puede administrar los datos de sesión en la caché o en una base de datos.
  • Puede refactorizar su aplicación para usar una base de datos para la administración de sesiones.
  • Puede refactorizar su 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 Liberty realiza la replicación del estado de sesión HTTP. Los siguientes documentos te ayudarán a entender cómo administrar sesiones HTTP en Liberty:

Orígenes de datos del documento

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 controladores JDBC en WAS, consulte Uso de controladores JDBC con WebSphere Application Server.

La configuración de JDBC es una configuración básica del servidor en Liberty. Para obtener más información, consulte Controlador JDBC.

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

Determine si se ha personalizado WAS

Identifique cuáles de las siguientes personalizaciones se han realizado y documente lo que se ha hecho.

  • ¿Se han cambiado los scripts de inicio? Estos scripts incluyen wsadmin, AdminControl, AdminConfig, AdminApp y AdminTask.
  • ¿Se han pasado parámetros específicos a JVM?
  • ¿Se han agregado archivos JAR a la ruta de clases del servidor?
  • ¿Se han utilizado instalaciones a nivel de sistema operativo como systemd para hacer que los componentes de WAS se inicien automáticamente tras un reinicio del 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 del contenedor que ejecuta Red Hat OpenShift en Azure. Cuando se utiliza la oferta prediseñada de Azure Marketplace, estas personalizaciones se manejan mejor creando una imagen de contenedor personalizada y haciéndola disponible en un registro público, luego 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 más información, consulte Connect an on-premises network to Azure (Conexión de una red local a Azure). Como alternativa, será necesario refactorizar la aplicación para usar las API públicas que exponen sus recursos de la infraestructura local.

Determinación de si las colas o los temas de Java Message Service (JMS) están en uso

Si su aplicación utiliza colas o temas JMS, debe migrarlos a un servidor JMS alojado externamente. Una estrategia para aquellos que utilizan JMS es utilizar Azure Service Bus y el protocolo Advanced Message Queuing Protocol. 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 ha configurado almacenes persistentes JMS, debe capturar su configuración y aplicarla después de la migración.

Si usa IBM MQ, puede migrar este software a máquinas virtuales de Azure y utilizarlo tal cual.

Microsoft dispone de una solución para integrar IBM MQ con Logic Apps. Para obtener más información, consulte Conexión a un servidor de 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 gestionar estas bibliotecas con las mismas técnicas que se describen en Acceso a API de terceros desde una aplicación Java EE.

Determinar si se utilizan bundles OSGi

Si ha utilizado bundles OSGi añadidos al WAS, deberá añadir los archivos JAR equivalentes directamente a su aplicación web.

Puede incluir los paquetes en la imagen incluida en la oferta predefinida 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 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.

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

Determine si se está utilizando IBM Integration Bus

Si su aplicación utiliza IBM Integration Bus, debe capturar cómo está configurado IBM Integration Bus. Para obtener más información, consulte la documentación de IBM Integration Bus.

IBM Integration Bus no es compatible directamente con la oferta preconfigurada de Marketplace de Azure. Para habilitar la función, 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 su 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 capturar sus configuraciones. Para obtener más información, consulte Diseño del paquete de archivo empresarial (EAR) en WebSphere.

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

Identifique todos los procesos externos y demonios que se ejecutan en los servidores de producción

Si tiene procesos que se ejecutan fuera del servidor de aplicaciones, como demonios de monitorización, tendrá que eliminarlos o migrarlos a otro entorno.

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

Kubernetes trabaja con sistemas de archivos con volúmenes persistentes (PV). No se admite el montaje de volúmenes persistentes en la oferta precompilada de Azure Marketplace. Para crear una clase de almacenamiento de Azure Files, siga las instrucciones de Crear una StorageClass de Azure Files en Red Hat OpenShift en Azure 4.

Contenido estático de solo lectura

Si la aplicación actualmente sirve contenido estático, necesita una ubicación alternativa para ella. Debe considerar la posibilidad de mover contenido estático a Azure Blob Storage y agregar Azure Front Door para descargas rápidas globalmente. Para más información, consulte hospedaje de sitios web estáticos en Azure Storage y Integración de una cuenta de Azure Storage con Azure Front Door.

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

La topología de red es un tema amplio, pero las siguientes referencias pueden orientar sus esfuerzos de migración:

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

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 Azure Kubernetes Service (AKS). Para obtener más información, consulte Introducción a los elementos de configuración de JCA y Java Connector Architecture.

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

El operador gestiona 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 su aplicación está utilizando Enterprise Java Beans (EJB) locales, es posible que necesite migrarlos a un EJB en clúster. Para obtener más información, consulte Desarrollo de aplicaciones EJB en Liberty.

Tenga en cuenta los requisitos de equilibrio de carga

La oferta prediseñada de Azure Marketplace utiliza una ruta integrada de OpenShift para alojar la aplicación en una URL pública y tener en cuenta el equilibrio de carga. Para obtener más información, consulte Configuración de rutas de OpenShift.

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

Cuenta de almacenes de claves

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

Conecte las fuentes JMS

Una vez conectadas las bases de datos, puede configurar JMS siguiendo las instrucciones de Introducción a los elementos de configuración de JCA en la documentación de IBM.

Cuenta para el registro

No puedes gestionar entornos cloud sin dominar la gestión de registros. El operador proporciona diferentes enfoques para la monitorización. Para obtener más información, consulte Supervisión del entorno de tiempo de ejecución del servidor Liberty. Es útil dominar el sistema de registro y monitorización en Red Hat OpenShift. Para obtener más información, consulte Comprensión del subsistema de registro para Red Hat OpenShift y Acerca de la supervisión de OpenShift Container Platform. Puede configurar Container Insights de Azure Monitor para Red Hat OpenShift en Azure. Para obtener más información, consulte Configurar la información del contenedor de Azure Monitor para Red Hat OpenShift en Azure. Si prefiere utilizar Elastic Stack, Azure proporciona un gran soporte para Elastic. Para obtener todos los detalles, consulte ¿Qué es la integración de Elastic con Azure? Puede combinar la información de estos recursos para lograr una solución de registros optimizada para Azure para Liberty en Red Hat OpenShift en Azure.

Migre sus aplicaciones

Tanto si elige proporcionar una imagen de la aplicación en el momento de la implementación como si no, necesitará actualizar la aplicación a través de CI/CD. La documentación de OpenShift tiene ejemplos que muestran cómo hacer esta actualización. Para obtener más información, consulte Información general de CI/CD de OpenShift Container Platform.

Configuración de pruebas

Debe configurar cualquier prueba de las aplicaciones en el contenedor 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. En los siguientes artículos se proporciona información sobre las mejoras posteriores a la migración:

  • Last updated on