Condividi tramite

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

  • Articolo

Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione WebSphere 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.

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

Controllare tutte le proprietà e i file di configurazione nel server di produzione o nei server per eventuali segreti e password. Assicurarsi di controllare ibm-web-bnd.xml nei WAR. I file di configurazione contenenti password o credenziali possono trovarsi anche all'interno dell'applicazione. Questi file possono includere, per le applicazioni Spring Boot, i file application.properties o application.yml .

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

Inventario delle risorse JNDI

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

All'interno dell'applicazione

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

Determinare se vengono usati i database

Se l'applicazione usa qualsiasi database, è necessario acquisire le informazioni seguenti:

  • Nome dell'origine dati.
  • Configurazione del pool di connessioni.
  • Percorso del file JAR del driver JDBC.

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 condivisi Di WebSphere o dal codice dell'applicazione. È possibile identificare alcuni o tutti gli scenari 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 file di dati temporanei) o file statici visibili solo all'applicazione, è possibile montare Archiviazione di Azure nel file system servizio app. Per altre informazioni, vedere Montare Archiviazione di Azure come condivisione locale in servizio app.

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 è 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 WebSphere

Se l'applicazione usa API specifiche di WebSphere, è necessario effettuare il refactoring dell'applicazione per NON usarle. 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 Entity Beans o CMP Beans in formato EJB 2.x, è necessario effettuare il refactoring dell'applicazione per rimuovere tali dipendenze.

Determinare se viene usata la funzionalità client dell'applicazione JavaEE

Se si dispone di applicazioni client che si connettono all'applicazione (server) usando la funzionalità Client applicazione JavaEE, sarà necessario effettuare il refactoring delle applicazioni client e dell'applicazione (server) per usare le 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 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.

Determinare se vengono usati i connettori JCA

Se l'applicazione usa connettori JCA, è necessario verificare che il connettore JCA possa essere usato in JBoss EAP. Se l'implementazione JCA è associata a WebSphere, è necessario effettuare il refactoring dell'applicazione rimuovendo la dipendenza dal connettore JCA. Se è possibile usare il connettore JCA, sarà necessario aggiungere i file JAR al classpath del server. Sarà anche necessario inserire i file di configurazione necessari nel percorso corretto nelle directory del server JBoss EAP per renderli disponibili.

Determinare se JAAS è in uso

Se l'applicazione usa JAAS, è necessario acquisire la modalità di configurazione di 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 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 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 viene inserita in un pacchetto come file EAR, assicurarsi di esaminare i file application.xml e ibm-application-bnd.xml e acquisire le 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.

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:

Dopo aver creato l'app Web, usare uno dei meccanismi di distribuzione disponibili per distribuire l'applicazione. Per altre informazioni, vedere Distribuire 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 Distribuire e configurare un'app Tomcat, JBoss o Java SE in app Azure Service.

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 Usare i riferimenti a Key Vault come impostazioni dell'app in app Azure Servizio e Funzioni di 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 in Configurare le origini dati per un'app Tomcat, JBoss o Java SE in app Azure Service.

Eseguire la migrazione di eventuali dipendenze classpath a livello di server aggiuntive. Per altre informazioni, vedere Configurare le origini dati per un'app Tomcat, JBoss o Java SE in app Azure Service.

Eseguire la migrazione di eventuali risorse JDNI a livello di server condiviso aggiuntive. Per altre informazioni, vedere Configurare le origini dati per un'app Tomcat, JBoss o Java SE in app Azure Service.

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. Una volta completata questa operazione, sono disponibili alcune raccomandazioni per rendere l'applicazione maggiormente nativa del cloud.

Consigli