Eseguire la migrazione di applicazioni JBoss EAP ad Azure Red Hat OpenShift

  • Articolo

Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione JBoss EAP esistente da eseguire in Azure Red Hat OpenShift.

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 JBoss EAP in Azure consiste nel selezionare la destinazione di migrazione più appropriata. JBoss EAP funziona bene nelle macchine virtuali di Azure o in Azure Red Hat OpenShift.

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 è analoga a quella in locale. La selezione delle macchine virtuali consente di rinviare la modernizzazione.

Red Hat OpenShift riunisce servizi testati e attendibili per ridurre l'attrito dello sviluppo, della modernizzazione, della distribuzione, dell'esecuzione e della gestione delle applicazioni. Azure Red Hat OpenShift è basato su Kubernetes. Azure Red Hat OpenShift offre un'esperienza coerente nel cloud pubblico, nel cloud locale, nel cloud ibrido o nell'architettura perimetrale.

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 JBoss EAP a JBoss EAP in macchine virtuali di Azure. Se è possibile tollerare la conversione dell'applicazione per l'esecuzione all'interno di Red Hat OpenShift per ridurre i costi di runtime, prendere in considerazione una migrazione basata su Azure Red Hat OpenShift. In questo caso, continuare con Eseguire la migrazione di applicazioni JBoss EAP a JBoss EAP in Azure Red Hat OpenShift. Per comprendere le differenze tra JBoss EAP e JBoss EAP per OpenShift, vedere Confronto: JBoss EAP e JBoss EAP per OpenShift.

Determinare se l'offerta predefinita di Azure Marketplace è un buon punto di partenza

Prima di tutto, decidere che Azure Red Hat OpenShift è la destinazione di distribuzione appropriata. Successivamente, decidere se l'offerta predefinita di Azure Marketplace è un buon punto di partenza. Considerare i punti seguenti sull'offerta predefinita di Azure Marketplace:

  • Red Hat e Microsoft hanno creato questa offerta per abilitare il provisioning rapido di JBoss EAP in Azure Red Hat OpenShift.
  • A livello generale, l'offerta automatizza automaticamente i passaggi seguenti.

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

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

Determinare se la versione di JBoss EAP è compatibile

La versione JBoss EAP esistente deve essere una delle versioni supportate dall'operatore . Per altre informazioni, vedere Compatibilità e supporto delle versioni nella documentazione di Red Hat.

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 sono necessarie indipendentemente dal percorso di migrazione scelto. Gli aspetti seguenti, e altro ancora, traggono vantaggio dalla disponibilità di un inventario dettagliato della capacità del server.

  • Per facilitare la selezione delle dimensioni delle macchine virtuali nel pool di nodi.
  • Per comprendere la quantità di memoria da usare dal contenitore.
  • Per conoscere il numero di condivisioni di CPU necessarie per il contenitore.

È possibile ridimensionare i pool di nodi in Azure Red Hat OpenShift. Per altre informazioni, vedere Ridimensionamento di un cluster--Microsoft Azure nella documentazione di Red Hat.

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 JBoss EAP, questi segreti si trovano in molti file di configurazione 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 i file di configurazione come custom-config.xml o jboss-web.xml nelle applicazioni. 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 EAP relativa ai segreti. Per altre informazioni, vedere Creazione di un segreto nella documentazione di Red Hat.

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 configurarli in Azure Red Hat OpenShift. Per altre informazioni, vedere Configurazione TLS in OpenShift Container Platform(replace) nella documentazione di Red Hat.

Verificare che la versione di Java supportata funzioni correttamente

Tutti i percorsi di migrazione per JBoss EAP in Azure Red Hat OpenShift richiedono una versione Java specifica, che varia per ogni percorso. È necessario verificare che l'applicazione sia in grado di essere eseguita 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

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 sulle risorse e i database JNDI, vedere Gestione delle origini dati nella documentazione di Red Hat. Altre risorse correlate a JNDI, ad esempio Broker messaggi Artemis ActiveMQ, possono richiedere la migrazione o la riconfigurazione. Per altre informazioni sulla configurazione di ActiveMQ Artemis, vedere Configurazione della messaggistica nella documentazione di Red Hat.

Determinare se viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica di sessione, con o senza Infinispan, sono disponibili tre opzioni:

  • Infinispan funziona bene nelle macchine virtuali di Azure, ma se si usa un profilo che offre funzionalità a disponibilità elevata, tenere presente la configurazione di JGroups . Determinare se il sistema funziona come dominio gestito o server autonomo.
    • Se in un dominio gestito, i profili ha o full-ha gestiscono JGroups.
    • Se in un server autonomo, i file di configurazione standalone-ha.xml o autonomi-full-ha.xml gestiscono JGroups.
    • Microsoft Azure non supporta i protocolli di individuazione JGroups basati sul multicast UDP. Per altre informazioni, vedere Uso della disponibilità elevata di JBoss EAP in Microsoft Azure nella documentazione di Red Hat.
  • 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 gestire il modo in cui JBoss EAP esegue la replica dello stato della sessione HTTP. Per altre informazioni, vedere Informazioni sulla replica di sessione HTTP nella documentazione di Red Hat.

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 JBoss EAP, vedere Gestione delle origini dati nella documentazione di Red Hat.

Determinare se JBoss EAP è 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 host, eap_env, autonomo e dominio.
  • Sono stati passati parametri specifici alla JVM?
  • Sono stati aggiunti JAR al classpath del server?

Queste personalizzazioni devono essere acquisite nell'immagine del contenitore in esecuzione in Azure Red Hat OpenShift. Per altre informazioni, vedere Configuring the JBoss EAP for OpenShift Image for Your Java Application (Configurazione di JBoss EAP per l'immagine OpenShift per l'applicazione Java) nella documentazione di Red Hat.

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, è consigliabile 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.

Per altre informazioni, vedere Configurazione della messaggistica nella documentazione di Red Hat.

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.

È possibile gestire queste librerie usando le stesse tecniche descritte nella sezione Determinare se JBoss EAP è stata personalizzata .

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.

Azure Red Hat OpenShift viene eseguito in OpenShift 4 usando Red Hat Enterprise Linux CoreOS (RHCOS) come sistema operativo per tutti i nodi del piano di controllo e del ruolo di lavoro. Qualsiasi codice specifico del sistema operativo deve essere compatibile con RHCOS.

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

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. Per altre informazioni, vedere Che cos'è app Azure lication Gateway?

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 nella portale di Azure, vedere JBoss EAP in Azure Red Hat OpenShift. Selezionare Crea e quindi seguire le istruzioni nell'offerta.

Migrazione delle applicazioni

L'offerta supporta il processo da origine a immagine (S2I) per compilare ed eseguire un'applicazione Java nell'immagine JBoss EAP per OpenShift. Red Hat include un esempio che illustra come eseguire manualmente questa operazione se si vuole eseguire la distribuzione in un secondo momento manualmente. Per altre informazioni, vedere Capitolo 2. Compilare ed eseguire un'applicazione Java in JBoss EAP for OpenShift Image nella documentazione di Red Hat.

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 informazioni su alcuni potenziali miglioramenti post-migrazione, vedere gli articoli seguenti: