Compartir a través de

Migración de aplicaciones de JBoss EAP a JBoss EAP en Azure App Service

  • Artículo

En esta guía se describe lo que debe tener en cuenta cuando quiera migrar una aplicación existente de Red Hat JBoss Enterprise Application Platform (EAP) para que se ejecute en JBoss EAP en una instancia de Azure App Service.

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

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

Inventariar todos los secretos

Revise todas las propiedades y archivos de configuración en los servidores de producción en busca de información confidencial y contraseñas. Asegúrese de comprobar jboss-web.xml en los archivos de Archivo de aplicaciones web (WAR). Los archivos de configuración que contienen contraseñas o credenciales también se pueden encontrar dentro de la aplicación.

Considere la posibilidad de almacenar dichos secretos en Azure KeyVault. Para más información, consulte Conceptos básicos de Azure Key Vault.

Puede usar secretos de Key Vault en la instancia de App Service con referencias de Key Vault. Las referencias de Key Vault le permiten usar los secretos de la aplicación mientras se mantienen protegidos y cifrados en reposo. Para más información, consulte Uso de referencias de Key Vault para App Service y Azure Functions.

Inventario de todos los certificados

Documente todos los certificados usados para los puntos de conexión SSL públicos. Para ver todos los certificados de los servidores de producción, ejecute el siguiente comando:

keytool -list -v -keystore <path to keystore>

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

JBoss EAP en App Service requiere una versión compatible de Java. Para obtener instrucciones sobre la versión del Kit de desarrollo de Java (JDK) que se va a usar, consulte configuraciones admitidas en la documentación de Red Hat.

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

Recursos externos de inventario

Los recursos externos, como fuentes de datos, brokers de mensajes del Java Message Service (JMS) y otros, se insertan a través de la Java Naming and Directory Interface (JNDI). Algunos de estos recursos pueden requerir migración o reconfiguración.

Dentro de tu aplicación

Inspeccione los archivos WEB-INF/jboss-web.xml y WEB-INF/web.xml. Busque elementos <Resource> dentro del elemento <Context>.

Orígenes de datos

Los orígenes de datos son recursos JNDI con el atributo type establecido en javax.sql.DataSource. Para cada origen de datos, documente 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 java Database Connectivity (JDBC)?

Para obtener más información, consulte Acerca de los orígenes de datos de JBoss Enterprise Application Platform (EAP) en la documentación de JBoss EAP.

Todos los demás recursos externos

No es factible documentar todas las dependencias externas posibles en esta guía. Es responsabilidad del equipo comprobar que puede cumplir todas las dependencias externas de la aplicación después de la migración.

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

Cualquier uso del sistema de archivos en el servidor de aplicaciones requiere reconfiguración o, en raras ocasiones, cambios arquitectónicos. Los módulos de JBoss EAP o el código de la aplicación pueden usar el sistema de archivos. Puede identificar algunos o todos los escenarios descritos en las secciones siguientes.

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.

Contenido dinámico o interno

En el caso de los archivos que la aplicación lee y escribe con frecuencia (por ejemplo, los archivos de datos temporales) o los archivos estáticos que solo son visibles para la aplicación, puede usar el almacenamiento de archivos local asociado al plan de App Service. Para más información, consulte Funcionalidad del sistema operativo en Azure App Service y Descripción del sistema de archivos de Azure App Service.

Determinación de si la aplicación se basa en trabajos programados

Los trabajos programados, como las tareas del programador de Quartz o los trabajos de cron de Unix, NO se deben usar con Azure App Service. App Service no le impedirá implementar una aplicación que contenga internamente tareas programadas. Sin embargo, si la aplicación se expande, un mismo trabajo programado se podría ejecutar más de una vez durante cada período programado. Esta situación puede tener consecuencias no deseadas.

Realice un inventario de todas las tareas programadas que se ejecutan en los servidores de producción, dentro o fuera del código de la aplicació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). 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 (AMQP) 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.

Determinación de si se están usando conectores de JCA

Si la aplicación usa conectores de Java Connector Architecture (JCA), valide que puede usar el conector JCA en JBoss EAP. Si puede usar el conector JCA en JBoss EAP, para que esté disponible, debe agregar los archivos de java Archive (JAR) a la ruta de clase de servidor y colocar los archivos de configuración necesarios en la ubicación correcta en los directorios del servidor JBoss EAP.

Determinación de si JAAS está en uso

Si la aplicación usa JAAS, deberá capturar cómo está configurado JAAS. Si utiliza una base de datos, puede convertirla en un dominio de JAAS en JBoss EAP. Si se trata de una implementación personalizada, deberá validar que se puede usar en JBoss EAP.

Determinación de si la aplicación usa un adaptador de recursos

Si la aplicación necesita un adaptador de recursos, debe ser compatible con JBoss EAP. Determine si el adaptador de recursos funciona correctamente en una instancia independiente de JBoss EAP; para ello, impleméntelo en el servidor y configúrelo correctamente. Si el adaptador de recursos funciona correctamente, tendrá que agregar los archivos JAR a la ruta de clase del servidor de App Service, y colocar los archivos de configuración necesarios en los directorios correspondientes del servidor de JBoss EAP para que esté disponible.

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, examine el archivo application.xml y capture la configuración.

Nota:

Si desea poder escalar cada una de sus aplicaciones web independientemente para un mejor uso de los recursos de App Service, debe dividir el EAR en aplicaciones web independientes.

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 daemons de monitorización, tendrá que eliminarlos o migrarlos.

Pruebas en contexto

Antes de crear las aplicaciones web, migre la aplicación a las versiones de JDK y JBoss EAP que quiere usar en App Service. Pruebe la aplicación exhaustivamente para garantizar su compatibilidad y rendimiento.

Notas sobre características de JBoss EAP en App Service

Cuando use JBoss EAP en App Service, asegúrese de tener en cuenta las notas siguientes.

  • Consola de administración de JBoss EAP: la consola web de JBoss no está expuesta en App Service. En su lugar, Azure Portal proporciona las API de administración de la aplicación y debe realizar la implementación mediante la CLI de Azure, el complemento Maven para Azure u otras herramientas de desarrollo de Azure. Se puede lograr una configuración adicional de los recursos de JBoss mediante la CLI de JBoss durante el inicio de la aplicación.

  • Transacciones: Se admite la API de Transacciones y hay compatibilidad con la recuperación automática de transacciones. Para más información, consulte Administración de transacciones en JBoss EAP en la documentación de Red Hat.

  • Modo de dominio administrado: en un entorno de producción de varios servidores, el modo de dominio administrado de JBoss EAP ofrece funcionalidades administradas centralizadas. Sin embargo, con JBoss EAP en App Service, la plataforma App Service asume la responsabilidad de la configuración y administración de las instancias de servidor. App Service elimina la necesidad de usar el modo de dominio administrado de JBoss EAP. El modo de dominio es una buena opción para las implementaciones de varios servidores basados en máquinas virtuales. Para más información, consulte Acerca de los dominios administrados en la documentación de Red Hat.

  • agrupación en clústeres de servidor a servidor: App Service admite totalmente implementaciones en clúster de JBoss EAP. Esto significa que puede usar con confianza:

    • Beans de sesión con estado.
    • Transacciones distribuidas.
    • Funciones similares que requieren comunicación de instancia a instancia o alta disponibilidad.

    Para más información, consulte la sección de clústeres de Configurar una aplicación Java para Azure App Service.

Migración

Kit de herramientas de migración para aplicaciones de Red Hat

El Kit de herramientas de migración para aplicaciones de Red Hat es una extensión gratuita para Visual Studio Code. Esta extensión analiza el código y la configuración de la aplicación para proporcionar recomendaciones para migrar a la nube desde el entorno local. Para obtener más información, consulte Información general sobre el kit de herramientas de migración para aplicaciones.

El contenido de esta guía le ayuda a abordar los demás componentes del recorrido de migración, como elegir el tipo de plan de App Service correcto, externalizar el estado de sesión y usar Azure para administrar las instancias de EAP en lugar de la interfaz de administración de JBoss.

Aprovisionamiento de Azure App Service para el runtime de JBoss EAP

Use los siguientes comandos para crear un grupo de recursos y un plan de Azure App Service. Una vez creado el plan de App Service, se crea un plan de aplicación web de Linux mediante el entorno de ejecución de JBoss Enterprise Application Platform (EAP).

Asegúrese de que las variables de entorno especificadas tienen los valores adecuados.

az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
    --resource-group $resourceGroup \
    --name $jbossAppService \
    --is-linux \
    --sku P0v3
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|8-java17"
    #  Or use "JBOSSEAP|8-java11" if you're using Java 11

Compilar la aplicación

Compile la aplicación con el comando de Maven siguiente.

mvn clean install -DskipTests

Implementación de la aplicación

Si la aplicación se ha creado a partir de un archivo POM de Maven, usará el complemento Webapp para Maven para crear la aplicación web e implementarla. Para obtener más información, consulte Inicio rápido: Creación de una aplicación Java en Azure App Service.

Para automatizar la implementación de las aplicaciones JBoss EAP, puede usar las herramientas de Azure Pipelines para WebApp o la acción de GitHub para implementar en Azure WebApp.

Configuración de orígenes de datos

Hay tres pasos principales al registrar un origen de datos con JBoss Enterprise Application Platform (EAP): cargando el controlador de Conectividad de base de datos java (JDBC), agregando el controlador JDBC como módulo y registrando el módulo. Para más información, consulte Administración de los orígenes de datos en la documentación de JBoss EAP. App Service es un servicio de hospedaje sin estado, por lo que los comandos de configuración para agregar y registrar el módulo de origen de datos deben incluirse en un script y aplicarse cuando se inicie el contenedor.

Para configurar orígenes de datos, siga estos pasos.

  1. Obtenga el controlador JDBC de la base de datos.

  2. Cree un archivo de definición de módulo XML para el controlador JDBC. El ejemplo que se muestra es una definición de módulo para PostgreSQL. Asegúrese de reemplazar el valor de resource-root path por la ruta de acceso al controlador JDBC que usa.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Coloque los comandos de la CLI de JBoss en un archivo denominado jboss-cli-commands.cli. Los comandos de JBoss deben agregar el módulo y registrarlo como un origen de datos. En el ejemplo se muestran los comandos de la CLI de JBoss para PostgreSQL.

    Nota:

    Microsoft recomienda usar el flujo de autenticación más seguro disponible. El flujo de autenticación descrito en este procedimiento, como para bases de datos, memorias caché, mensajería o servicios de inteligencia artificial, requiere un grado de confianza muy alto en la aplicación y conlleva riesgos que no están presentes en otros flujos. Use este flujo solo cuando las opciones más seguras, como las identidades administradas para conexiones sin contraseña o sin claves, no sean viables. En el caso de las operaciones de máquina local, prefiera identidades de usuario para conexiones sin contraseña o sin claves.

    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

  4. Cree un script de inicio denominado startup_script.sh que llame a los comandos de la CLI de JBoss. En el ejemplo se muestra cómo llamar al archivo jboss-cli-commands.cli. Más adelante, configure App Service para ejecutar este script cuando se inicie la instancia.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. Con el cliente FTP de su elección, cargue el controlador JDBC, jboss-cli-commands.cli, startup_script.sh y la definición del módulo en /site/deployments/tools/.

  6. Configure el sitio para que ejecute startup_script.sh al iniciarse el contenedor. En Azure Portal, vaya a Configuración > Configuración general > Comando de inicio. Establezca el campo del comando de inicio en /home/site/deployments/tools/startup_script.sh y seleccione Guardar.

  7. Reinicie la aplicación web, lo que hace que ejecute el script de configuración.

  8. Actualice la configuración del origen de datos de Java Transaction API (JTA) para la aplicación. Abra el archivo src/main/resources/META-INF/persistence.xml de su aplicación y busque el elemento <jta-data-source>. Reemplace su contenido como se muestra aquí:

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

Compilar la aplicación

Compile la aplicación con el comando de Maven siguiente.

mvn clean install -DskipTests

Implementación de la aplicación

Si la aplicación se ha creado a partir de un archivo POM de Maven, usará el complemento Webapp para Maven para crear la aplicación web e implementarla. Para obtener más información, consulte Inicio rápido: Creación de una aplicación Java en Azure App Service.

Para automatizar la implementación de las aplicaciones JBoss EAP, puede usar las herramientas de Azure Pipelines para WebApp o la acción de GitHub para implementar en Azure WebApp.

Después de la migración

Ahora que ha migrado la aplicación a Azure App Service, debe comprobar que funciona según lo previsto. Después de hacerlo, tenemos algunas recomendaciones para usted que pueden hacer que la aplicación sea más nativa de la nube.

Recomendaciones