Eseguire la migrazione di applicazioni WebLogic Server a JBoss EAP nel servizio app Azure

Questa guida descrive gli elementi da tenere presenti quando si vuole eseguire la migrazione di un'applicazione WebLogic Server esistente da eseguire in app Azure Service usando JBoss EAP.

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 uno di questi requisiti di pre-migrazione, vedere la guida alla migrazione complementare per eseguire la migrazione delle applicazioni a Macchine virtuali invece: Eseguire la migrazione di applicazioni WebLogic Server ad Azure Macchine virtuali

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 del piano di servizio app.

L'elenco dei livelli di piano di servizio app disponibili mostra le informazioni sulla memoria, sui core CPU, sull'archiviazione e sui prezzi. Si noti che JBoss EAP in servizio app è disponibile solo nei livelli Premium V3 e Isolated V2 servizio app Plan.

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.

Esaminare la configurazione del dominio

L'unità di configurazione principale in WebLogic Server è il dominio. Di conseguenza, il file config.xml contiene una grande quantità di configurazioni che è necessario considerare attentamente per la migrazione. Il file include riferimenti a file XML aggiuntivi archiviati in sottodirectory. Oracle consiglia di usare normalmente la console di amministrazione per configurare gli oggetti e i servizi gestibili di WebLogic Server e di consentire a WebLogic Server di gestire il file config.xml. Per altre informazioni, vedere File di configurazione del dominio.

All'interno dell'applicazione

Esaminare il file WEB-INF/weblogic.xml e/o il file WEB-INF/web.xml.

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.

Per tutte queste opzioni, è consigliabile verificare come viene eseguita la replica dello stato delle sessioni HTTP da WebLogic. Per altre informazioni, vedere Replica dello stato delle sessioni HTTP nella documentazione di Oracle.

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.

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

JBoss EAP nel servizio app Azure supporta Java 8 e 11. Pertanto, sarà necessario verificare che l'applicazione sia in grado di funzionare correttamente usando tale versione supportata. Questa convalida è particolarmente importante se il server corrente è usa una versione di JDK non supportata, 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

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.

Per eseguire i processi pianificati in Azure, provare a usare Funzioni di Azure con un trigger timer. Per altre informazioni, vedere Trigger timer per Funzioni di Azure. Non è necessario eseguire la migrazione del codice del processo stesso in una funzione. La funzione può semplicemente richiamare un URL nell'applicazione per attivare il processo.

Nota

Per evitare un uso improprio, potrebbe essere necessario assicurarsi che l'endpoint di chiamata del processo richieda le credenziali. In questo caso, la funzione di trigger dovrà fornire le credenziali.

Determinare se viene usato lo strumento WLST (WebLogic Scripting Tool)

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

• Sono esternalizzati come impostazioni dell'app.
• Sono incorporati nell'applicazione.
• Usano l'interfaccia della riga di comando di JBoss durante la distribuzione.

Se WLST esegue più di quanto indicato in precedenza, durante la migrazione saranno disponibili alcune operazioni aggiuntive.

Determinare se l'applicazione usa API specifiche di WebLogic

Se l'applicazione usa API specifiche di WebLogic, sarà necessario effettuare il refactoring dell'applicazione per NON usarle. 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. Red Hat Migration Toolkit per le app può facilitare la rimozione e il refactoring di queste dipendenze.

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

Se l'applicazione usa fagioli CMP di tipo Entity Beans o EJB 2.x, sarà necessario effettuare il refactoring dell'applicazione per NON usarli.

Determinare se viene usata la funzionalità Java EE Application Client

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

Determinare se è stato usato un piano di distribuzione

Se per eseguire la distribuzione è stato usato un piano di distribuzione, è necessario valutare le operazioni eseguite dal piano di distribuzione. Se il piano prevede una distribuzione diretta, sarà possibile distribuire l'applicazione Web senza modifiche. Se invece il piano è più elaborato, sarà necessario 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, sarà necessario effettuare il refactoring dell'applicazione in modo che non sia più necessario un piano di distribuzione.

Determinare se i timer EJB sono in uso

Se l'applicazione usa timer EJB, è necessario verificare che il codice timer EJB possa essere attivato da ogni istanza JBoss EAP in modo indipendente. Questa convalida è necessaria perché quando il servizio app viene ridimensionato orizzontalmente, ogni timer EJB verrà attivato nella propria istanza di JBoss EAP.

Verificare 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 condivisi WebLogic o dal codice dell'applicazione. È possibile identificare alcuni o tutti gli scenari seguenti.

Contenuto statico di sola lettura

Se l'applicazione attualmente serve contenuto statico, sarà necessario un percorso alternativo per il contenuto statico. È possibile prendere in considerazione lo spostamento di contenuto statico in Archiviazione BLOB di Azure e l'aggiunta di Rete CDN di Azure per download veloci a livello globale.

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. È stata fornita un'implementazione di esempio per l'uso.

Contenuto dinamico o interno

Per i file scritti e letti di frequente dall'applicazione (ad esempio file di dati temporanei) o file statici visibili solo all'applicazione, Archiviazione di Azure possono essere montati nel file system servizio app.

Determinare se vengono usati i connettori JCA

Se l'applicazione usa connettori JCA, sarà necessario convalidare che il connettore JCA possa essere usato in JBoss EAP. Se l'implementazione JCA è associata a WebLogic, è necessario effettuare il refactoring dell'applicazione per NON usare il connettore JCA. Se 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 JBoss EAP affinché sia disponibile.

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, è necessario aggiungere i file JAR al classpath server dell'istanza di servizio app e inserire i file di configurazione necessari nel percorso corretto nelle directory del server JBoss EAP affinché siano disponibili.

Determinare se viene usato JAAS

Se l'applicazione usa JAAS, sarà necessario acquisire il modo in cui è configurato JAAS. 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 viene usato il clustering WebLogic

Molto probabilmente, l'applicazione viene distribuita in più server WebLogic per ottenere disponibilità elevata. app Azure Servizio è 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.

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 consigli per la migrazione delle applicazioni Jakarta EE a JBoss EAP da altri server app, ad esempio la rimozione delle dipendenze dalle API proprietarie. L'estensione fornirà anche raccomandazioni se si esegue 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 di un piano di servizio app

Nell'elenco dei piani di servizio disponibili selezionare il piano le cui specifiche soddisfano o superano le specifiche dell'hardware di produzione corrente.

Nota

Se si prevede di eseguire distribuzioni staging/canary o di usare gli slot di distribuzione, il piano di servizio app deve includere tale capacità aggiuntiva. È consigliabile usare piani Premium o superiori per le applicazioni Java.

Creare il piano di servizio app.

Creare e distribuire app Web

È necessario creare un'app Web nel piano di servizio app per ogni file WAR distribuito nel server JBoss EAP.

Nota

Sebbene sia possibile distribuire più file WAR in un'unica app Web, questo approccio non è consigliabile. La distribuzione di più file WAR in un'unica app Web impedisce il ridimensionamento di ogni applicazione in base alle proprie esigenze di utilizzo, aumentando anche la complessità delle pipeline di distribuzione successive. Se più applicazioni devono essere disponibili in un singolo URL, provare a usare una soluzione di routing come il gateway applicazione di Azure.

Applicazioni Maven

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 la sezione Configurare il plug-in Maven di Avvio rapido: Creare un'app Java nel servizio app Azure.

Applicazioni non Maven

Se non è possibile usare il plug-in Maven, sarà necessario effettuare il provisioning dell'app Web tramite altri meccanismi, ad esempio:

• Azure portal
• Interfaccia della riga di comando di Azure
• Azure PowerShell

Dopo aver creato l'app Web, usare uno dei meccanismi di distribuzione disponibili per distribuire l'applicazione. Per altre informazioni, vedereDistribuire file in servizio app.

Eseguire la migrazione delle opzioni di runtime JVM

Se l'applicazione richiede opzioni di runtime specifiche, usare il meccanismo più appropriato per specificarle. Per altre informazioni, vedere la sezione Impostare le opzioni di runtime Java di Configurare un'app Java per app Azure Servizio.

Eseguire la migrazione di parametri esterni

Se è necessario usare parametri esterni, è necessario impostarli come impostazioni dell'app. Per altre informazioni, vedere Configurare le impostazioni delle app.

Eseguire la migrazione degli script di avvio

Se l'applicazione originale usa uno script di avvio personalizzato, è necessario eseguirne la migrazione a uno script Bash. Per altre informazioni, vedere Personalizzare la configurazione del server applicazioni.

Popolare i segreti

Usare le impostazioni dell'applicazione per archiviare i segreti specifici dell'applicazione. Se si intende usare lo stesso segreto o lo stesso segreto tra più applicazioni o se sono necessari criteri di accesso e funzionalità di controllo con granularità fine, usare invece i riferimenti ad Azure Key Vault. Per altre informazioni, vedere la sezione Use KeyVault References (Usare riferimenti all'insieme di credenziali delle chiavi) di Configurare un'app Java per il servizio app Azure.

Configurare un dominio personalizzato e SSL

Se l'applicazione Web sarà visibile in un dominio personalizzato, sarà necessario eseguirne il mapping a tale dominio. Per altre informazioni, vedere Esercitazione: Eseguire il mapping di un nome DNS personalizzato esistente a app Azure Servizio.

Sarà quindi necessario associare il certificato TLS/SSL per tale dominio all'app Web servizio app. Per altre informazioni, vedere Proteggere un nome DNS personalizzato con un'associazione TLS/SSL nel servizio app di Azure.

Eseguire la migrazione di origini dati, librerie e risorse JNDI

Per eseguire la migrazione delle origini dati, seguire la procedura descritta nella sezione Configurare le origini dati di Configurare un'app Java per app Azure Servizio.

Eseguire la migrazione di eventuali dipendenze di classpath a livello di server aggiuntive seguendo le istruzioni nella sezione JBoss EAP di Configurare un'app Java per app Azure Servizio.

Eseguire la migrazione di eventuali risorse JDNI a livello di server condiviso aggiuntive. Per altre informazioni, vedere la sezione JBoss EAP di Configurare un'app Java per app Azure Service.

Eseguire la migrazione di connettori JCA e moduli JAAS

Eseguire la migrazione di tutti i connettori JCA e i moduli JAAS seguendo le istruzioni riportate in Installare moduli e dipendenze.

Nota

Se si segue l'architettura consigliata di una war per applicazione, è consigliabile eseguire la migrazione di librerie classpath a livello di server e risorse JNDI nell'applicazione. In questo modo si semplifica notevolmente la governance dei componenti e la gestione delle modifiche. Se si vuole distribuire più di una war per applicazione, è consigliabile esaminare una delle guide complementari indicate all'inizio di questa guida.

Eseguire la migrazione dei processi pianificati

È consigliabile spostare almeno i processi pianificati in una macchina virtuale di Azure in modo che non facciano più parte dell'applicazione. In alternativa, è possibile scegliere di modernizzarli in Java basato su eventi usando servizi di Azure, ad esempio Funzioni di Azure, database SQL e Hub eventi.

Riavvio e smoke test

Infine, sarà necessario riavviare l'app Web per applicare tutte le modifiche alla configurazione. Al termine del riavvio, verificare che l'applicazione venga eseguita correttamente.

Post-migrazione

Ora che è stata eseguita la migrazione dell'applicazione a app Azure Servizio, è necessario verificare che funzioni come previsto. Dopo aver completato questa operazione, sono disponibili alcune raccomandazioni che consentono di rendere l'applicazione più 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 Montare Archiviazione di Azure come condivisione locale in un contenitore personalizzato in servizio app.

• Se si dispone di una configurazione nella directory /home che contiene stringa di connessione, chiavi SSL e altre informazioni segrete, è consigliabile usare una combinazione di Azure Key Vault e l'inserimento di parametri con le impostazioni dell'applicazione, dove possibile. Per altre informazioni, vedere Usare i riferimenti a Key Vault per servizio app e Funzioni di Azure e Configurare un'app servizio app.

• 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 Compilazione e distribuzione nell'app Web Java. Se si usano gli slot di distribuzione, è possibile automatizzare la distribuzione in uno slot e lo scambio di slot successivo. Per altre informazioni, vedere la sezione Esempio: Distribuire in uno slot di Deploy to servizio app using Azure Pipelines (Distribuire in uno slot in servizio app tramite Azure Pipelines).

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