Condividi tramite

Eseguire la migrazione di applicazioni JBoss EAP a JBoss EAP in Servizio app di Azure

  • Articolo

Questa guida descrive cosa è necessario tenere presente quando si vuole eseguire la migrazione di un'applicazione JBoss EAP esistente per l'esecuzione in JBoss EAP in un'istanza del servizio app Azure.

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.

È possibile usare i segreti di Key Vault nell'istanza di servizio app con i riferimenti a Key Vault. I riferimenti a Key Vault consentono di usare i segreti nell'applicazione mantenendoli protetti e crittografati inattivi. Per altre informazioni, vedere Usare i riferimenti a Key Vault per Servizio app 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 nelle macchine virtuali di Azure richiede una versione supportata di Java. Per indicazioni su quale versione di JDK 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

Le risorse esterne, ad esempio le origini dati, i broker di messaggi JMS e altre, vengono inserite tramite JNDI (Java Naming and Directory Interface). Alcune di queste risorse 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>.

Datasources

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 JDBC?

Per altre informazioni, vedere la sezione relativa alle origini dati di JBoss 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 viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica delle sessioni, sarà necessario cambiarla per rimuovere questa dipendenza. servizio app non consente alle istanze di comunicare direttamente tra loro.

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 dai 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 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 altre informazioni, vedere Funzionalità del sistema operativo in app Azure Servizio e Informazioni sul file system del servizio app Azure.

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 cron Unix, non devono essere usati con app Azure Servizio. app Azure Servizio 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.

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, 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 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 l'archiviazione con ridondanza geografica funziona correttamente in un'istanza autonoma di JBoss EAP distribuendola nel server e configurandola correttamente. Se l'archiviazione con ridondanza geografica funziona correttamente, sarà necessario aggiungere i file JAR al classpath del server del servizio app e inserire i file di configurazione necessari nel percorso corretto nelle directory del server JBoss EAP 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 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 immagini del contenitore, eseguire la migrazione dell'applicazione alle versioni JDK e JBoss EAP che si intende usare in servizio app. Testare accuratamente l'applicazione per garantirne la compatibilità e le prestazioni.

JBoss EAP sulle note sulle funzionalità servizio app

Quando si usa JBoss EAP in servizio app, assicurarsi di prendere in considerazione le note seguenti.

  • Console di gestione JBoss EAP: la console Web JBoss non è esposta in servizio app. 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 Transactions è 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. servizio app elimina la necessità della modalità di 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: a partire dal 28 settembre 2023, la distribuzione in cluster di JBoss EAP è disponibile a livello generale. Questo supporto significa che non è più necessario rimuovere le funzionalità seguenti dalle applicazioni prima di poterle distribuire in servizio app:

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

    Per altre informazioni, vedere l'annuncio sulla versione e la sezione Clustering di Configurare un'app Java per app Azure Servizio.

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 altre informazioni, vedere Panoramica di Migration Toolkit for Applications.

Il contenuto di questa guida consente di gestire gli altri componenti del percorso di migrazione, ad esempio la scelta del tipo di piano 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 servizio app, viene creato un piano di app Web Linux usando il runtime JBoss EAP. È possibile creare siti JBoss EAP solo nei livelli PremiumV3 e IsolatedV2 servizio app Plan.

Assicurarsi che le variabili di ambiente specificate abbiano valori appropriati.

Nota

PremiumV3 e IsolatedV2 sono entrambi idonei per i prezzi dell'istanza riservata, riducendo i costi. Per altre informazioni sui piani di servizio app e sui prezzi delle istanze riservate, vedere prezzi servizio app.

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 P1V2
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|7-java8"
    #  Or use "JBOSSEAP|7-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 EAP sono necessari tre passaggi principali: caricamento del driver JDBC, 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 seguente è 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 seguente 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 seguente illustra come chiamare il file jboss-cli-commands.cli . Successivamente si configurerà 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, che causerà l'esecuzione dello script di configurazione.

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

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 a app Azure Servizio, è necessario verificare che funzioni come previsto. Al termine, sono disponibili alcune raccomandazioni per rendere l'applicazione maggiormente nativa del cloud.

Consigli