Eseguire la migrazione di applicazioni WebSphere a servizio Azure Kubernetes (servizio Azure Kubernetes)

  • Articolo

Questa guida descrive gli elementi da tenere presenti quando si vuole eseguire la migrazione di un carico di lavoro esistente di WebSphere Application Server (WAS) a IBM WebSphere Liberty o Open Liberty in servizio Azure Kubernetes (AKS).

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 WAS ad Azure consiste nel selezionare la destinazione di migrazione più appropriata.

WAS tradizionale funziona bene in Azure Macchine virtuali. La destinazione della macchina virtuale (VM) è 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.

Un'altra opzione consiste nel eseguire la migrazione ai contenitori convertendo il carico di lavoro tradizionale WAS in contenitori dell'applicazione. È possibile eseguire la destinazione del contenitore in servizio Azure Kubernetes (AKS) e Azure Red Hat OpenShift. Il compromesso per questa facilità è il costo economico.

In generale, il costo al minuto per una soluzione basata su vm è più elevato rispetto ai contenitori. Anche se una soluzione basata su contenitori costa meno per l'esecuzione, è necessario vincolare l'applicazione in base ai requisiti della piattaforma di orchestrazione dei contenitori.

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 WebSphere ad Azure Macchine virtuali.

Se è possibile tollerare la conversione dell'applicazione in modo che venga eseguita all'interno di contenitori per ridurre i costi di runtime, prendere in considerazione una migrazione basata sul servizio Azure Kubernetes o basata su Azure Red Hat OpenShift.

Per la migrazione basata sul servizio Azure Kubernetes, è possibile iniziare a usare il livello Gratuito. Ottenere la gestione gratuita dei cluster e pagare solo le macchine virtuali, l'archiviazione associata e le risorse di rete utilizzate. In questo caso, vedere Eseguire la migrazione di applicazioni WebSphere a servizio Azure Kubernetes.

Per la migrazione basata su Azure Red Hat OpenShift, oltre ai costi di calcolo e infrastruttura, i nodi dell'applicazione hanno un altro costo per il componente licenze OpenShift. Questo costo viene fatturato in base al numero di nodi dell'applicazione e al tipo di istanza. Usare i prezzi on demand o le istanze riservate, a seconda delle esigenze del carico di lavoro e dell'azienda. In questo caso, vedere Eseguire la migrazione di applicazioni WebSphere ad Azure Red Hat OpenShift.

Le guide pratiche nella documentazione di Azure Red Hat OpenShift illustrano alcuni aspetti rilevanti per la migrazione. Per l'elenco completo delle guide pratiche, vedere la documentazione di Azure Red Hat OpenShift.

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 IBM WebSphere Liberty o Open Liberty Operator (l'operatore) sia l'unico modo per eseguire Liberty 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:

  • IBM e Microsoft hanno creato questa offerta per consentire di effettuare rapidamente il provisioning di Liberty nel servizio Azure Kubernetes. Questo concetto è illustrato in modo più dettagliato nel contenuto seguente.
  • A livello generale, l'offerta automatizza automaticamente i passaggi seguenti.
    • Acquisire un'immagine dell'applicazione esistente, se necessario.
    • Effettuare il provisioning di un cluster del servizio Azure Kubernetes e di un'istanza di Registro Azure Container(ACR), se necessario.
    • Installare e configurare l'operatore IBM WebSphere Liberty o l'operatore Open Liberty nel servizio Azure Kubernetes.
    • Usare l'operatore per eseguire l'intera operazione. L'operatore distribuisce e gestisce applicazioni Liberty in contenitori nel servizio Azure Kubernetes. È possibile trovare la documentazione di riferimento all'operatore IBM WebSphere Liberty e all'operatore Open Liberty.

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 è disponibile all'operatore IBM WebSphere Liberty e all'operatore Open Liberty.

Ora che sono stati introdotti i vari modi per gestire Liberty 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 liberty è compatibile

È necessario l'operatore Open Liberty o l'operatore WebSphere Liberty per distribuire e gestire le applicazioni nei cluster basati su Kubernetes. Assicurarsi che la versione di Liberty esistente sia una delle versioni supportate dall'operatore. Le versioni di Open Liberty vengono mantenute in GitHub OpenLiberty/open-liberty. IBM gestisce le versioni di IBM WebSphere Application Server Liberty. Per altre informazioni, vedere WebSphere Application Server Liberty.

L'offerta predefinita di Azure Marketplace consente di selezionare le immagini dell'applicazione dal registro pubblico e di supportare in modo implicito tutte le versioni.

Determinare se è necessaria una licenza

Per IBM WebSphere Liberty, è necessario accettare le condizioni del contratto di licenza corrispondente alla versione del programma IBM nel contenitore dell'applicazione. Per il contratto di licenza applicabile a questo programma IBM, vedere Visualizzazione delle informazioni sulla licenza per l'operatore WebSphere Liberty. Per altre informazioni, vedere Running WebSphere Liberty on Microsoft Azure (Esecuzione di WebSphere Liberty in Microsoft Azure).

Se l'edizione del prodotto è diversa dall'istanza predefinita di IBM WebSphere Application Server (base), deve specificare l'edizione .spec.license.edition value del prodotto. Altri valori disponibili sono IBM WebSphere Application Server Liberty Core e IBM WebSphere Application Server Network Deployment. L'offerta predefinita di Azure Marketplace consente di selezionare l'edizione del prodotto supportata.

Differenze di inventario con gli strumenti di migrazione IBM

Per spostare le applicazioni in WebSphere Application Server Liberty o Open Liberty, è necessario pianificare la migrazione, analizzare le applicazioni e aggiornare il codice sorgente. IBM offre strumenti di migrazione per identificare eventuali differenze tra l'ambiente corrente e le tecnologie nel nuovo ambiente Liberty, ad esempio Java EE 7 o Java EE 8 e Java SE 8 o Java SE 11. Per altre informazioni, vedere Migrazione di applicazioni a Liberty.

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 WAS, questi segreti si trovano in molti archivi di configurazione e file di configurazione diversi. Controllare tutte le proprietà e i file di configurazione nei server di produzione per verificare la presenza di segreti e password. I file di configurazione contenenti password o credenziali possono trovarsi anche all'interno dell'applicazione. WAS archivia i dati di configurazione in diversi documenti in una gerarchia a catena di directory. La maggior parte dei documenti di configurazione include contenuto XML. Per altre informazioni, vedere Documenti di configurazione e 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 gli articoli seguenti:

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, configurarli usando gli articoli seguenti:

Verificare che la versione di Java supportata funzioni correttamente

L'uso di Liberty richiede una versione specifica di Java, quindi è necessario verificare che l'applicazione venga eseguita correttamente usando tale versione supportata.

Il runtime di WebSphere Application Server Liberty ha requisiti specifici per il livello minimo di Java Runtime Environment (JRE). Per altre informazioni, vedere Dipendenze della versione Java per le funzionalità.

Open Liberty richiede un runtime Java SE. Può essere eseguito usando java Runtime Environment (JRE) o una distribuzione Java SE Development Kit (JDK). Per altre informazioni, vedere Versioni di Java SE supportate.

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 WebSphere Data Sources (Origini dati WebSphere) nella documentazione di IBM. 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 Uso delle risorse JMS.

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. Per WebSphere Liberty nel servizio Azure Kubernetes, è possibile rendere disponibile un oggetto nello spazio dei nomi Java Naming and Directory Interface (JNDI) predefinito. Per altre informazioni, vedere Sviluppo con lo spazio dei nomi predefinito JNDI in una funzionalità Liberty. Per Open Liberty, vedere Java Naming and Directory Interface .For Open Liberty, see Java Naming and Directory Interface.

Esaminare la configurazione del profilo

L'unità di configurazione principale in WAS è il profilo. Di conseguenza, il file di resources.xml contiene un'ampia gamma di configurazioni da considerare con attenzione per la migrazione. Il file include riferimenti ad altri file XML archiviati nelle sottodirectory. Per altre informazioni, vedere Gestione dei profili nei sistemi operativi IBM i e distribuiti.

All'interno dell'applicazione

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

È necessario acquisire queste personalizzazioni nell'immagine del contenitore eseguita dal servizio Azure Kubernetes. Quando si usa l'offerta predefinita di Azure Marketplace, tali personalizzazioni vengono gestite in modo ottimale creando un'immagine del contenitore personalizzata e rendendola disponibile in un registro pubblico, quindi puntando a tale registro in fase di distribuzione.

Se si usa una cella WebSphere Application Server Network Deployment, ogni membro del cluster viene eseguito in un'installazione di WAS tradizionale. Liberty è un profilo leggero del server applicazioni WebSphere. Si tratta di un profilo flessibile e dinamico di WAS, che consente al server WAS di distribuire solo le funzionalità personalizzate necessarie anziché distribuire un ampio set di componenti Java EE disponibili.

Determinare se viene usata la replica delle sessioni

Se l'applicazione si basa sulla replica di sessione, sono disponibili le opzioni seguenti:

  • Per le sessioni HTTP, in base al livello di gestione delle sessioni, è possibile usare la cache o un database per raccogliere i dati della sessione.
  • Per le sessioni distribuite, è possibile salvare le sessioni in un database usando la persistenza della sessione del database.
  • Per La cache dinamica è possibile gestire i dati della sessione nella cache o in un database.
  • È possibile effettuare il refactoring dell'applicazione per usare un database per la gestione delle sessioni.
  • È possibile effettuare il refactoring dell'applicazione per esternalizzare la sessione al servizio Redis di Azure. Per altre informazioni, vedere Azure Cache for Redis.

Per tutte queste opzioni, è consigliabile gestire il modo in cui Liberty esegue la replica dello stato della sessione HTTP. I documenti seguenti consentono di comprendere come gestire le sessioni HTTP in Liberty:

L'offerta predefinita di Azure Marketplace supporta l'affinità di sessione tramite il controller di ingresso gateway applicazione. Quando si distribuisce l'offerta, selezionare Abilita affinità basata su cookie.

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 WAS, vedere Uso dei driver JDBC con WebSphere Application Server.

La configurazione di JDBC è una configurazione del server principale in Liberty. Per altre informazioni, vedere Driver JDBC.

L'offerta predefinita di Azure Marketplace offre un supporto limitato per i database. È possibile gestire la configurazione nelle immagini dell'applicazione e usare l'immagine quando si distribuisce l'offerta.

Determinare se WAS è 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 wsadmin, AdminControl, AdminConfig, AdminApp e AdminTask.
  • Sono stati passati parametri specifici alla JVM?
  • Sono stati aggiunti JAR al classpath del server?
  • Sono state usate funzionalità a livello di sistema operativo, ad esempio systemd per causare l'avvio automatico dei componenti WAS dopo il riavvio del server?

È necessario tenere conto delle considerazioni sulla migrazione a seconda delle risposte a queste domande.

È necessario acquisire queste personalizzazioni nell'immagine del contenitore eseguita dal servizio Azure Kubernetes. Quando si usa l'offerta predefinita di Azure Marketplace, tali personalizzazioni vengono gestite in modo ottimale creando un'immagine del contenitore personalizzata e rendendola disponibile in un registro pubblico, quindi puntando a tale registro in fase di distribuzione.

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, è necessario eseguirne la migrazione a un server JMS ospitato esternamente. Una strategia per coloro che usano JMS consiste nell'usare bus di servizio di Azure e advanced Message Queuing Protocol. 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 permanenti JMS, è necessario acquisire la configurazione e applicarla dopo la migrazione.

Se si usa IBM MQ, è possibile eseguire la migrazione di questo software ad Azure Macchine virtuali e usarlo così come sono.

Microsoft offre una soluzione per integrare IBM MQ con App per la logica. Per altre informazioni, vedere Connettersi a un server IBM MQ da un flusso di lavoro in App per la logica di Azure.

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 in Accesso alle API di terze parti da un'applicazione Java EE.

Determinare se vengono usati bundle OSGi

Se sono stati usati bundle OSGi aggiunti a WAS, è necessario aggiungere i file JAR equivalenti direttamente all'applicazione Web.

È possibile includere i bundle nell'immagine fornita all'offerta predefinita di Azure Marketplace. Per altre informazioni, vedere Configurazione delle librerie per le applicazioni OSGi.

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.

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

Determinare se IBM Integration Bus è in uso

Se l'applicazione usa IBM Integration Bus, è necessario acquisire la configurazione di IBM Integration Bus. Per altre informazioni, vedere la documentazione di IBM Integration Bus.

IBM Integration Bus non è supportato direttamente nell'offerta predefinita di Azure Marketplace. Per abilitare la funzionalità, seguire le istruzioni riportate in Abilitazione dell'applicazione JMS in Liberty per connettersi al bus di integrazione dei servizi nella documentazione di IBM.

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, ibm-application-bnd.xmi e ibm-application-ext.xmi e acquisire le configurazioni. Per altre informazioni, vedere Building the enterprise archive (EAR) package on WebSphere (Building the enterprise archive package on WebSphere).

L'offerta predefinita di Azure Marketplace consente di usare un'immagine del contenitore esistente. È possibile preparare l'applicazione in base ai requisiti aziendali.

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 e come viene usato il file system

Kubernetes gestisce i file system con volumi persistenti (PV). Il montaggio di volumi permanenti non è supportato nell'offerta predefinita di Azure Marketplace. Per abilitare opzioni di archiviazione diverse, seguire le istruzioni in Opzioni di archiviazione per le applicazioni in servizio Azure Kubernetes.

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, è necessario acquisire la topologia di rete della distribuzione esistente. È quindi necessario riprodurre tale topologia in Azure, anche dopo aver alzato l'offerta di base con uno dei modelli di soluzione.

La topologia di rete è un argomento generale, ma i riferimenti seguenti possono dare una direzione alle attività di migrazione:

  • Per un'enumerazione degli argomenti di alto livello relativi alla migrazione della topologia di rete in Azure, vedere Topologie di rete del server applicazioni WebSphere.
  • Poiché le origini dati sono server separati in un sistema Liberty, è necessario considerarle come parte dell'analisi della topologia di rete. Per altre informazioni, vedere Origini dati Liberty del server applicazioni WebSphere.
  • Anche le origini di messaggistica sono server distinti. Per altre informazioni, vedere WebSphere Application Server Liberty: WebSphere MQ messaging(Libertà server applicazioni WebSphere: messaggistica MQ WebSphere).
  • Il bilanciamento del carico è un requisito fondamentale. Per informazioni sul lato Liberty del bilanciamento del carico, vedere Architettura collettiva webSphere Application Server Liberty.

Account per l'uso di adattatori JCA e adattatori di risorse

Se l'applicazione esistente usa adattatori JCA o adattatori di risorse per connettersi ad altri sistemi aziendali, assicurarsi di applicare la configurazione per questi artefatti al server Liberty in esecuzione su servizio Azure Kubernetes (servizio Azure Kubernetes). Per altre informazioni, vedere Panoramica degli elementi di configurazione JCA e Architettura del connettore Java.

Determinare se viene usato il clustering

L'operatore gestisce il clustering per tutti i modi possibili di esecuzione del carico di lavoro WAS nel servizio Azure Kubernetes.

Esaminare il clustering EJB

Se l'applicazione usa Java Beans (EJB) locale, potrebbe essere necessario eseguirne la migrazione a un EJB cluster. Per altre informazioni, vedere Sviluppo di applicazioni EJB in Liberty.

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.

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 IBM WebSphere Liberty e Open Liberty su servizio Azure Kubernetes. Selezionare Crea, quindi usare le informazioni raccolte nei passaggi precedenti per compilare i campi dell'offerta.

Tenere conto degli archivi chiavi

È necessario tenere conto della migrazione di tutti gli archivi chiavi SSL/TLS 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 Panoramica degli elementi di configurazione JCA nella documentazione di IBM.

Tenere conto della registrazione

Non è possibile eseguire il cloud senza la registrazione mastering. L'operatore fornisce approcci diversi per il monitoraggio. Per altre informazioni, vedere Monitoraggio dell'ambiente di runtime del server Liberty. Se si preferisce usare Elastic Stack, 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 Liberty nel servizio Azure Kubernetes.

Esegui la migrazione delle applicazioni

Indipendentemente dal fatto che si sia scelto di fornire un'immagine dell'applicazione in fase di distribuzione, è necessario aggiornare l'applicazione tramite CI/CD. La documentazione IBM include un esempio che illustra come eseguire questo aggiornamento. Per altre informazioni, vedere Distribuzione di applicazioni in Liberty.

Configurazione dei test

Per accedere ai nuovi server in esecuzione in Azure, è necessario configurare tutti i test in contenitori rispetto alle applicazioni. 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. Gli articoli seguenti forniscono informazioni sui miglioramenti post-migrazione: