Eseguire la migrazione di applicazioni JBoss EAP a WildFly in servizio Azure Kubernetes (AKS)

  • Articolo

Questa guida descrive gli aspetti da considerare per la migrazione di un'applicazione JBoss EAP esistente da eseguire in WildFly in un contenitore del servizio Azure Kubernetes.

Pre-migrazione

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

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

Controllare tutte le proprietà e i file di configurazione nei server di produzione per verificare la presenza di segreti e password. Assicurarsi di controllare jboss-web.xml nei WAR. I file di configurazione contenenti password o credenziali possono trovarsi anche all'interno dell'applicazione.

È consigliabile archiviare tali segreti in Azure KeyVault. 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>

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.

Inventario delle risorse JNDI

Creare un inventario di tutte le risorse JNDI. Alcune, ad esempio i broker di messaggi JMS, possono richiedere la migrazione o la riconfigurazione.

Determinare se viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica delle sessioni, sarà necessario cambiarla per rimuovere questa dipendenza.

All'interno dell'applicazione

Esaminare i file WEB-INF/jboss-web.xml e/o WEB-INF/web.xml.

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, vedere la sezione relativa alle origini dati di JBoss EAP nella documentazione di JBoss EAP.

Determinare se e come viene usato il file system

Qualsiasi utilizzo del file system nel server applicazioni richiede modifiche della configurazione o, in casi rari, dell'architettura. Il file system può essere usato da moduli JBoss EAP 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 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 è 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 l'applicazione usa API specifiche di JBoss EAP

Se l'applicazione usa API specifiche di JBoss EAP, sarà necessario effettuarne il refactoring per rimuovere tali dipendenze.

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 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 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 vengono usati i connettori JCA

Se l'applicazione usa connettori JCA, è necessario verificare che sia possibile usare il connettore JCA in WildFly. Se l'implementazione di JCA è vincolata a JBoss EAP, sarà necessario effettuare il refactoring dell'applicazione per rimuovere tale dipendenza. Se è possibile usare il connettore JCA, affinché sia disponibile sarà necessario aggiungere i file JAR al parametro classpath del server e includere i file di configurazione necessari nel percorso corretto nelle directory del server WildFly.

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 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 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 il file application.xml e acquisire la relativa configurazione.

Nota

Se si vuole essere in grado di ridimensionare ognuna delle applicazioni Web in modo indipendente per un uso migliore delle risorse di servizio Azure Kubernetes (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.

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.

  1. Configurare KeyVault FlexVolume
  2. Configurare le origini dati
  3. Configurare le risorse JNDI
  4. Verificare la configurazione di WildFly

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.

    PostgreSQL

    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

    MySQL

    batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --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=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

    SQL Server

    batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
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:

    PostgreSQL

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

    MySQL

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

    SQL Server

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

    PostgreSQL

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

    MySQL

    jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

    SQL Server

    jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

  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.

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. Al termine, sono disponibili alcune raccomandazioni per rendere l'applicazione maggiormente nativa del cloud.

Consigli