Compartir a través de

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

  • Artículo

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

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.

Si no puede cumplir los requisitos previos a la migración, consulte la guía de migración complementaria:

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.

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>

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.

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 dos opciones:

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

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.

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?

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

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.

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.

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.

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.

Nota:

Si desea poder escalar cada una de las aplicaciones web de forma independiente para usar mejor los recursos de Azure Kubernetes Service, debe dividir los archivos 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 demonios de supervisión, tendrá que eliminarlos o migrarlos a otro lugar.

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

El uso de WildFly en Azure Kubernetes Service 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.

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

Consulte en Requisitos qué versión usar para ejecutar WildFly.

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

Los trabajos programados, como las tareas del Quartz Scheduler o los trabajos de Cron de Unix, NO se pueden usar con Azure Kubernetes Service (AKS). Azure Kubernetes Service no le impedirá implementar internamente una aplicación que contenga tareas programadas internamente. Sin embargo, si la aplicación se escala horizontalmente, un mismo trabajo programado se podría ejecutar más de una vez por cada período programado. Esta situación puede tener consecuencias no deseadas.

Para ejecutar trabajos programados en el clúster de AKS, defina los trabajos de Cron de Kubernetes que sean necesarios. Para más información, consulte Ejecución de tareas automatizadas con un trabajo de Cron.

Determinación de si se usa WebLogic Scripting Tool

Si actualmente usa WebLogic Scripting Tool (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, tendrá que asegurarse de que esos parámetros se ajusten a una de las siguientes opciones:

  • Los parámetros están externalizados como ajustes de la aplicación.
  • Los parámetros están incrustados en su aplicación.
  • Los parámetros usan la CLI de JBoss durante la implementación.

Si WLST hace algo más de lo que se ha mencionado anteriormente, tendrá que realizar algún trabajo extra durante la migración.

Determinación de si la aplicación usa API específicas de WebLogic

Si su aplicación usa API específicas de WebLogic, deberá refactorizarla para quitar esas dependencias. Por ejemplo, si ha usado una clase mencionada en la referencia de la API de Java para Oracle WebLogic Server, ha utilizado una API específica de WebLogic en la aplicación. Tendría que refactorizar para eliminar la referencia.

Determinación de si las aplicaciones usa beans de Entity o beans de CMP del estilo de EJB 2.x.

Si su aplicación usa beans de Entity o de CMP del estilo de EJB 2.x, debe refactorizar la aplicación para quitar estas dependencias.

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

Si tiene aplicaciones cliente que se conectan a la aplicación (servidor) mediante la característica de cliente de aplicación de Java EE, deberá refactorizar las aplicaciones cliente y la aplicación (servidor) para que usen las API HTTP.

Determinación de si se ha utilizado un plan de implementación

Si la aplicación se ha implementado mediante un plan de implementación, necesitará evaluar lo que está haciendo dicho plan. Si el plan es una implementación directa, podrá implementar la aplicación web sin realizar ningún cambio. Si el plan de implementación es más elaborado, necesitará determinar si puede usar la CLI de JBoss para configurar correctamente la aplicación como parte de la implementación. Si no es posible usar la CLI de JBoss, necesitará refactorizar la aplicación para que no se necesite un plan de implementación.

Determinación de si los temporizadores de EJB están en uso

Si la aplicación usa temporizadores de EJB, deberá validar que cada instancia de WildFly pueda desencadenar el código del temporizador de EJB de manera independiente. Esta validación es necesaria porque, en el escenario de implementación del Azure Kubernetes Service, cada temporizador de EJB se desencadenará en su propia instancia de WildFly.

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

Para usar el sistema de archivos en el servidor de aplicaciones será necesario cambiar la configuración o, en raras ocasiones, la arquitectura. Los módulos compartidos de WebLogic o el código de aplicación pueden usar el sistema de archivos. Es posible que identifique algunos o todos los escenarios descritos en las siguientes secciones.

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.

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 montar recursos compartidos de Azure Storage como volúmenes persistentes. Para más información, consulte Creación y uso de un volumen con Azure Files en Azure Kubernetes Service (AKS).

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

Si su aplicación usa conectores de JCA, tendrá que validar que el conector de JCA se puede usar en WildFly. Si la implementación de JCA está asociada a WebLogic, tendrá que refactorizar la aplicación para quitar esa dependencia. Si se puede usar, tendrá que agregar los archivos JAR a la ruta de acceso del servidor y colocar los archivos de configuración necesarios en la ubicación correcta de los directorios del servidor de WildFly para que esté disponible.

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 WildFly. Determine si el adaptador de recursos funciona correctamente en una instancia independiente de WildFly; 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 la imagen de Docker, y colocar los archivos de configuración necesarios en los directorios correspondientes del servidor de WildFly para que esté disponible.

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 WildFly. Si se trata de una implementación personalizada, deberá validar que se puede usar en WildFly.

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

Lo más probable es que haya implementado la aplicación en varios servidores de WebLogic para lograr alta disponibilidad. Azure Kubernetes Service tiene la capacidad de escalar, pero si ha usado Cluster API de WebLogic, tendrá que refactorizar el código para eliminar el uso de esa API.

Pruebas en contexto

Antes de crear las imágenes de contenedor, migre la aplicación a las versiones de JDK y Wildfly que piensa usar en AKS. Pruebe la aplicación exhaustivamente para garantizar su compatibilidad y rendimiento.

Migración

Aprovisionamiento de Azure Container Registry y Azure Kubernetes Service

Use los comandos siguientes para crear un registro de contenedor y un clúster de Azure Kubernetes cuya entidad de servicio tenga el rol de lector en el Registro. Asegúrese de elegir el modelo de red adecuado para los requisitos de red del clúster.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Creación de una imagen de Docker para WildFly

Para crear un archivo Dockerfile, necesitará lo siguiente:

  • Un JDK compatible.
  • Una instalación de WildFly.
  • Las opciones de su entorno de ejecución de JVM.
  • Una manera de pasar variables de entorno (si procede).

Después, puede realizar los pasos descritos en las secciones siguientes, si procede. Puede usar el repositorio de inicio rápido de contenedores de WildFly como punto de partida para su aplicación web y archivo Dockerfile.

Configuración de un volumen flexible de KeyVault

Cree un almacén de claves de Azure y rellene todos los secretos necesarios. Para más información, consulte Inicio rápido: Establecimiento y recuperación de un secreto desde Azure Key Vault mediante la CLI de Azurede Azure. Después, configure un volumen flexible de KeyVault para que esos secretos sean accesibles para los pods.

También necesitará actualizar el script de inicio que se usa para arrancar WildFly. Antes de iniciar el servidor, este script debe importar los certificados en el almacén de claves que WildFly use.

Configuración de orígenes de datos

Para configurar WildFly para acceder a un origen de datos, deberá agregar el archivo JAR del controlador JDBC a la imagen de Docker y, a continuación, ejecutar los comandos de la CLI de JBoss correspondientes. Estos comandos deben configurar el origen de datos al compilar la imagen de Docker.

En los pasos siguientes se proporcionan instrucciones para PostgreSQL, MySQL y SQL Server.

  1. Descargue el controlador JDBC para PostgreSQL, MySQL o SQL Server.

    Desempaquete el archivo descargado para obtener el archivo. jar del controlador.

  2. Cree un archivo con un nombre como module.xml y agregue el marcado siguiente. Reemplace el marcador de posición <module name> (incluidos los corchetes angulares) por org.postgres para PostgreSQL, com.mysql para MySQL o com.microsoft para SQL Server. Reemplace <JDBC .jar file path> por el nombre del archivo .jar del paso anterior, incluida la ruta de acceso completa a la ubicación en que colocará el archivo en la imagen de Docker, por ejemplo, /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Cree un archivo con un nombre como datasource-commands.cli y agregue el código siguiente. Reemplace <JDBC .jar file path> por el valor que usó en el paso anterior. Reemplace <module file path> por el nombre de archivo y la ruta de acceso del paso anterior, por ejemplo /opt/database/module.xml.

    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.

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/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=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --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
reload
run batch
shutdown

  4. Actualice la configuración del origen de datos de JTA de la aplicación:

    Abra el archivo de src/main/resources/META-INF/persistence.xml de la 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>

  5. Agregue lo siguiente a Dockerfile para crear el origen de datos al compilar la imagen de Docker.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Determine el valor de DATABASE_CONNECTION_URL porque es diferente para cada servidor de base de datos, y también es diferente de los valores de Azure Portal. WildFly necesita usar los formatos de dirección URL que se muestran aquí:

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. Al crear la implementación de YAML en una fase posterior, tendrá que pasar las siguientes variables de entorno, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME y DATABASE_SERVER_ADMIN_PASSWORD, con los valores adecuados.

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.

Para más información acerca de cómo configurar la conectividad de una base de datos con WildFly, consulte PostgreSQL, MySQL o SQL Server.

Configuración de recursos de JNDI

Para configurar cada uno de los recursos de JNDI que necesita configurar en WildFly, por lo general usará los siguientes pasos:

  1. Descargue los archivos JAR necesarios y cópielos en la imagen de Docker.
  2. Cree un archivo module.xml de WildFly que haga referencia a esos archivos JAR.
  3. Cree las configuraciones necesarias para el recurso de JNDI específico.
  4. Cree el script de la CLI de JBoss que se usará durante la compilación de Docker para registrar el recurso de JNDI.
  5. Agregue todo a Dockerfile.
  6. Pase las variables de entorno adecuadas en el archivo YAML de implementación.

En el ejemplo siguiente se muestran los pasos necesarios para crear el recurso de JNDI para la conectividad de JMS a Azure Service Bus.

  1. Descargue el proveedor de JMS de Apache Qpid.

    Desempaquete el archivo descargado para obtener los archivo. jar.

  2. Cree un archivo con un nombre como module.xml y agregue el marcado siguiente en /opt/servicebus. Asegúrese de que los números de versión de los archivos JAR están en línea con los nombres de los archivos JAR del paso anterior.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Cree un archivo jndi.properties en /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Cree un archivo con un nombre como servicebus-commands.cli y agregue el código siguiente.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Agregue lo siguiente a Dockerfile para crear el recurso de JNDI al compilar la imagen de Docker.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Al crear la implementación de YAML en una fase posterior, tendrá que pasar las siguientes variables de entorno, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC y SB_TOPIC con los valores adecuados.

Revisión de la configuración de WildFly

Revise la guía de administración de WildFly para más información sobre otros pasos previos a la migración que no estén incluidos en la guía anterior.

Compilación e inserción de la imagen de Docker en Azure Container Registry

Después de crear el archivo Dockerfile, deberá compilar la imagen de Docker y publicarla en Azure Container Registry.

Si ha usado nuestro repositorio de GitHub del inicio rápido de contenedores de WildFly, el proceso de compilación e inserción de la imagen en el registro de contenedor de Azure se haría invocando los tres comandos siguientes.

En estos ejemplos, la variable de entorno MY_ACR contiene el nombre del registro de contenedor de Azure y la variable MY_APP_NAME contiene el nombre de la aplicación web que quiere usar en su registro de contenedor de Azure.

Compile el archivo WAR:

mvn package

Inicie sesión en su registro de contenedor de Azure:

az acr login --name ${MY_ACR}

Compile e inserte la imagen:

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

También puede usar la CLI de Docker para compilar y probar primero la imagen localmente, tal y como se muestra en los siguientes comandos. Este enfoque puede simplificar las pruebas y perfeccionar la imagen antes de la implementación inicial en ACR. Sin embargo, requiere la instalación de la CLI de Docker y asegurarse de que el demonio de Docker se está ejecutando.

Compile la imagen:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Ejecute la imagen localmente:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Ahora puede acceder a su aplicación en http://localhost:8080.

Inicie sesión en su registro de contenedor de Azure:

az acr login --name ${MY_ACR}

Inserte la imagen en su registro de contenedor de Azure:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Para obtener información más detallada sobre la creación y el almacenamiento de imágenes de contenedor en Azure, consulte el módulo de aprendizaje Compilación y almacenamiento de imágenes de contenedor con Azure Container Registry.

Aprovisionamiento de una dirección IP pública

Si la aplicación va a ser accesible desde fuera de las redes internas o virtuales, necesitará una dirección IP estática pública. Debe aprovisionar esta dirección IP dentro del grupo de recursos del nodo del clúster, tal y como se muestra en el ejemplo siguiente:

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Implementación en Azure Kubernetes Service (AKS)

Cree y aplique los archivos YAML de Kubernetes. Para más información, consulte Inicio rápido: Implementación de un clúster de Azure Kubernetes Service (AKS) mediante la CLI de Azure. Si va a crear un equilibrador de carga externo (ya sea para la aplicación o para un controlador de entrada), asegúrese de proporcionar la dirección IP aprovisionada en la sección anterior como LoadBalancerIP.

Incluya los parámetros externalizados como variables de entorno. Para más información, consulte Definición de variables de entorno para un contenedor. No incluya secretos (por ejemplo, contraseñas, claves de API y cadenas de conexión de JDBC). Se tratan en las siguientes secciones.

Asegúrese de incluir la configuración de memoria y CPU al crear el archivo YAML de implementación para que los contenedores tengan el tamaño adecuado.

Configuración de almacenamiento persistente

Si su aplicación requiere almacenamiento no volátil, configure uno o más volúmenes persistentes.

Migración de los trabajos programados

Para ejecutar trabajos programados en el clúster de AKS, defina los trabajos de Cron de Kubernetes que sean necesarios. Para más información, consulte Ejecución de tareas automatizadas con un trabajo de Cron.

Después de la migración

Ahora que ha migrado la aplicación a Azure Kubernetes Service, debe comprobar que funciona como se espera. Una vez hecho esto, consulta las recomendaciones siguientes para que su aplicación se comporte de forma más nativa en la nube.

Recomendaciones