Eseguire la migrazione di applicazioni Spring Boot ad App Azure Container
Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione Spring Boot esistente per l'esecuzione in App Contenitore di Azure.
Pre-migrazione
Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.
Se non è possibile soddisfare i requisiti di pre-migrazione, vedere le guide alla migrazione complementari seguenti:
- Eseguire la migrazione di applicazioni JAR eseguibili ai contenitori nel servizio Azure Kubernetes (indicazioni in pianificazione)
- Eseguire la migrazione di applicazioni JAR eseguibili alle macchine virtuali di Azure (indicazioni in pianificazione)
Esaminare i componenti dell'applicazione
Identificare lo stato locale
Negli ambienti PaaS, non è garantito che un'applicazione venga eseguita esattamente una volta in un determinato momento. Anche se si configura un'applicazione per l'esecuzione in una singola istanza, è possibile che venga creata un'istanza duplicata nei casi seguenti:
- L'applicazione deve essere riallocata in un host fisico a causa di un errore o di un aggiornamento di sistema.
- L'applicazione viene aggiornata.
In uno di questi casi, l'istanza originale rimane in esecuzione fino al termine dell'avvio della nuova istanza. Questo modello può avere le implicazioni potenzialmente significative seguenti per l'applicazione:
- Non è possibile garantire che un singleton sia effettivamente singolo.
- È probabile che tutti i dati non salvati in modo permanente all'esterno dell'archiviazione andranno persi prima che si trovassero in un singolo server fisico o macchina virtuale.
Prima di eseguire la migrazione ad App Contenitore di Azure, assicurarsi che il codice non contenga lo stato locale che non deve essere perso o duplicato. Se lo stato locale esiste, cambiare il codice per archiviarlo all'esterno dell'applicazione. Le applicazioni pronte per il cloud archiviano in genere lo stato dell'applicazione in posizioni come le opzioni seguenti:
- Cache Redis di Azure
- Azure Cosmos DB
- Un altro database esterno, ad esempio SQL di Azure, Database di Azure per MySQL o Database di Azure per PostgreSQL.
- Archiviazione di Azure, usato per archiviare dati non strutturati o persino oggetti serializzati.
Determinare se e come viene usato il file system
Trovare tutte le istanze in cui i servizi eseguono la scrittura e/o la lettura dal file system locale. Identificare la posizione in cui vengono scritti e letti i file a breve termine/temporanei e i file di lunga durata.
App Azure Container offre diversi tipi di archiviazione. L'archiviazione temporanea può leggere e scrivere dati temporanei ed essere disponibile per un contenitore o una replica in esecuzione. File di Azure offre un'archiviazione permanente e può essere condivisa tra più contenitori. Per altre informazioni, vedere Usare i montaggi di archiviazione nelle app contenitore di Azure.
Contenuto statico di sola lettura
Se l'applicazione attualmente serve contenuto statico, è necessario un percorso alternativo. È possibile prendere in considerazione lo spostamento di contenuto statico in Archiviazione BLOB di Azure e l'aggiunta di Rete CDN di Azure per download veloci 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 supporta contenuti statici, caricati o generati dall'applicazione stessa, che rimangono invariati dopo la creazione, è possibile integrare Archiviazione BLOB di Azure e Rete CDN di Azure. È anche possibile usare una funzione di Azure per gestire i caricamenti e attivare gli aggiornamenti della rete CDN quando necessario. Nell'articolo Caricamento e precaricamento nella rete CDN di contenuto statico con Funzioni di Azure è riportata un'implementazione di esempio che è possibile usare.
Determinare se uno dei servizi 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.
Passare a una piattaforma supportata
Se si crea manualmente il Dockerfile e si distribuisce un'applicazione in contenitori in App Azure Container, si assume il controllo completo sulla distribuzione, incluse le versioni JRE/JDK.
Per la distribuzione da elementi, App Azure Container offre anche versioni specifiche di Java (8, 11, 17 e 21) e versioni specifiche dei componenti Spring Boot e Spring Cloud. Per garantire la compatibilità, eseguire prima la migrazione dell'applicazione a una delle versioni supportate di Java nell'ambiente corrente e quindi procedere con i passaggi rimanenti della migrazione. Assicurarsi di testare completamente la configurazione risultante. Usare la versione stabile più recente della distribuzione Linux in questi test.
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
Per le versioni supportate di Java, Spring Boot e Spring Cloud, nonché istruzioni per l'aggiornamento, vedere Panoramica di Java in App contenitore di Azure.
Determinare se l'applicazione si basa su processi pianificati
Un'applicazione temporanea, ad esempio processi cron Unix o applicazioni brevi basate su Spring Batch Framework, deve essere eseguita come processo nelle app contenitore di Azure. Per altre informazioni, vedere Processi in App Azure Container. Se l'applicazione è un'applicazione a esecuzione prolungata ed esegue regolarmente attività usando un framework di pianificazione, ad esempio Quarzi o Spring Batch, App Contenitore di Azure può ospitare tale applicazione. Tuttavia, l'applicazione deve gestire il ridimensionamento in modo appropriato per evitare race condition in cui le stesse istanze dell'applicazione vengono eseguite più volte per periodo pianificato durante l'aumento del numero di istanze o l'aggiornamento in sequenza.
Eseguire l'inventario di tutte le attività pianificate in esecuzione nei server di produzione, all'interno o all'esterno del codice dell'applicazione.
Identificare le versioni di Spring Boot
Esaminare le dipendenze di ogni applicazione di cui viene eseguita la migrazione per determinare la versione di Spring Boot.
Maven
Nei progetti Maven la versione di Spring Boot è in genere disponibile nell'elemento <parent>
del file POM:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.3.3</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
Gradle
Nei progetti Gradle la versione di Spring Boot è in genere disponibile nella sezione plugins
, come versione del plug-in org.springframework.boot
:
plugins {
id 'org.springframework.boot' version '3.3.3'
id 'io.spring.dependency-management' version '1.1.6'
id 'java'
}
Per tutte le applicazioni che usano le versioni di Spring Boot precedenti alla versione 3.x, seguire la guida alla migrazione di Spring Boot 2.0 o la Guida alla migrazione di Spring Boot 3.0 per aggiornarli a una versione di Spring Boot supportata. Per le versioni supportate, vedere le versioni di Spring Boot e Spring Cloud.
Identificare le soluzioni di aggregazione dei log
Identificare le soluzioni di aggregazione dei log in uso dalle applicazioni di cui si esegue la migrazione. È necessario configurare le impostazioni di diagnostica nella migrazione per rendere disponibili gli eventi registrati per l'utilizzo. Per altre informazioni, vedere La sezione Verificare la registrazione della console e configurare le impostazioni di diagnostica.
Identificare gli agenti di gestione delle prestazioni delle applicazioni
Identificare gli agenti di gestione delle prestazioni delle applicazioni usati dalle applicazioni. Le app per contenitori di Azure non offrono il supporto predefinito per l'integrazione di APM. È necessario preparare l'immagine del contenitore o integrare lo strumento APM direttamente nel codice. Se si vuole misurare le prestazioni dell'applicazione ma non è ancora integrato alcun APM, è consigliabile usare app Azure lication Insights. Per altre informazioni, vedere la sezione Migrazione .
Inventario delle risorse esterne
Identificare le risorse esterne, ad esempio le origini dati, i broker dei messaggi JMS e gli URL di altri servizi. Nelle applicazioni Spring Boot è in genere possibile trovare la configurazione per tali risorse nella cartella src/main/resources , in un file denominato in genere application.properties o application.yml.
Database
Per un'applicazione Spring Boot, stringa di connessione in genere vengono visualizzati nei file di configurazione quando dipende da un database esterno. Ecco un esempio di un file application.properties:
spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
Ecco un esempio di un file application.yaml:
spring:
data:
mongodb:
uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017
Vedere la documentazione di Spring Data per altri scenari possibili di configurazione:
Broker di messaggi JMS
Identificare i broker in uso cercando nel manifesto di compilazione, in genere, un file pom.xml o build.gradle, per le dipendenze pertinenti.
Ad esempio, un'applicazione Spring Boot che usa ActiveMQ in genere contiene questa dipendenza nel relativo file pom.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-activemq</artifactId>
</dependency>
Le applicazioni Spring Boot che usano broker commerciali in genere contengono dipendenze direttamente dalle librerie di driver JMS dei broker. Ecco un esempio di un file build.gradle:
dependencies {
...
compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
...
}
Dopo aver identificato i broker in uso, trovare le impostazioni corrispondenti. Nelle applicazioni Spring Boot si trovano in genere nei file application.properties e application.yml nella directory dell'applicazione.
Nota
Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Il flusso di autenticazione descritto in questa procedura, ad esempio per database, cache, messaggistica o servizi di intelligenza artificiale, richiede un livello di attendibilità molto elevato nell'applicazione e comporta rischi non presenti in altri flussi. Usare questo flusso solo quando le opzioni più sicure, ad esempio le identità gestite per le connessioni senza password o senza chiave, non sono valide. Per le operazioni del computer locale, preferire le identità utente per le connessioni senza password o senza chiave.
Ecco un esempio di un file application.properties per ActiveMQ:
spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>
Per altre informazioni sulla configurazione di ActiveMQ, vedere la documentazione sulla messaggistica di Spring Boot.
Ecco un esempio di un file application.yaml per IBM MQ:
ibm:
mq:
queueManager: qm1
channel: dev.ORDERS
connName: localhost(14)
user: admin
password: <password>
Per altre informazioni sulla configurazione di IBM MQ, vedere la documentazione relativa ai componenti Spring di IBM MQ.
Identificare le cache esterne
Identificare le cache esterne in uso. Spesso, Redis viene usato tramite Spring Data Redis. Per informazioni sulla configurazione, vedere la documentazione di Spring Data Redis.
Determinare se i dati della sessione vengono memorizzati nella cache tramite una sessione Spring cercando la rispettiva configurazione (in Java o XML).
Provider di identità
Identificare tutti i provider di identità usati dall'applicazione. Per informazioni su come configurare i provider di identità, consultare gli argomenti seguenti:
- Per la configurazione di OAuth2, vedere la guida le informazioni di riferimento per Spring Security.
- Per la configurazione di Auth0 Spring Security, vedere la documentazione di Auth0 Spring Security.
- Per la configurazione della sicurezza di PingFederate Spring Security, vedere le istruzioni di Auth0 PingFederate.
Identificare i client che si basano su una porta non standard
App Azure Container consente di esporre la porta in base alla configurazione delle risorse di App Contenitore di Azure. Ad esempio, un'applicazione Spring Boot è in ascolto della porta 8080 per impostazione predefinita, ma può essere impostata con server.port
o variabile SERVER_PORT
di ambiente in base alle esigenze.
Tutte le altre risorse esterne
Non è possibile documentare tutte le possibili dipendenze esterne in questa guida. Dopo la migrazione, è responsabilità dell'utente verificare che sia possibile soddisfare tutte le dipendenze esterne dell'applicazione.
Segreti e origini della configurazione dell'inventario
Password e stringhe sicure dell'inventario
Controllare tutte le proprietà e i file di configurazione e tutte le variabili di ambiente nei server di produzione per verificare la presenza di stringhe segrete e password. In un'applicazione Spring Boot tali stringhe si trovano in genere nel file application.properties o application.yml.
Inventario dei certificati
Documentare tutti i certificati usati per gli endpoint SSL pubblici o per la comunicazione con i database back-end e altri sistemi. È possibile visualizzare tutti i certificati nei server di produzione eseguendo il comando seguente:
keytool -list -v -keystore <path to keystore>
Esaminare l'architettura di distribuzione
Documentare i requisiti hardware per ogni servizio
Documentare le informazioni seguenti per l'applicazione Spring Boot:
- Numero di istanze in esecuzione.
- Numero di CPU allocate a ogni istanza.
- Quantità di RAM allocata a ogni istanza.
Documentare la replica geografica/distribuzione
Determinare se le istanze dell'applicazione Spring Boot sono attualmente distribuite tra più aree o data center. Documentare i requisiti di tempo di attività/contratto di servizio per le applicazioni di cui si intende eseguire la migrazione.
Migrazione
Creare un ambiente di App Azure Container e distribuire le app
Effettuare il provisioning di un'istanza di App Contenitore di Azure nella sottoscrizione di Azure. Il suo ambiente di hosting sicuro viene creato insieme a esso. Per altre informazioni, vedere Avvio rapido: Distribuire la prima app contenitore usando il portale di Azure.
Verificare la registrazione della console e configurare le impostazioni di diagnostica
Configurare la registrazione per assicurarsi che tutto l'output venga indirizzato alla console anziché ai file.
Dopo la distribuzione di un'applicazione in App Contenitore di Azure, è possibile configurare le opzioni di registrazione all'interno dell'ambiente App contenitore per definire una o più destinazioni dei log. Queste destinazioni possono includere Log Analytics di Monitoraggio di Azure, Hub eventi di Azure o anche altre soluzioni di monitoraggio di terze parti. È anche possibile disabilitare i dati di log e visualizzare i log solo in fase di esecuzione. Per istruzioni dettagliate sulla configurazione, vedere Opzioni di archiviazione e monitoraggio dei log in App Azure Container.
Configurare la risorsa di archiviazione persistente
Se una parte dell'applicazione legge o scrive nel file system locale, è necessario configurare l'archiviazione permanente per sostituire il file system locale. È possibile specificare il percorso da montare nel contenitore tramite le impostazioni dell'app e allinearlo al percorso usato dall'app. Per altre informazioni, vedere Usare i montaggi di archiviazione nelle app contenitore di Azure.
Eseguire la migrazione di tutti i certificati a Key Vault
App contenitori di Azure supporta la comunicazione sicura tra app. L'applicazione non deve gestire il processo di stabilire comunicazioni sicure. È possibile caricare il certificato privato in App Azure Container o usare un certificato gestito gratuito fornito da App Azure Container. L'uso di Azure Key Vault per gestire i certificati è un approccio consigliato. Per altre informazioni, vedere Certificati nelle app Azure Container.
Configurare le integrazioni di APM (Application Performance Management)
Indipendentemente dal fatto che l'app venga distribuita da un'immagine del contenitore o dal codice, le app contenitore di Azure non interferiscono con l'immagine o il codice. Pertanto, l'integrazione dell'applicazione con uno strumento APM dipende dalle proprie preferenze e implementazione.
Se l'applicazione non usa un APM supportato, app Azure lication Insights è un'opzione. Per altre informazioni, vedere Uso di Application Insights di Monitoraggio di Azure con Spring Boot.
Distribuire l'applicazione
Distribuire ognuno dei microservizi migrati (non incluso Spring Cloud Config Server e Spring Cloud Service Registry), come descritto in Distribuire app di Azure Container con il comando az containerapp up.
Configurare i segreti per servizio e le impostazioni esternalizzate
È possibile inserire le impostazioni di configurazione in ogni applicazione come variabili di ambiente. È possibile impostare queste variabili come voci manualmente o come riferimenti ai segreti. Per altre informazioni sulla configurazione, vedere Gestire le variabili di ambiente in App Azure Container.
Eseguire la migrazione e abilitare il provider di identità
Se le applicazioni Spring Cloud richiedono l'autenticazione o l'autorizzazione, assicurarsi che siano configurate per l'accesso al provider di identità:
- Se il provider di identità è Microsoft Entra ID, non è necessario apportare modifiche.
- Se il provider di identità è una foresta Active Directory locale, prendere in considerazione l'implementazione di una soluzione ibrida di gestione delle identità con Microsoft Entra ID. Per altre informazioni, vedere la documentazione delle identità ibride.
- Se il provider di identità è un'altra soluzione locale, ad esempio PingFederate, consultare l'argomento Installazione personalizzata di Microsoft Entra Connect per configurare la federazione con Microsoft Entra ID. In alternativa, valutare l'uso di Spring Security per usare il provider di identità personalizzato tramite OAuth2/OpenID Connect o SAML.
Esporre l'applicazione
Per impostazione predefinita, un'applicazione distribuita in App Azure Container è accessibile tramite un URL dell'applicazione. Se l'app viene distribuita nel contesto di un ambiente gestito con la propria rete virtuale, è necessario determinare il livello di accessibilità dell'app per consentire l'ingresso pubblico o l'ingresso solo dalla rete virtuale. Per altre informazioni, vedere Reti nell'ambiente App contenitore di Azure.
Post-migrazione
Ora che è stata completata la migrazione, verificare che l'applicazione funzioni come previsto. È quindi possibile rendere l'applicazione maggiormente nativa del cloud seguendo queste raccomandazioni.
Valutare se consentire l'uso dell'applicazione con Spring Cloud Registry. Questo componente consente all'applicazione di essere individuata dinamicamente da altre applicazioni e client Spring distribuiti. Per altre informazioni, vedere Configurare le impostazioni per il componente Eureka Server for Spring in App Azure Container. Modificare quindi tutti i client dell'applicazione per usare Spring Client Load Balancer. Spring Client Load Balancer consente al client di ottenere gli indirizzi di tutte le istanze in esecuzione dell'applicazione e di trovare un'istanza che funziona se un'altra istanza viene danneggiata o non risponde. Per altre informazioni, vedere Spring Tips: Spring Cloud Load Balancer nel blog di Spring.
Invece di rendere pubblica l'applicazione, è consigliabile aggiungere un'istanza di Spring Cloud Gateway. Spring Cloud Gateway offre un singolo endpoint per tutte le applicazioni distribuite nell'ambiente App Azure Container. Se Spring Cloud Gateway è già distribuito, assicurarsi che una regola di routing sia configurata per instradare il traffico all'applicazione appena distribuita.
Prendere in considerazione l'aggiunta di un server di configurazione Spring Cloud per gestire centralmente e controllare la configurazione del controllo della versione per tutte le applicazioni Spring Cloud. Creare prima di tutto un repository Git per ospitare la configurazione e configurare l'istanza dell'app per usarla. Per altre informazioni, vedere Configurare le impostazioni per il componente Config Server for Spring in App Azure Container. Eseguire quindi la migrazione della configurazione seguendo questa procedura:
All'interno della directory src/main/resources dell'applicazione creare un file bootstrap.yml con il contenuto seguente:
spring: application: name: <your-application-name>
Nel repository Git di configurazione creare un <file nome-applicazione>.yml , dove
your-application-name
corrisponde a quello del passaggio precedente. Spostare le impostazioni dal file application.yml in src/main/resources al nuovo file creato. Se le impostazioni si trovavano in precedenza in un file con estensione properties, dovranno prima essere convertite in YAML. Per eseguire questa conversione, è possibile trovare gli strumenti online o i plug-in IntelliJ.Creare un file application.yml nella directory precedente. È possibile usare questo file per definire le impostazioni e le risorse condivise tra tutte le applicazioni nell'ambiente App Azure Container. Tali impostazioni includono in genere origini dati, impostazioni di registrazione, configurazione di Spring Boot Actuator e altro ancora.
Eseguire il commit e il push delle modifiche nel repository Git.
Rimuovere il file application.properties o application.yml dall'applicazione.
Prendere in considerazione l'aggiunta del componente Amministratore per Spring gestito per abilitare un'interfaccia amministrativa per le applicazioni Web Spring Boot che espongono endpoint dell'attuatore. Per altre informazioni, vedere Configurare il componente di amministrazione di Spring Boot nelle app contenitore di Azure.
Valutare la possibilità di aggiungere una pipeline di distribuzione per distribuzioni automatiche e coerenti. Le istruzioni sono disponibili per Azure Pipelines e per GitHub Actions.
Prendere in considerazione l'uso di revisioni, etichette di revisione e pesi del traffico in ingresso per abilitare la distribuzione blu-verde, che consente di testare le modifiche del codice nell'ambiente di produzione prima che vengano rese disponibili ad alcuni o a tutti gli utenti finali. Per altre informazioni, vedere Distribuzione blu-verde nelle app contenitore di Azure.
Valutare la possibilità di aggiungere associazioni a servizi per connettere l'applicazione ai database di Azure supportati. Queste associazioni a servizi elimineranno la necessità di fornire le informazioni di connessione, incluse le credenziali, alle applicazioni Spring Cloud.
Valutare la possibilità di abilitare lo stack di sviluppo Java per raccogliere le metriche di base di JVM per le applicazioni. Per altre informazioni, vedere Metriche Java per le app Java in App Contenitore di Azure.
Valutare la possibilità di aggiungere regole di avviso e gruppi di azioni di Monitoraggio di Azure per rilevare rapidamente e risolvere le condizioni anomale. Per altre informazioni, vedere Configurare gli avvisi in App Azure Container.
Valutare la possibilità di replicare l'app tra le zone nell'area abilitando la ridondanza della zona di App Contenitore di Azure. Il traffico viene bilanciato e indirizzato automaticamente alle repliche se si verifica un'interruzione della zona. Per altre informazioni sulle impostazioni ridondanti, vedere Affidabilità nelle app contenitore di Azure.
Valutare la possibilità di proteggere le app contenitore di Azure da exploit e vulnerabilità comuni usando Web Application Firewall in gateway applicazione. Per altre informazioni, vedere Proteggere le app di Azure Container con Web Application Firewall in gateway applicazione.