Eseguire la migrazione di applicazioni JBoss EAP a JBoss EAP in Servizio app di Azure
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.
Ottenere il driver JDBC del database.
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>
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.
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
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
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/.
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.
Riavviare l'app Web, che causerà l'esecuzione dello script di configurazione.
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
Se si è scelto di usare la directory /home per l'archiviazione file, è consigliabile sostituirla con Archiviazione di Azure. Per altre informazioni, vedere Access Archiviazione di Azure come condivisione di rete da un contenitore in servizio app.
Se si dispone di una configurazione nella directory /home contenente stringa di connessione, chiavi SSL e altre informazioni segrete, è consigliabile usare Azure Key Vault e/o l'inserimento di parametri con le impostazioni dell'applicazione laddove possibile. Per altre informazioni, vedere Usare i riferimenti a Key Vault per servizio app e Funzioni di Azure e Configurare un'app servizio app nel portale di Azure.
Prendere in considerazione l'uso degli slot di distribuzione per distribuzioni affidabili senza tempi di inattività. Per altre informazioni, vedere Configurare gli ambienti di gestione temporanea nel Servizio app di Azure.
Progettare e implementare una strategia DevOps. Per mantenere l'affidabilità aumentando al tempo stesso la velocità di sviluppo, è consigliabile automatizzare le distribuzioni e i test con Azure Pipelines. Per altre informazioni, vedere Creare e distribuire in un'app Web Java. Quando si usano gli slot di distribuzione, è possibile automatizzare la distribuzione in uno slot seguito dallo scambio di slot. Per altre informazioni, vedere la sezione Distribuire in uno slot di Distribuire un'app Web di Azure (Linux).
Progettare e implementare una strategia di continuità aziendale e ripristino di emergenza. Per le applicazioni cruciali, considerare un'architettura di distribuzione in più aree. Per altre informazioni, vedere Applicazione Web multi-area a disponibilità elevata.