Condividi tramite

Eseguire la migrazione di applicazioni WebLogic Server a servizio Azure Kubernetes (servizio Azure Kubernetes)

  • Articolo

Questa guida descrive cosa è necessario tenere presente quando si vuole eseguire la migrazione di un'applicazione WebLogic Server (WLS) esistente da eseguire in servizio Azure Kubernetes (servizio Azure Kubernetes).

Pre-migrazione

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

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 l'offerta predefinita di Azure Marketplace è un buon punto di partenza

Dopo aver deciso che il servizio Azure Kubernetes è la destinazione di distribuzione appropriata, è necessario accettare che l'operatore Kubernetes Oracle WLS (operatore) sia l'unico modo per eseguire WLS in Kubernetes. Dopo aver accettato questo fatto, è necessario decidere se l'offerta predefinita di Azure Marketplace è un buon punto di partenza. Ecco alcuni aspetti da considerare sull'offerta predefinita di Azure Marketplace.

  • Oracle e Microsoft hanno creato questa offerta per consentire di effettuare rapidamente il provisioning di WLS nel servizio Azure Kubernetes usando il tipo di origine home del dominio image . Questo concetto è illustrato in modo più dettagliato più avanti in questo articolo.
  • A livello generale, l'offerta automatizza automaticamente i passaggi seguenti.
    • Prendere una distribuzione WAR o EAR esistente, se necessario.
    • Eseguire il wrapping in un contenitore usando WebLogic Image Tool (WIT). Per altre informazioni, vedere WebLogic Image Tool nella documentazione di Oracle.
    • Installare e configurare l'operatore Kubernetes WebLogic nel servizio Azure Kubernetes.
    • Usare l'operatore per eseguire l'intera operazione. L'operatore richiama WebLogic Deploy Tooling (WDT) per supportare gli ambienti WebLogic ed eseguire operazioni del ciclo di vita del dominio in modo ripetibile in base a un modello di metadati. Per altre informazioni, vedere Strumenti di distribuzione WebLogic nella documentazione di Oracle.
  • Anche se l'offerta predefinita offre numerose integrazioni dei servizi di Azure, ad esempio gateway app, registrazione elastica, integrazione del database e altro ancora, semplifica molti presupposti. Questi presupposti rendono l'offerta non flessibile come il mastering e l'uso dell'operatore manualmente.

Se non si usa l'offerta predefinita di Azure Marketplace, è necessario imparare a usare direttamente l'operatore. Il mastering dell'operatore non rientra nell'ambito di questo articolo. La documentazione completa per l'operatore Kubernetes WLS è disponibile in Oracle.

Nella parte restante di questa sezione vengono fornite alcune considerazioni per decidere di usare direttamente l'offerta predefinita di Azure Marketplace o l'operatore .

Decidere se usare l'offerta predefinita di Azure Marketplace

Prima di tutto, è necessario comprendere il concetto di "dominio" di WLS. Un dominio è un gruppo di risorse WLS correlato logicamente. Per la definizione canonica del dominio WLS, vedere la documentazione di Oracle. L'esecuzione di WLS nel servizio Azure Kubernetes richiede la scelta del modo in cui il servizio Azure Kubernetes gestisce i domini. Le varie scelte sono denominate "tipo di origine home del dominio". L'operatore Kubernetes WLS supporta tre opzioni del tipo di origine home del dominio. L'offerta predefinita di Azure Marketplace usa la prima di questa tabella.

Tipo di origine home del dominio Descrizione Aspetti positivi Aspetti negativi
Modello nell'immagine WLS e le applicazioni si trovano nell'immagine del contenitore e tutto il resto viene mantenuto all'esterno di tale immagine. Supportato dall'offerta predefinita. Documentata come esempio ufficiale; vedere Oracle. La maggior parte usa WDT. Opzione più "nativa del cloud". Integrazione CI/CD più semplice. Curva di apprendimento più grande.
Dominio in PV Il dominio risiede in un volume permanente Kubernetes. Concettualmente simile all'esecuzione nelle macchine virtuali. È possibile usare la console WLS per apportare modifiche e tali modifiche vengono mantenute tra i riavvii del pod del servizio Azure Kubernetes. Documentata come esempio ufficiale; vedere Oracle. È necessario attenuare alcune problematiche correlate a NFS. Per altre informazioni, vedere Oracle. Questo approccio è la tecnica meno nativa del cloud; lo stato si trova interamente all'esterno del cluster del servizio Azure Kubernetes.
Dominio nell'immagine Il dominio risiede in un'immagine del contenitore. Le applicazioni sono contenute in un'immagine del contenitore sovrapposta nell'immagine del dominio. Più "nativo del cloud" rispetto al dominio in PV. Più facile per CI/CD. Non è possibile usare la console WLS. Deve mantenere più immagini del contenitore.

Importante

Se si sceglie il dominio nel tipo di origine PV , è consigliabile NFS anziché SMB. NFS si è evoluto dal sistema operativo UNIX e da altre varianti come GNU/Linux. Per questo motivo, quando si usa NFS con tecnologie contenitore come Docker, è meno probabile che si verifichino problemi per le letture simultanee e il blocco dei file.

Assicurarsi di abilitare NFS v4.1. Le versioni precedenti alla versione 4.1 avranno problemi.

La documentazione dell'operatore include anche una tabella utile che confronta le varie opzioni. Per altre informazioni, vedere Scegliere un tipo di origine home del dominio.

Per una panoramica dell'offerta predefinita di Azure Marketplace, vedere Avvio rapido: Distribuire WebLogic Server in servizio Azure Kubernetes usando il portale di Azure. Per la documentazione di riferimento sull'offerta predefinita di Azure Marketplace, vedere Oracle.

Per provare a usare direttamente l'operatore, provare gli esempi nella documentazione dell'operatore.

Ora che sono stati introdotti i vari modi per gestire i domini WLS nel servizio Azure Kubernetes, è possibile scegliere se usare l'offerta predefinita di Azure Marketplace o per farlo usando direttamente l'operatore.

Determinare se la versione di WebLogic è compatibile

La versione WLS esistente deve essere una delle versioni supportate dall'operatore . Oracle gestisce queste versioni in Oracle Container Registry (OCR). Usare la procedura seguente per visualizzare l'elenco delle versioni supportate.

  1. Visitare il sito Web di Oracle Container Registry e accedere. Per ulteriori informazioni, vedere https://container-registry.oracle.com/.
  2. Se si dispone di un diritto di supporto, selezionare Middleware, quindi cercare weblogic_cpu. Selezionare weblogic_cpu.
  3. Se non si ha un diritto di supporto da Oracle, selezionare Middleware, quindi cercare weblogic. Selezionare weblogic.

Nota

Ottenere un diritto di supporto da Oracle prima di passare all'ambiente di produzione. In caso contrario, l'esecuzione di immagini non sicure che non vengono applicate patch per errori di sicurezza critici. Per altre informazioni sugli aggiornamenti critici delle patch di Oracle, vedere Aggiornamenti critici delle patch, avvisi di sicurezza e bollettini.

L'offerta predefinita di Azure Marketplace consente di selezionare le immagini WLS da OCR e Registro Azure Container (ACR) e supporta in modo implicito tutte le versioni disponibili da OCR. Se si indica all'offerta di eseguire il pull di un'immagine da Registro Azure Container, assicurarsi che sia derivata da una delle versioni supportate elencate in OCR.

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

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.

Dopo aver ottenuto un inventario solido dei segreti, consultare la documentazione dell'operatore relativa ai segreti. Per altre informazioni, vedere Segreti.

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>

Dopo aver ottenuto un inventario solido dei certificati, è possibile installarli direttamente con l'offerta predefinita di Azure Marketplace. Per altre informazioni, vedere Configurazione TLS/SSL. Se si usa direttamente l'operatore, vedere Aggiornamento dei certificati esterni dell'operatore.

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.

Se si usa l'offerta predefinita di Azure Marketplace, il set di risorse JNDI che è possibile personalizzare in fase di distribuzione è limitato a ciò che l'offerta supporta. Cercare JNDI nella documentazione dell'offerta. Se si usa direttamente l'operatore, le risorse JDNI possono essere definite a seconda del tipo di origine home del dominio scelto. Per Dominio in PV, è possibile impostarli nel modo consueto, con WLST o con la console di amministrazione. Per il dominio nell'immagine o nel modello, vedere Sostituzioni tipiche.

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.

L'offerta predefinita di Azure Marketplace crea automaticamente una risorsa di dominio. Se si usa direttamente l'operatore, è possibile personalizzare completamente il modo in cui viene rappresentato il dominio. Per informazioni complete, vedere Risorsa di dominio.

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.

L'offerta predefinita di Azure Marketplace supporta l'affinità di sessione tramite il controller di ingresso gateway applicazione. L'affinità basata su cookie è abilitata per impostazione predefinita. È possibile selezionare Disabilita affinità basata su cookie per disabilitarla. Cercare l'affinità basata su cookie nella documentazione per l'offerta.

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.

L'offerta predefinita di Azure Marketplace offre supporto per i database più diffusi. Per altre informazioni, vedere Database. Per Dominio in PV, è possibile impostarli nel modo consueto, con WLST o con la console di amministrazione. Per il dominio nell'immagine o nel modello, vedere Sostituzioni tipiche.

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?

È necessario acquisire queste personalizzazioni nell'immagine del contenitore eseguita dal servizio Azure Kubernetes. Per l'offerta predefinita di Azure Marketplace, tali personalizzazioni vengono gestite al meglio creando un'immagine del contenitore personalizzata e rendendola disponibile in Registro Azure Container, quindi puntando a tale registro in fase di distribuzione. Per altre informazioni, vedere Selezione dell'immagine. Se si usa direttamente l'operatore, vedere Variabili di ambiente JVM memory e Java option.

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.

L'unico tipo di origine home del dominio in cui è opportuno continuare a usare la gestione su REST è Domain in PV. È possibile usarlo con gli altri tipi di origine home del dominio, ma le modifiche apportate sono temporanee e non vengono mantenute tra i riavvii dei pod.

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

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.

Queste librerie possono essere gestite usando le stesse tecniche descritte in Determinare se WebLogic è stato personalizzato.

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.

È possibile includerli nell'offerta WAR o EAR fornita all'offerta predefinita di Azure Marketplace o usando direttamente l'operatore .

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.

WLS nel servizio Azure Kubernetes viene eseguito in Oracle Linux. Qualsiasi codice specifico del sistema operativo deve essere compatibile con Oracle Linux. Per informazioni su come individuare informazioni specifiche sul sistema operativo, seguire la procedura descritta in Determinare se la versione di WebLogic è compatibile.

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.

OSB non è supportato direttamente nell'offerta predefinita di Azure Marketplace. Se è necessario usare OSB, è necessario usare direttamente l'operatore .

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.

L'offerta predefinita di Azure Marketplace supporta le richieste di accesso e le richieste pull. L'uso diretto dell'operatore supporta anche war ed EAR.

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.

L'unico tipo di origine home del dominio compatibile con l'uso di WLST è Domain in PV. Per altre informazioni, vedere Home del dominio in un pv.

Determinare se e come viene usato il file system

Kubernetes gestisce i file system con volumi persistenti (PV). Il montaggio di volumi permanenti è supportato nell'offerta predefinita di Azure Marketplace e quando si usa direttamente l'operatore . Se si usa Dominio in PV, il file system è un aspetto centrale della configurazione.

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.

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 la distribuzione si basa su adattatori di risorse, l'opzione più supportata è Domain home in un pv.

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.

Se la distribuzione si basa su provider di sicurezza, l'opzione più supportata è Domain home in un pv.

Determinare se viene usato il clustering WebLogic

L'operatore gestisce il clustering per tutti i possibili modi di eseguire WLS nel servizio Azure Kubernetes.

Esaminare il clustering EJB

Se l'applicazione usa EJB locale, è necessario eseguirne la migrazione a EJB in cluster. Per altre informazioni, vedere Clustering e EJB locale.

Includere i requisiti per il bilanciamento del carico

Il modo migliore per tenere conto del bilanciamento del carico consiste nell'usare l'integrazione del gateway app fornita dall'offerta predefinita di Azure Marketplace. Per altre informazioni, vedere Esercitazione: Eseguire la migrazione di un cluster WebLogic Server ad Azure con gateway di app Azure lication come servizio di bilanciamento del carico.

Determinare se viene usata la funzionalità Java EE Application Client

Se la distribuzione si basa sui client dell'applicazione Java EE, è consigliabile usare direttamente l'operatore. Per altre informazioni, vedere Client esterni.

Determinare se sono necessarie più immagini del contenitore

Un dominio WebLogic Server può contenere più cluster. Ad esempio, un'applicazione a più livelli può essere rappresentata in un singolo dominio, ma ha due cluster, ad esempio "front-end" e "back-end". È utile essere in grado di aggiornare il front-end, senza aggiornare il back-end e viceversa. Con il tipo di origine home del dominio Image , tuttavia, l'intero dominio è rappresentato in un'immagine del contenitore. Per soddisfare questo caso d'uso, è necessario separare i cluster nei rispettivi domini, ognuno con la propria immagine del contenitore. L'operatore può gestire più domini in più spazi dei nomi. Per altre informazioni, vedere Scegliere una strategia di selezione dello spazio dei nomi di dominio

L'adozione di più domini può introdurre problemi di accesso T3 tra domini. Per risolvere questi problemi, abilitare un canale personalizzato come descritto in Determinare se è necessario abilitare l'accesso host sconosciuto.

Determinare se è necessario abilitare l'accesso host sconosciuto

Potrebbe essere necessario abilitare l'accesso all'host sconosciuto applicando una patch a WebLogic per gli scenari seguenti:

  • Consentire l'accesso T3 da client esterni al servizio Azure Kubernetes ai cluster WLS nel servizio Azure Kubernetes tramite un canale personalizzato.
  • Consentire l'accesso T3 tra domini WLS diversi nel servizio Azure Kubernetes tramite un canale personalizzato.

Per informazioni dettagliate sulla patch, seguire le indicazioni riportate in Come usare la ricerca patch in My Oracle Support (MOS) e cercare patch 30656708.

Dopo l'applicazione della patch, vedere Abilitazione dell'accesso host sconosciuto.

Migrazione

I passaggi descritti in questa sezione presuppongono che l'analisi abbia portato a decidere di usare l'offerta predefinita di Azure Marketplace.

Effettuare il provisioning dell'offerta

Per aprire l'offerta nel portale di Azure, vedere https://aka.ms/wlsaks. Selezionare Crea e quindi seguire le istruzioni nella documentazione per l'offerta. Usare le informazioni raccolte nei passaggi precedenti per facilitare la compilazione dei campi dell'offerta.

Eseguire la migrazione dei domini

Dopo aver effettuato il provisioning dell'offerta, restituire il dominio seguendo questa procedura.

Se ci si è allontanati dalla pagina Distribuzione in corso, i passaggi seguenti mostrano come tornare a quella pagina. Se si è ancora nella pagina che mostra il messaggio La distribuzione è stata completata, è possibile passare al quinto passaggio.

  1. In alto a sinistra di qualsiasi pagina del portale selezionare il menu hamburger e selezionare Gruppi di risorse.

  2. Nella casella con il testo Filtra per qualsiasi campoimmettere i primi caratteri del gruppo di risorse creato in precedenza. Se è stata seguita la convenzione consigliata, immettere le iniziali, quindi selezionare il gruppo di risorse appropriato.

  3. Nella sezione Impostazioni del riquadro di spostamento a sinistra selezionare Distribuzioni per visualizzare un elenco ordinato delle distribuzioni in questo gruppo di risorse, con quello più recente.

  4. Scorrere fino alla voce meno recente in questo elenco. Questa voce corrisponde alla distribuzione avviata nella sezione precedente. Selezionare la distribuzione meno recente, come illustrato nello screenshot seguente.

    Screenshot di portale di Azure che mostra l'elenco delle distribuzioni del gruppo di risorse.

  5. Nel riquadro a sinistra, selezionare Output. Questo elenco mostra i valori di output della distribuzione. Informazioni utili sono incluse negli output. Gli output che consentono di esaminare il dominio e interagire con l'operatore sono interessati. Gli altri valori negli output sono illustrati in dettaglio nella Guida dell'utente di WebLogic nel servizio Azure Kubernetes.

  6. Individuare l'output denominato shellCmdtoConnectAks. Incollare il valore dell'output in una shell Bash ed eseguire il comando . Questo comando consente di usare kubectl come descritto in Connettersi al cluster.

  7. Individuare l'output denominato shellCmdtoOutputWlsDomainYaml. Incollare il valore dell'output in una shell Bash ed eseguire il comando . Questo comando restituisce la risorsa di dominio come file YAML.

  8. Ora che si dispone del dominio YAML della distribuzione corrente, è possibile applicare le informazioni in Distribuzione dei file YAML delle risorse di dominio ed esaminare queste indicazioni per altre indicazioni su come eseguire la migrazione dei domini. Questo materiale sussidiario richiede l'adattamento da applicare al modo in cui Kubernetes esegue le operazioni, ma è comunque utile sapere.

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 seguendo le istruzioni riportate in Middleware di Fusion per l'amministrazione di risorse JMS per Oracle WebLogic Server nella documentazione di WebLogic.

Tenere conto della registrazione

Non è possibile eseguire il cloud senza la registrazione mastering. L'operatore fornisce esempi per l'uso di Elasticsearch e Kibana. Per altre informazioni, vedere la documentazione dell'operatore. Azure offre un ottimo supporto per Elastic. Per informazioni dettagliate, vedere Che cos'è l'integrazione elastica con Azure?. È possibile combinare le conoscenze in queste due risorse per ottenere una soluzione di registrazione ottimizzata per Azure per WLS nel servizio Azure Kubernetes.

Migrazione delle applicazioni

Indipendentemente dal fatto che si sia scelto di fornire un file WAR o EAR in fase di distribuzione, è necessario aggiornare l'applicazione tramite CI/CD. La documentazione dell'operatore include un esempio che illustra come eseguire questo aggiornamento. Per altre informazioni, vedere Update 3. Gli altri esempi di aggiornamento sono rilevanti per la migrazione e vale la pena esplorare.

Test

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.

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