Condividi tramite

Eseguire la migrazione delle applicazioni JBoss EAP su JBoss EAP su Azure App Service

Questa guida descrive cosa occorre tenere presente quando si vuole eseguire la migrazione di un'applicazione Red Hat JBoss Enterprise Application Platform (EAP) esistente da eseguire in JBoss EAP in un'istanza del servizio app di Azure.

Premigrazione

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.

Se si dispone di dati di test di carico, creare uno snapshot dei risultati dei test correnti in modo da poter eseguire di nuovo i test dopo la migrazione per assicurarsi di soddisfare gli obiettivi di prestazioni previsti.

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

Inventaria tutti i segreti

Controllare tutte le proprietà e i file di configurazione nei server di produzione per eventuali segreti e password. Assicurarsi di controllare jboss-web.xml nei file di archivio applicazioni Web (WAR). I file di configurazione che contengono password o credenziali sono disponibili anche all'interno dell'applicazione.

È consigliabile archiviare tali segreti in Azure KeyVault. Per altre informazioni, vedere Concetti di base di Azure Key Vault.

È possibile usare i segreti di Key Vault nell'istanza di App Service con i riferimenti a Key Vault. I riferimenti a Key Vault consentono di usare i segreti nell'applicazione mantenendoli protetti e crittografati quando sono inattivi. Per ulteriori informazioni, vedere Usare i riferimenti a Key Vault per App Service e Funzioni di Azure.

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

JBoss EAP nel servizio app richiede una versione supportata di Java. Per indicazioni sulla versione di Java Development Kit (JDK) da usare, vedere configurazioni supportate nella documentazione di Red Hat.

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

Inventario delle risorse esterne

Risorse esterne, ad esempio origini dati, broker di messaggi JMS (Java Message Service) e altri vengono inseriti tramite Java Naming and Directory Interface (JNDI). Alcune risorse di questo tipo possono richiedere la migrazione o la riconfigurazione.

All'interno dell'applicazione

Esaminare i file WEB-INF/jboss-web.xml e/o WEB-INF/web.xml. Cercare gli elementi <Resource> all'interno dell'elemento <Context>.

Origini dati

Le origini dati sono risorse JNDI con l'attributo type impostato su javax.sql.DataSource. Per ogni origine dati, documentare le informazioni seguenti:

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

Per ulteriori dettagli, consultare la sezione Informazioni sulle origini dati della JBoss Enterprise Application Platform (EAP) nella documentazione di JBoss EAP.

Tutte le altre risorse esterne

Non è possibile documentare tutte le possibili dipendenze esterne in questa guida. È responsabilità del team verificare che sia possibile soddisfare tutte le dipendenze esterne dell'applicazione dopo la migrazione.

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. I moduli JBoss EAP o il codice dell'applicazione possono usare il file system. È possibile identificare alcuni o tutti gli scenari descritti nelle sezioni seguenti.

Contenuto statico di sola lettura

Se l'applicazione attualmente serve contenuto statico, è necessario un percorso alternativo. È consigliabile spostare contenuto statico in Archiviazione BLOB di Azure e aggiungere Frontdoor di Azure per i download rapidi a livello globale. Per altre informazioni, vedere l'hosting di siti web statici su Azure Storage e Integrare un account di archiviazione di Azure con Azure Front Door.

Contenuto dinamico o interno

Per i file spesso scritti e letti dall'applicazione (ad esempio file di dati temporanei) o file statici visibili solo all'applicazione, è possibile usare l'archiviazione file locale associata al piano di servizio app. Per ulteriori informazioni, vedere Funzionalità del sistema operativo su Azure App Service e Comprendere il file system di Azure App Service.

Determinare se la tua applicazione si basa su processi programmati

I processi pianificati, ad esempio le attività dell'utilità di pianificazione di Quartz o i processi cron Unix, non devono essere usati con Azure App Service. Azure App Service non impedirà di distribuire dall'interno 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.

Eseguire l'inventario di tutte le attività pianificate in esecuzione nei server di produzione, all'interno o all'esterno del codice dell'applicazione.

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

Se l'applicazione usa connettori JCA (Java Connector Architecture), verificare che sia possibile usare il connettore JCA in JBoss EAP. Se è possibile usare il connettore JCA in JBoss EAP, per renderlo disponibile, è necessario aggiungere i file Java Archive (JAR) al classpath server e inserire i file di configurazione necessari nella posizione corretta nelle directory del server JBoss EAP.

Determinare se JAAS è in uso

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

Determinare se l'applicazione usa un adattatore di risorse

Se l'applicazione necessita di un adattatore di risorse (RA), deve essere compatibile con JBoss EAP. Determinare se il RA funziona correttamente in una istanza standalone di JBoss EAP implementandola nel server e configurandola correttamente. Se il RA funziona correttamente, sarà necessario aggiungere i file JAR al classpath del server del servizio applicativo e posizionare i file di configurazione necessari nella posizione corretta nelle directory del server JBoss EAP affinché sia 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 è confezionata come un 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 del servizio app, è 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 le app Web, eseguire la migrazione dell'applicazione alle versioni JDK e JBoss EAP che si intende usare nel servizio app. Testare accuratamente l'applicazione per garantirne la compatibilità e le prestazioni.

JBoss EAP nelle note sulle funzionalità di Servizio App

Quando si usa JBoss EAP nel Servizio App, assicurarsi di fare attenzione alle seguenti note.

  • Console di gestione JBoss EAP: la console Web JBoss non è esposta su App Service. Al contrario, il portale di Azure fornisce le API di gestione per l'applicazione ed è consigliabile eseguire la distribuzione usando l'interfaccia della riga di comando di Azure, il plug-in Azure Maven o altri strumenti di sviluppo di Azure. È possibile ottenere un'ulteriore configurazione delle risorse JBoss usando l'interfaccia della riga di comando di JBoss durante l'avvio dell'applicazione.

  • Transazioni: l'API Transazioni è supportata ed è disponibile il supporto per il ripristino automatico delle transazioni. Per altre informazioni, vedere Gestione delle transazioni in JBoss EAP nella documentazione di Red Hat.

  • Modalità di dominio gestito: in un ambiente di produzione multiserver, la modalità dominio gestito in JBoss EAP offre funzionalità gestite centralizzate. Tuttavia, con JBoss EAP in servizio app, la piattaforma servizio app assume la responsabilità della configurazione e della gestione delle istanze del server. Il servizio App Service elimina la necessità della modalità dominio gestito di JBoss EAP. La modalità di dominio è una scelta ottimale per le distribuzioni multiserver basate su macchine virtuali. Per altre informazioni, vedere Informazioni sui domini gestiti nella documentazione di Red Hat.

  • clustering da server a server: il servizio app supporta completamente le distribuzioni cluster JBoss EAP. Ciò significa che è possibile usare in tutta sicurezza:

    • Fagioli di sessione con stato.
    • Transazioni distribuite.
    • Funzionalità simili che richiedono la comunicazione da istanza a istanza o disponibilità elevata.

    Per altre informazioni, vedere la sezione clustering di Configurare un'app Java per il servizio app di Azure.

Migrazione

Red Hat Migration Toolkit per le app

Red Hat Migration Toolkit for Applications è un'estensione gratuita per Visual Studio Code. Questa estensione analizza il codice e la configurazione dell'applicazione per fornire suggerimenti per la migrazione al cloud dall'ambiente locale. Per ulteriori informazioni, vedere la panoramica di Migration Toolkit for Applications.

Il contenuto di questa guida illustra gli altri componenti del percorso di migrazione, ad esempio la scelta del tipo di piano di servizio app corretto, l'esternalizzazione dello stato della sessione e l'uso di Azure per gestire le istanze EAP anziché l'interfaccia di gestione di JBoss.

Effettuare il provisioning del servizio app Azure per il runtime EAP di JBoss

Usare i comandi seguenti per creare un gruppo di risorse e un piano di servizio app Azure. Dopo aver creato il piano di servizio app, viene creato un piano di app Web Linux usando il runtime di JBoss Enterprise Application Platform (EAP).

Assicurarsi che le variabili di ambiente specificate abbiano valori appropriati.

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

Compilare l'applicazione

Compilare l'applicazione usando il comando Maven seguente.

mvn clean install -DskipTests

Distribuire l'applicazione

Se l'applicazione viene compilata da un file POM Maven, usare il plug-in Webapp per Maven per creare l'app Web e distribuire l'applicazione. Per altre informazioni, vedere Avvio rapido: Creare un'app Java nel servizio app Azure.

Per automatizzare la distribuzione di applicazioni JBoss EAP, è possibile usare l'attività Azure Pipelines per l'app Web o GitHub Action per la distribuzione in App Web di Azure.

Configurare le origini dati

Durante la registrazione di un'origine dati con JBoss Enterprise Application Platform (EAP) sono necessari tre passaggi principali: caricamento del driver JDBC (Java Database Connectivity), aggiunta del driver JDBC come modulo e registrazione del modulo. Per altre informazioni, vedere Gestione delle origini dati nella documentazione di JBoss EAP. Il servizio app è un servizio di hosting senza stato, quindi i comandi di configurazione per l'aggiunta e la registrazione del modulo dell'origine dati devono essere inseriti in script e applicati all'avvio del contenitore.

Per configurare le origini dati, seguire questa procedura.

  1. Ottenere il driver JDBC del database.

  2. Creare un file di definizione del modulo XML per il driver JDBC. L'esempio illustrato è una definizione di modulo per PostgreSQL. Assicurarsi di sostituire il resource-root path valore con il percorso del driver JDBC usato.

    <?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. Inserire i comandi dell'interfaccia della riga di comando di JBoss in un file denominato jboss-cli-commands.cli. I comandi JBoss devono aggiungere il modulo e registrarlo come origine dati. L'esempio mostra i comandi dell'interfaccia della riga di comando di JBoss per PostgreSQL.

    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.

    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. Creare uno script di avvio denominato startup_script.sh che chiama i comandi dell'interfaccia della riga di comando di JBoss. L'esempio illustra come eseguire il file jboss-cli-commands.cli. Successivamente si configura il servizio app per eseguire questo script all'avvio dell'istanza.

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

  5. Usando un client FTP di propria scelta, caricare il driver JDBC, jboss-cli-commands.cli, startup_script.sh e la definizione del modulo in /site/deployments/tools/.

  6. Configurare il sito per l'esecuzione startup_script.sh all'avvio del contenitore. Nel portale di Azure passare a Configurazione > generale Impostazioni > comando di avvio. Impostare il campo del comando di avvio su /home/site/deployments/tools/startup_script.sh e quindi selezionare Salva.

  7. Riavviare l'app Web, causando l'esecuzione dello script di configurazione.

  8. Aggiornare la configurazione dell'origine dati JTA (Java Transaction API) 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>

Compilare l'applicazione

Compilare l'applicazione usando il comando Maven seguente.

mvn clean install -DskipTests

Distribuire l'applicazione

Se l'applicazione viene compilata da un file POM Maven, usare il plug-in Webapp per Maven per creare l'app Web e distribuire l'applicazione. Per altre informazioni, vedere Avvio rapido: Creare un'app Java nel servizio app Azure.

Per automatizzare la distribuzione di applicazioni JBoss EAP, è possibile usare l'attività Azure Pipelines per l'app Web o GitHub Action per la distribuzione in App Web di Azure.

Post-migrazione

Ora che è stata eseguita la migrazione dell'applicazione al servizio app di Azure, è necessario verificare che funzioni come previsto. Dopo aver eseguito questa operazione, sono disponibili alcune raccomandazioni che consentono di rendere l'applicazione più nativa del cloud.

Consigli