Eseguire la migrazione di applicazioni WebLogic Server alle macchine virtuali di Azure

  • Articolo

Questa guida descrive gli aspetti da considerare per la migrazione di un'applicazione WebLogic esistente da eseguire nelle macchine virtuali di Azure. Per una panoramica delle soluzioni WebLogic Server disponibili in Azure Marketplace, vedere Quali sono le soluzioni per l'esecuzione di Oracle WebLogic Server in Azure Macchine virtuali?

Pre-migrazione

Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.

Definire cosa si intende per "migrazione completata"

Questa guida e le offerte di Azure Marketplace corrispondenti costituiscono un punto di partenza per accelerare la migrazione dei carichi di lavoro di WebLogic Server ad Azure. È importante definire l'ambito dell'attività di migrazione. Ad esempio, si sta eseguendo un trasferimento "lift-and-shift" rigoroso dall'infrastruttura esistente alle macchine virtuali di Azure? In caso affermativo, si potrebbe essere tentati di adottare un modello di migrazione "lift-and-improve".

È preferibile attenersi il più strettamente possibile all'approccio "lift-and-shift", tenendo conto delle necessarie modifiche descritte in questa guida. Definire cosa si intende per "migrazione completata", in modo da sapere quando viene raggiunto questo traguardo. Una volta raggiunta la fase di "migrazione completata", è possibile acquisire uno snapshot delle macchine virtuali, come descritto in Creare uno snapshot. Dopo aver verificato che è possibile eseguire correttamente il ripristino dallo snapshot, è possibile eseguire i miglioramenti senza temere di perdere lo stato di avanzamento della migrazione raggiunto finora.

Assicurarsi che la destinazione sia la destinazione appropriata per il lavoro di migrazione

Il primo passaggio di una migrazione corretta di un'applicazione WLS ad Azure consiste nel selezionare la destinazione di migrazione più appropriata. WLS funziona correttamente in macchine virtuali (VM) di Azure o servizio Azure Kubernetes (servizio Azure Kubernetes). La destinazione della macchina virtuale è la scelta più semplice, perché è molto simile a una distribuzione locale. L'esperienza amministrativa e di distribuzione per le macchine virtuali è molto simile a quella in locale. Il compromesso per questa facilità è il costo economico. In generale, il costo al minuto per una soluzione basata su vm è superiore rispetto al servizio Azure Kubernetes. Sebbene una soluzione basata sul servizio Azure Kubernetes costi meno da eseguire, è necessario vincolare l'applicazione in base ai requisiti del servizio Azure Kubernetes. Se la riduzione al minimo delle modifiche è il fattore più importante per il lavoro di migrazione, prendere in considerazione una migrazione basata su vm. In questo caso, vedere Eseguire la migrazione di applicazioni WebLogic ad Azure Macchine virtuali. Se è possibile tollerare la conversione dell'applicazione per l'esecuzione all'interno di Kubernetes per ridurre i costi di runtime, prendere in considerazione una migrazione basata sul servizio Azure Kubernetes. In questo caso, continuare con Eseguire la migrazione di applicazioni WebLogic Server a servizio Azure Kubernetes.

Determinare se le offerte predefinite di Azure Marketplace sono un buon punto di partenza

Oracle e Microsoft hanno collaborato per portare un set di modelli di soluzioni di Azure in Azure Marketplace per offrire un punto di partenza solido per la migrazione ad Azure. Consultare la documentazione sul middleware Oracle Fusion per l'elenco di offerte disponibili e scegliere quella più indicata per la distribuzione esistente. È possibile visualizzare l'elenco di offerte nell'articolo di panoramica Informazioni su Oracle WebLogic Server in Azure

Se nessuna delle offerte esistenti è un buon punto di partenza, è necessario riprodurre la distribuzione con le risorse della macchina virtuale di Azure. Per istruzioni dettagliate, vedere Installare Oracle WebLogic Server in Azure Macchine virtuali manualmente. Per altre informazioni, vedere Che cos'è IaaS?

Determinare se la versione di WebLogic è compatibile

La versione di WebLogic esistente deve essere compatibile con la versione presente nelle offerte IaaS. Per visualizzare le offerte per WebLogic versione 12.2.1.3, eseguire query su Azure Marketplace per Oracle WebLogic 12.2.1.3. Se la versione di WebLogic esistente non è compatibile con tale versione, è necessario riprodurre la distribuzione con le risorse IaaS di Azure. Per altre informazioni, vedere la documentazione di Azure.

Inventario della capacità dei server

Documentare l'hardware (memoria, CPU, disco) dei server di produzione correnti oltre al numero medio e massimo di richieste e all'utilizzo delle risorse. La scelta delle dimensioni delle VM si deve basare su queste informazioni. Per altre informazioni, vedere Dimensioni dei servizi cloud.

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>

Verificare che la versione di Java supportata funzioni correttamente

Tutti i percorsi di migrazione per WebLogic in Azure richiedono una versione specifica di Java, che varia per ogni percorso. Sarà necessario verificare che l'applicazione sia in grado di funzionare correttamente usando tale versione supportata.

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

Nota

Quando si esegue la migrazione a WLS in macchine virtuali di Azure, i requisiti per le versioni Java specifiche sono determinati da Java preinstallato nelle macchine virtuali. Quando si esegue la migrazione a WLS nel servizio Azure Kubernetes, la versione Java specifica viene determinata dall'immagine del contenitore scelta. Esistono un'ampia gamma di scelte, ma tutte usano Oracle JDK.

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 tre opzioni:

  • Coherence*Web può essere eseguito insieme a WebLogic Server nelle macchine virtuali di Azure, ma è necessario configurare manualmente questa opzione dopo aver effettuato il provisioning dell'offerta. Se si usa la versione autonoma di Coherence, è possibile eseguire anche questa nelle macchine virtuali di Azure, ma è necessario configurare manualmente questa opzione dopo aver effettuato il provisioning dell'offerta.
  • 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 viene usata la gestione su REST

Se il ciclo di vita dell'applicazione include l'uso della gestione su REST, è necessario acquisire informazioni sulle porte che vengono usate per accedere all'API REST e determinare come vengono autenticate ed esposte. Dopo la migrazione sarà necessario assicurarsi che vengano esposti gli stessi meccanismi di autenticazione e le stesse porte, in modo che il ciclo di vita dell'applicazione rimanga simile a come era prima della migrazione. Per altre informazioni, vedere Amministrazione di Oracle WebLogic Server con i servizi di gestione RESTful.

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 Scegliere una soluzione per la connessione di 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 JMS, sarà necessario eseguirne la migrazione a un server JMS ospitato esternamente. Il bus di servizio di Azure e Advanced Message Queueing Protocol possono costituire un'ottima strategia di migrazione per coloro che usano JMS. Per altre informazioni, vedere Usare JMS con il bus di servizio e AMQP 1.0.

Se sono stati configurati archivi persistenti JMS, è necessario acquisire la relativa configurazione e applicarla dopo la migrazione.

Se si usa Oracle Message Broker, è possibile eseguire la migrazione di questo software alle macchine virtuali di Azure e usarlo così com'è.

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, sarà necessario effettuarne il refactoring per rimuovere tali dipendenze. Ad esempio, potrebbe essere necessario sostituire qualsiasi utilizzo di / o \ nei percorsi del file system con File.Separator o Paths.get.

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.

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

Se attualmente si usa lo strumento WLST per eseguire la distribuzione, sarà necessario valutare quali operazioni esegue. Se lo strumento WLST cambia qualsiasi parametro (runtime) dell'applicazione come parte della distribuzione, è necessario assicurarsi che questo comportamento continui a funzionare durante i test dell'applicazione dopo la migrazione.

Determinare se e come viene usato il file system

I file system delle VM funzionano allo stesso modo di quelli locali in termini di persistenza, avvio e arresto. Ciononostante, è importante tenere presenti i requisiti dei file system e assicurarsi che le VM abbiano dimensioni dello spazio di archiviazione e prestazioni adeguate.

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. È anche possibile distribuire direttamente il contenuto statico in un'app nel piano Azure Spring Apps Enterprise. Per altre informazioni, vedere Distribuire file statici Web.

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. È anche possibile distribuire direttamente il contenuto statico in un'app nel piano Azure Spring Apps Enterprise. Per altre informazioni, vedere Distribuire file statici Web.

Determinare la topologia di rete

Il set corrente di offerte di Azure Marketplace è un punto di partenza per la migrazione. Se l'offerta non copre gli aspetti dell'architettura di cui è necessario eseguire la migrazione, sarà necessario acquisire la topologia di rete della distribuzione esistente e riprodurla in Azure, anche dopo aver approntato l'offerta di base con uno dei modelli di soluzione.

Si tratta di un argomento molto ampio, ma le informazioni di riferimento seguenti possono fornire un orientamento per le attività di migrazione:

Tenere conto dell'uso di adapter JCA e adapter di risorse

Se l'applicazione esistente usa adapter JCA e/o adapter di risorse per la connessione ad altri sistemi aziendali, assicurarsi che la configurazione per questi artefatti venga applicata all'istanza di WebLogic Server in esecuzione nelle macchine virtuali di Azure. Per informazioni, vedere Creazione e configurazione di un adapter di risorse

Tenere conto dell'uso di provider di sicurezza personalizzati e JAAS

Se l'applicazione usa JAAS, è necessario verificare che la migrazione della configurazione dei provider di sicurezza venga eseguita correttamente. Per altre informazioni, vedere Informazioni sulla configurazione dei provider di sicurezza di WebLogic nella documentazione di Oracle.

Determinare se viene usato il clustering WebLogic

Molto probabilmente, l'applicazione viene distribuita in più server WebLogic per ottenere disponibilità elevata. È possibile eseguire la migrazione di questi cluster direttamente dall'installazione locale a WebLogic in esecuzione nelle macchine virtuali di Azure. Per altre informazioni, vedere File di configurazione del dominio nella documentazione di Oracle.

Includere i requisiti per il bilanciamento del carico

Il bilanciamento del carico è una parte essenziale della migrazione del cluster Oracle WebLogic Server in Azure. La soluzione più semplice consiste nell'usare il supporto predefinito per Gateway applicazione di Azure fornito nell'offerta di Azure Marketplace per il cluster Oracle WebLogic Server. Per un'esercitazione su questo argomento, vedere Esercitazione: Eseguire la migrazione di un cluster WebLogic Server ad Azure con gateway di app Azure lication come servizio di bilanciamento del carico.

Per un riepilogo delle funzionalità di Gateway applicazione di Azure rispetto ad altre soluzioni di bilanciamento del carico di Azure, vedere Panoramica delle opzioni di bilanciamento del carico in Azure.

Determinare se viene usata la funzionalità Java EE Application Client

Se l'applicazione usa la funzionalità Java EE Application Client, dovrebbe continuare a funzionare inalterata dopo la migrazione alle macchine virtuali di Azure. Per altre informazioni, vedere Uso dei moduli di Java EE Application Client.

Migrazione

Selezionare un'offerta di WebLogic in macchine virtuali di Azure

Le offerte seguenti sono disponibili per WebLogic in macchine virtuali di Azure.

Durante la distribuzione di un'offerta, viene chiesto di scegliere le dimensioni della macchina virtuale per i nodi del server WebLogic. Nella scelta delle dimensioni delle VM, è importante considerare tutti gli aspetti, ossia memoria, processore e disco. Per altre informazioni, vedere la documentazione di Azure per il dimensionamento delle macchine virtuali

Singolo nodo di WebLogic Server senza server di amministrazione

Questa offerta crea una singola macchina virtuale in cui viene installato WebLogic, ma senza configurare alcun dominio, il che è utile per gli scenari con una configurazione di domini altamente personalizzata.

Singolo nodo di WebLogic con server di amministrazione

Questa offerta prevede il provisioning di una singola VM in cui viene installato WebLogic Server. Viene creato un dominio e viene avviato il server di amministrazione.

Cluster a n nodi di WebLogic Server

Questa offerta crea un cluster a disponibilità elevata di macchine virtuali WebLogic Server.

Cluster dinamico a n nodi di WebLogic Server

Questa offerta crea un cluster dinamico, scalabile e a disponibilità elevata di macchine virtuali WebLogic Server

Effettuare il provisioning dell'offerta

Dopo aver selezionato l'offerta da cui iniziare, seguire le istruzioni riportate nella documentazione per le offerte per effettuarne il provisioning. Assicurarsi di scegliere il nome di dominio che corrisponde al nome di dominio esistente. È anche possibile usare la stessa password di dominio esistente.

Eseguire la migrazione dei domini

Dopo aver effettuato il provisioning dell'offerta, è possibile esaminare la configurazione dei domini e seguire questa guida per informazioni su come eseguirne la migrazione.

Connettere i database

Dopo aver eseguito la migrazione dei domini, è possibile connettere i database seguendo le istruzioni riportate nella documentazione dell'offerta. Queste istruzioni consentono di tenere conto dei segreti del database e delle stringhe di accesso coinvolte.

Tenere conto degli archivi chiavi

È necessario tenere conto della migrazione di eventuali archivi chiavi SSL usati dall'applicazione. Per altre informazioni, vedere Configurazione degli archivi chiavi.

Connettere le origini JMS

Dopo aver connesso i database, è possibile configurare JMS. Per altre informazioni, vedere Fusion Middleware Amministrazione istering delle risorse JMS per Oracle WebLogic Server nella documentazione di WebLogic.

Includere l'autenticazione e l'autorizzazione

La maggior parte delle applicazioni include una forma di autenticazione e autorizzazione. Se si usa LDAP per l'autenticazione, è possibile configurare Microsoft Entra Domain Services con LDAP sicuro e configurare le connessioni LDAP in WebLogic Server. Per altre informazioni, vedere Creare e configurare un dominio gestito di Microsoft Entra Domain Services e Configurare LDAP sicuro per un dominio gestito di Microsoft Entra Domain Services.

Tenere conto della registrazione

Usare l'integrazione con Elastic in Azure fornita dai modelli di soluzione del marketplace Oracle WebLogic Server. Questo approccio è il modo più semplice per tenere conto della registrazione. È possibile visualizzare l'elenco delle offerte nell'articolo panoramica Informazioni sulle soluzioni per l'esecuzione di Oracle WebLogic Server in Azure Macchine virtuali? Le esercitazioni complete per configurare Elastic sono disponibili in:

Se l'integrazione elastica non è appropriata, è necessario eseguire la configurazione di registrazione esistente quando si esegue la migrazione del dominio. Per altre informazioni, vedere Configurare i livelli di logger java.util.logging e Configurare i file di log e filtrare i messaggi di log per Oracle WebLogic Server nella documentazione di Oracle.

Migrazione delle applicazioni

Le tecniche usate per distribuire le applicazioni dai computer di sviluppo ai server di test, staging e produzione variano enormemente da un caso all'altro. In alcuni casi, è presente una piattaforma CI/CD altamente evoluta che comporta la distribuzione delle applicazioni in WebLogic Server. In altri casi, il processo può essere maggiormente manuale. Uno dei vantaggi offerti dall'uso di Azure Macchine virtuali per eseguire la migrazione di applicazioni WebLogic nel cloud consiste nel fatto che i processi esistenti continuano a funzionare.

È necessario configurare il gruppo di sicurezza di rete di cui viene effettuato il provisioning dell'offerta per consentire l'accesso dalla pipeline CI/CD o dal sistema di distribuzione manuale. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Test in corso

Tutti i test effettuati in contenitori sulle applicazioni devono essere configurati per l'accesso ai nuovi server eseguiti in Azure. Come per i problemi di CI/CD, è necessario assicurarsi che le regole di sicurezza di rete necessarie consentano ai test di accedere alle applicazioni distribuite in Azure. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Dopo la migrazione

Una volta raggiunti gli obiettivi di migrazione definiti nel passaggio di pre-migrazione, eseguire alcuni test di accettazione end-to-end per verificare che tutto funzioni come previsto. Per indicazioni su alcuni potenziali miglioramenti post-migrazione, vedere le raccomandazioni seguenti: