Condividi tramite

Eseguire la migrazione di applicazioni WebLogic Server a WildFly in servizio Azure Kubernetes

  • Articolo

Questa guida descrive gli elementi da tenere presenti quando si vuole eseguire la migrazione di un'applicazione WebLogic Server esistente per l'esecuzione in WildFly in un contenitore servizio Azure Kubernetes.

Pre-migrazione

Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.

Se non è possibile soddisfare i requisiti di pre-migrazione, vedere la guida alla migrazione complementare:

Inventario della capacità dei server

Documentare l'hardware (memoria, CPU, disco) dei server di produzione correnti e il numero medio e massimo di richieste e l'utilizzo delle risorse. Queste informazioni saranno necessarie indipendentemente dal percorso di migrazione scelto. È utile, ad esempio, per guidare la selezione delle dimensioni delle macchine virtuali nel pool di nodi, la quantità di memoria da usare dal contenitore e il numero di condivisioni di CPU necessarie per il contenitore.

È possibile ridimensionare i pool di nodi nel servizio Azure Kubernetes. Per informazioni su come, vedere Ridimensionare i pool di nodi in servizio Azure Kubernetes (servizio Azure Kubernetes).

Inventario di tutti i segreti

Prima della comparsa di tecnologie di tipo "configurazione come servizio", ad esempio Azure Key Vault, non esisteva un concetto ben definito di "segreti". Era invece disponibile un set disparato di impostazioni di configurazione assimilabili a quello che ora chiamiamo "segreti". Con i server app come WebLogic Server, questi segreti si trovano in molti file e archivi di configurazione diversi. Controllare tutte le proprietà e i file di configurazione nei server di produzione per verificare la presenza di segreti e password. Assicurarsi di controllare weblogic.xml nei WAR. I file di configurazione contenenti password o credenziali possono trovarsi anche all'interno dell'applicazione. Per altre informazioni, vedere Concetti di base di Azure Key Vault.

Inventario di tutti i certificati

Documentare tutti i certificati usati per gli endpoint SSL pubblici. È possibile visualizzare tutti i certificati nei server di produzione eseguendo il comando seguente:

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

Inventario delle risorse JNDI

Creare un inventario di tutte le risorse JNDI. Ad esempio, le origini dati, come i database, possono avere un nome JNDI associato che consente a JPA di associare correttamente le istanze di EntityManager a un database specifico. Per altre informazioni su risorse e database JNDI, vedere Origini dati di WebLogic Server nella documentazione di Oracle. Altre risorse correlate a JNDI, ad esempio i broker di messaggi JMS, possono richiedere la migrazione o la riconfigurazione. Per altre informazioni sulla configurazione di JMS, vedere Oracle WebLogic Server 12.2.1.4.0.

Determinare se viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica delle sessioni, con o senza Oracle Coherence*Web, sono disponibili due opzioni:

  • Effettuare il refactoring dell'applicazione per l'uso di un database per la gestione delle sessioni.
  • Effettuare il refactoring dell'applicazione per esternalizzare la sessione nel servizio Azure Redis. Per altre informazioni, vedere Azure Cache for Redis.

Documentare le origini dati

Se l'applicazione usa qualsiasi database, è necessario acquisire le informazioni seguenti:

  • Qual è il nome dell'origine dati?
  • Qual è la configurazione del pool di connessioni?
  • Dove è possibile trovare il file JAR del driver JDBC?

Per altre informazioni sui driver JDBC in WebLogic, vedere Uso dei driver JDBC con WebLogic Server.

Determinare se WebLogic è stato personalizzato

Determinare quali delle seguenti personalizzazioni sono state apportate e acquisire informazioni sulle attività eseguite.

  • Gli script di avvio sono stati cambiati? Tali script includono setDomainEnv, commEnv, startWebLogic e stopWebLogic.
  • Sono stati passati parametri specifici alla JVM?
  • Sono stati aggiunti JAR al classpath del server?

Determinare se è necessaria una connessione all'ambiente locale

Se l'applicazione deve accedere ai servizi locali, è necessario effettuare il provisioning di uno dei servizi di connettività di Azure. Per altre informazioni, vedere Connettere una rete locale ad Azure. In alternativa, è necessario effettuare il refactoring dell'applicazione per usare le API disponibili pubblicamente esposte dalle risorse locali.

Determinare se sono in uso code o argomenti di JMS (Java Message Service)

Se l'applicazione usa code o argomenti di JMS, sarà necessario eseguirne la migrazione a un server JMS ospitato esternamente. Il bus di servizio di Azure e il protocollo AMQP (Advanced Message Queueing Protocol) possono risultare un'ottima strategia di migrazione se si usa JMS. Per altre informazioni, vedere Usare Java Message Service 1.1 con bus di servizio di Azure standard e AMQP 1.0.

Se sono stati configurati archivi persistenti JMS, è necessario acquisire la relativa configurazione e applicarla dopo la migrazione.

Determinare se si usano librerie Java EE condivise personalizzate

Se si usano librerie Java EE condivise, sono disponibili due opzioni:

  • Effettuare il refactoring del codice dell'applicazione per rimuovere tutte le dipendenze dalle librerie e incorporare la funzionalità direttamente nell'applicazione.
  • Aggiungere le librerie al classpath del server.

Determinare se vengono usati bundle OSGi

Se sono stati aggiunti bundle OSGi a WebLogic Server, è necessario aggiungere i file JAR equivalenti direttamente nell'applicazione Web.

Determinare se l'applicazione contiene codice specifico del sistema operativo

Se l'applicazione contiene codice con dipendenze dal sistema operativo host, è necessario effettuare il refactoring per rimuovere tali dipendenze. Ad esempio, potrebbe essere necessario sostituire qualsiasi uso di o \ nei percorsi del / file system con File.Separator o Paths.get se l'applicazione è in esecuzione in Windows.

Determinare se il bus di servizio di Oracle è in uso

Se l'applicazione usa il bus di servizio di Oracle, sarà necessario acquisire la relativa configurazione. Per altre informazioni, vedere Informazioni sull'installazione del bus di servizio di Oracle.

Determinare se l'applicazione è costituita da più WAR

Se l'applicazione è costituita da più WAR, è consigliabile considerarli come applicazioni distinte e seguire i rispettivi argomenti di questa guida.

Determinare se l'applicazione è assemblata come EAR

Se l'applicazione è assemblata come file EAR, assicurarsi di esaminare i file application.xml e weblogic-application.xml e acquisire le relative configurazioni.

Nota

Se si vuole essere in grado di ridimensionare ognuna delle applicazioni Web in modo indipendente per un uso migliore delle risorse servizio Azure Kubernetes, è consigliabile suddividere EAR in applicazioni Web separate.

Identificare tutti i processi e daemon esterni in esecuzione nei server di produzione

Se sono in esecuzione processi all'esterno del server applicazioni, ad esempio daemon di monitoraggio, sarà necessario eliminarli o trasferirli altrove.

Verificare che la versione di Java supportata funzioni correttamente

L'uso di WildFly nel servizio Azure Kubernetes richiede una versione specifica di Java, quindi è necessario verificare che l'applicazione funzioni correttamente usando tale versione supportata.

Nota

Questa convalida è particolarmente importante se il server corrente è in esecuzione in un JDK non supportato, ad esempio Oracle JDK o IBM OpenJ9.

Per ottenere la versione corrente di Java, accedere al server di produzione ed eseguire il comando seguente:

java -version

Per informazioni sulla versione da usare per l'esecuzione di WildFly, vedere Requisiti.

Determinare se l'applicazione si basa su processi pianificati

I processi pianificati, ad esempio le attività dell'utilità di pianificazione di Quarzi o i processi Unix cron, non devono essere usati con servizio Azure Kubernetes (servizio Azure Kubernetes). Il servizio Azure Kubernetes non impedisce la distribuzione interna di un'applicazione contenente attività pianificate. Tuttavia, se l'applicazione viene ampliata, lo stesso processo pianificato può essere eseguito più di una volta per ogni periodo pianificato. Questa situazione può provocare conseguenze indesiderate.

Per eseguire i processi pianificati nel cluster del servizio Azure Kubernetes, definire i processi Cron Kubernetes come necessario. Per altre informazioni, vedere Esecuzione di attività automatiche con un processo Cron.

Determinare se viene usato Lo strumento di scripting WebLogic

Se attualmente si usa WebLogic Scripting Tool (WLST) per eseguire la distribuzione, è necessario valutare le operazioni eseguite. Se WLST modifica i parametri (runtime) dell'applicazione come parte della distribuzione, assicurarsi che tali parametri siano conformi a una delle opzioni seguenti:

  • I parametri vengono esternizzati come impostazioni dell'app.
  • I parametri sono incorporati nell'applicazione.
  • I parametri usano l'interfaccia della riga di comando di JBoss durante la distribuzione.

Se WLST esegue più di quanto indicato in precedenza, durante la migrazione è necessario eseguire alcune operazioni aggiuntive.

Determinare se l'applicazione usa API specifiche di WebLogic

Se l'applicazione usa API specifiche di WebLogic, sarà necessario effettuarne il refactoring per rimuovere tali dipendenze. Se, ad esempio, è stata usata una classe menzionata nelle informazioni di riferimento sulle API Java per Oracle WebLogic Server, è stata usata un'API specifica di WebLogic nell'applicazione. È necessario effettuare il refactoring per rimuovere il riferimento.

Determinare se l'applicazione usa Entity Beans o CMP Beans in formato EJB 2.x

Se l'applicazione usa Entity Beans o CMP Beans in formato EJB 2.x, è necessario effettuare il refactoring dell'applicazione per rimuovere tali dipendenze.

Determinare è in uso la funzionalità Java EE Application Client

Se le applicazioni client si connettono all'applicazione (server) tramite la funzionalità Java EE Application Client, sarà necessario effettuare il refactoring sia delle applicazioni client che dell'applicazione (server) per l'uso delle API HTTP.

Determinare se è stato usato un piano di distribuzione

Se l'app è stata distribuita usando un piano di distribuzione, valutare le operazioni del piano di distribuzione. Se il piano prevede una distribuzione diretta, sarà possibile distribuire l'applicazione Web senza modifiche. Se il piano di distribuzione è più elaborato, determinare se è possibile usare l'interfaccia della riga di comando di JBoss per configurare correttamente l'applicazione come parte della distribuzione. Se non è possibile usare l'interfaccia della riga di comando di JBoss, effettuare il refactoring dell'applicazione in modo che un piano di distribuzione non sia più necessario.

Determinare se i timer EJB sono in uso

Se l'applicazione usa i timer EJB, è necessario verificare che il relativo codice possa essere attivato da ogni istanza di WildFly in modo indipendente. Questa verifica è necessaria perché, nello scenario di distribuzione del servizio Azure Kubernetes, ogni timer EJB verrà attivato nella propria istanza di WildFly.

Determinare se e come viene usato il file system

Qualsiasi utilizzo del file system nel server applicazioni richiede la riconfigurazione o, in rari casi, modifiche dell'architettura. Il file system può essere usato dai moduli condivisi WebLogic o dal codice dell'applicazione. È possibile identificare alcuni o tutti gli scenari descritti nelle sezioni seguenti.

Contenuto statico di sola lettura

Se l'applicazione attualmente distribuisce contenuto statico, è necessario modificarne la posizione. Si può scegliere di spostare il contenuto statico in Archiviazione BLOB di Azure e di aggiungere la rete di distribuzione dei contenuti di Azure per accelerare i download a livello globale. Per altre informazioni, vedere Hosting di siti Web statici in Archiviazione di Azure e Avvio rapido: Integrare un account di archiviazione di Azure con Rete CDN di Azure.

Contenuto statico pubblicato dinamicamente

Se l'applicazione consente contenuto statico caricato/prodotto dall'applicazione ma non modificabile dopo la creazione, è possibile usare Archiviazione BLOB di Azure e la rete di distribuzione dei contenuti di Azure, come descritto sopra, con una funzione di Azure per gestire i caricamenti e l'aggiornamento della rete CDN. Nell'articolo Caricamento e precaricamento nella rete CDN di contenuto statico con Funzioni di Azure è riportata un'implementazione di esempio che è possibile usare.

Contenuto dinamico o interno

Per i file scritti e letti di frequente dall'applicazione, ad esempio i file di dati temporanei, o i file statici visibili solo all'applicazione, è possibile montare le condivisioni di archiviazione di Azure come volumi persistenti. Per altre informazioni, vedere Creare e usare un volume con File di Azure in servizio Azure Kubernetes (servizio Azure Kubernetes).

Determinare se vengono usati i connettori JCA

Se l'applicazione usa connettori JCA, è necessario verificare che possano essere usati in WildFly. Se l'implementazione di JCA è vincolata a WebLogic, sarà necessario effettuare il refactoring dell'applicazione per rimuovere tale dipendenza. Se il connettore può essere usato, sarà necessario aggiungere i file JAR al classpath del server e inserire i file di configurazione necessari nella posizione corretta nelle directory del server WildFly per renderlo disponibile.

Determinare se l'applicazione usa un adattatore di risorse

Se l'applicazione richiede un adattatore di risorse, è necessario che sia compatibile con WildFly. Determinare se l'adattatore di risorse funziona in un'istanza autonoma di WildFly distribuendolo nel server e configurandolo correttamente. Se l'adattatore di risorse funziona correttamente, sarà necessario aggiungere i file JAR al classpath del server dell'immagine Docker e inserire i file di configurazione necessari nella posizione corretta nelle directory del server WildFly per renderlo disponibile.

Determinare se JAAS è in uso

Se l'applicazione usa JAAS, sarà necessario acquisire la relativa configurazione. Se usa un database, è possibile convertirlo in un dominio JAAS in WildFly. Se si tratta di un'implementazione personalizzata, sarà necessario verificare che può essere usata in WildFly.

Determinare se viene usato il clustering WebLogic

Molto probabilmente, l'applicazione viene distribuita in più server WebLogic per ottenere disponibilità elevata. servizio Azure Kubernetes è in grado di ridimensionare, ma se è stata usata l'API Cluster WebLogic, è necessario effettuare il refactoring del codice per eliminare l'uso di tale API.

Eseguire i test sul posto

Prima di creare immagini di contenitori, eseguire la migrazione dell'applicazione alle versioni di JDK e WildFly che si intende usare nel servizio Azure Kubernetes. Testare accuratamente l'applicazione per garantirne la compatibilità e le prestazioni.

Migrazione

Effettuare il provisioning di Registro Azure Container e del servizio Azure Kubernetes

Usare i comandi seguenti per creare un registro contenitori e un cluster di Azure Kubernetes con un'entità servizio che ha il ruolo Lettore nel registro. Assicurarsi di scegliere il modello di rete appropriato per i requisiti di rete del cluster.

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

Creare un'immagine Docker per WildFly

Per creare un Dockerfile, è necessario soddisfare i prerequisiti seguenti:

  • Una versione supportata di JDK.
  • Un'installazione di WildFly.
  • Le opzioni di runtime della JVM.
  • Un modo per passare le variabili di ambiente (se applicabile).

È quindi possibile eseguire i passaggi descritti nelle sezioni seguenti, ove applicabile. È possibile usare il repository di avvio rapido di contenitori WildFly come punto di partenza per il Dockerfile e l'applicazione Web.

Configurare KeyVault FlexVolume

Creare un'istanza di Azure KeyVault e popolarla con i segreti necessari. Per altre informazioni, vedere Avvio rapido: Impostare e recuperare un segreto da Azure Key Vault usando l'interfaccia della riga di comando di Azure. Configurare quindi KeyVault FlexVolume per rendere tali segreti accessibili ai pod.

Sarà anche necessario aggiornare lo script di avvio usato per eseguire il bootstrap di WildFly. Questo script deve importare i certificati nell'archivio chiavi usato da WildFly prima di avviare il server.

Configurare le origini dati

Per configurare WildFly per l'accesso a un'origine dati, è necessario aggiungere il file JAR del driver JDBC all'immagine Docker e quindi eseguire i comandi dell'interfaccia della riga di comando di JBoss appropriati. Questi comandi devono configurare l'origine dati durante la creazione dell'immagine Docker.

La procedura seguente fornisce le istruzioni per PostgreSQL, MySQL e SQL Server.

  1. Scaricare il driver JDBC per PostgreSQL, MySQL o SQL Server.

    Decomprimere l'archivio scaricato per ottenere il file con estensione jar del driver.

  2. Creare un file con un nome come module.xml e aggiungere il markup seguente. Sostituire il segnaposto <module name> (incluse le parentesi angolari) con org.postgres per PostgreSQL, com.mysql per MySQL o com.microsoft per SQL Server. Sostituire <JDBC .jar file path> con il nome del file con estensione jar del passaggio precedente, incluso il percorso completo della posizione in cui si vuole inserire il file nell'immagine Docker, ad esempio in /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. Creare un file con un nome come datasource-commands.cli e aggiungere il codice seguente. Sostituire <JDBC .jar file path> con il valore usato nel passaggio precedente. Sostituire <module file path> con il nome file e il percorso del passaggio precedente, ad esempio /opt/database/module.xml.

    Nota

    Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Il flusso di autenticazione descritto in questa procedura, ad esempio per database, cache, messaggistica o servizi di intelligenza artificiale, richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi non presenti in altri flussi. Usare questo flusso solo quando le opzioni più sicure, ad esempio le identità gestite per le connessioni senza password o senza chiave, non sono valide. Per le operazioni del computer locale, preferire le identità utente per le connessioni senza password o senza chiave.

    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. Aggiornare la configurazione dell'origine dati JTA per l'applicazione:

    Aprire il file src/main/resources/META-INF/persistence.xml per l'app e trovare l'elemento <jta-data-source>. Sostituire il relativo contenuto come illustrato di seguito:

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

  5. Aggiungere quanto segue al Dockerfile in modo che l'origine dati venga creata quando si crea l'immagine 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. Determinare il valore di DATABASE_CONNECTION_URL da usare perché è diverso per ogni server di database ed è diverso dai valori nel portale di Azure. I formati di URL riportati di seguito sono necessari per l'uso da parte di WildFly:

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

  7. Quando si crea la distribuzione YAML in una fase successiva, sarà necessario passare le variabili di ambiente DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME e DATABASE_SERVER_ADMIN_PASSWORD con i valori appropriati.

Nota

Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Il flusso di autenticazione descritto in questa procedura, ad esempio per database, cache, messaggistica o servizi di intelligenza artificiale, richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi non presenti in altri flussi. Usare questo flusso solo quando le opzioni più sicure, ad esempio le identità gestite per le connessioni senza password o senza chiave, non sono valide. Per le operazioni del computer locale, preferire le identità utente per le connessioni senza password o senza chiave.

Per altre informazioni sulla configurazione della connettività del database con WildFly, vedere PostgreSQL, MySQL o SQL Server.

Configurare le risorse JNDI

Per impostare ogni risorsa JNDI che è necessario configurare in WildFly, si useranno in genere i passaggi seguenti:

  1. Scaricare i file JAR necessari e copiarli nell'immagine Docker.
  2. Creare un file module.xml di WildFly che fa riferimento a tali file JAR.
  3. Creare qualsiasi configurazione necessaria per la risorsa JNDI specifica.
  4. Creare uno script dell'interfaccia della riga di comando di JBoss da usare durante la compilazione Docker per registrare la risorsa JNDI.
  5. Aggiungere tutto al Dockerfile.
  6. Passare le variabili di ambiente appropriate nella distribuzione YAML.

L'esempio seguente illustra i passaggi necessari per creare la risorsa JNDI per la connettività JMS al bus di servizio di Azure.

  1. Scaricare il provider JMS di Apache Qpid

    Decomprimere l'archivio scaricato per ottenere il file con estensione jar.

  2. Creare un file con un nome come module.xml e aggiungere il markup seguente in /opt/servicebus. Verificare che i numeri di versione dei file JAR siano allineati ai nomi dei file JAR del passaggio precedente.

    <?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. Crea un file jndi.properties in /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. Creare un file con un nome come servicebus-commands.cli e aggiungere il codice seguente.

    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. Aggiungere quanto segue a Dockerfile in modo che la risorsa JNDI venga creata quando si crea l'immagine 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. Quando si crea la distribuzione YAML in una fase successiva, sarà necessario passare le variabili di ambiente MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC e SB_TOPIC con i valori appropriati.

Verificare la configurazione di WildFly

Leggere la guida dell'amministratore di WildFly per informazioni su eventuali passaggi di premigrazione necessari non illustrati nelle istruzioni precedenti.

Creare l'immagine Docker ed eseguirne il push in Registro Azure Container

Dopo aver creato il Dockerfile, è necessario creare l'immagine Docker e pubblicarla nel registro contenitori di Azure.

Se è stato usato il repository GitHub di avvio rapido dei contenitori WildFly, il processo di creazione dell'immagine e push nel registro contenitori di Azure equivale a richiamare i tre comandi seguenti.

In questi esempi la variabile di ambiente MY_ACR include il nome del registro contenitori di Azure e la variabile MY_APP_NAME il nome dell'applicazione Web che si vuole usare al suo interno.

Compilare il file WAR:

mvn package

Accedere al registro contenitori di Azure:

az acr login --name ${MY_ACR}

Creare l'immagine ed eseguirne il push:

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

In alternativa, è possibile usare l'interfaccia della riga di comando di Docker per creare e testare l'immagine in locale, come illustrato nei comandi seguenti. Questo approccio può semplificare il test e il perfezionamento dell'immagine prima della distribuzione iniziale in Registro Azure Container. Tuttavia, è necessario installare l'interfaccia della riga di comando di Docker e assicurarsi che il daemon Docker sia in esecuzione.

Creare l'immagine:

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

Eseguire l'immagine in locale:

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

È ora possibile accedere all'applicazione all'indirizzo http://localhost:8080.

Accedere al registro contenitori di Azure:

az acr login --name ${MY_ACR}

Eseguire il push delle immagini nel registro contenitori di Azure:

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

Per informazioni più dettagliate sulla creazione e l'archiviazione di immagini di contenitore in Azure, vedere il modulo Learn Compilare e archiviare immagini del contenitore con Registro Azure Container.

Provisioning di un indirizzo IP pubblico

Se l'applicazione deve essere accessibile dall'esterno delle reti virtuali o interne, sarà necessario un indirizzo IP statico pubblico. È necessario effettuare il provisioning di questo indirizzo IP all'interno del gruppo di risorse del nodo del cluster, come illustrato nell'esempio seguente:

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

Distribuire nel servizio Azure Kubernetes

Creare e applicare i file YAML di Kubernetes. Per altre informazioni, vedere Avvio rapido: Distribuire un cluster servizio Azure Kubernetes (AKS) usando l'interfaccia della riga di comando di Azure. Se si crea un servizio di bilanciamento del carico esterno (per l'applicazione o per un controller in ingresso), assicurarsi di fornire l'indirizzo IP di cui è stato effettuato il provisioning nella sezione precedente come LoadBalancerIP.

Includere i parametri esternalizzati come variabili di ambiente. Per altre informazioni, vedere Definire le variabili di ambiente per un contenitore. Non includere segreti, ad esempio password, chiavi API e stringhe di connessione JDBC. Questi verranno illustrati nelle sezioni seguenti.

Assicurarsi di includere le impostazioni della memoria e della CPU durante la creazione della distribuzione YAML, in modo che i contenitori siano dimensionati correttamente.

Configurare la risorsa di archiviazione persistente

Se l'applicazione richiede una risorsa di archiviazione non volatile, configurare uno o più volumi persistenti.

Eseguire la migrazione dei processi pianificati

Per eseguire i processi pianificati nel cluster del servizio Azure Kubernetes, definire i processi Cron Kubernetes come necessario. Per altre informazioni, vedere Esecuzione di attività automatiche con un processo Cron.

Post-migrazione

Ora che è stata eseguita la migrazione dell'applicazione al servizio Azure Kubernetes, è necessario verificare che funzioni come previsto. A questo scopo, vedere i consigli seguenti per rendere l'applicazione più nativa del cloud.

Consigli