Eseguire la migrazione di applicazioni Spring Boot ad Azure Spring Apps

Nota

Azure Spring Apps è il nuovo nome del servizio Azure Spring Cloud. Anche se il servizio ha un nuovo nome, il nome precedente verrà visualizzato in alcune posizioni per un po' mentre si lavora per aggiornare gli asset, ad esempio screenshot, video e diagrammi.

Questa guida descrive gli aspetti da tenere presenti quando si vuole eseguire la migrazione di un'applicazione Spring Boot esistente da eseguire in Azure Spring Apps.

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 rimarrà in esecuzione fino al completamento dell'avvio della nuova istanza. Questo comportamento presenta implicazioni potenzialmente significative per l'applicazione:

• Non è possibile garantire che un singleton sia effettivamente singolo.
• Tutti i dati che non sono stati salvati in modo permanente in un archivio esterno andranno probabilmente persi molto prima rispetto a quanto avverrebbe in un singolo server fisico o in una VM.

Prima di eseguire la migrazione ad Azure Spring Apps, 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. Lo stato delle applicazioni predisposte per il cloud viene in genere archiviato in posizioni come le 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.

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.

Nota

Azure Spring Apps offre 5 GB di archiviazione temporanea per ogni istanza di Azure Spring Apps, montata in /tmp. Se viene eseguita la scrittura di un numero di file temporanei in eccesso rispetto a tale limite o in un percorso diverso, sarà necessario apportare modifiche al codice.

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 se uno dei servizi 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.

Passare a una piattaforma supportata

Azure Spring Apps offre versioni specifiche di Java e versioni specifiche di 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 Preparare un'applicazione per la distribuzione in Azure Spring Apps.

Determinare se l'applicazione si basa su processi pianificati

I processi pianificati, ad esempio le attività dell'utilità di pianificazione di Quarzi o i processi Unix cron, non devono essere usati con Azure Spring Apps. Azure Spring Apps non impedisce la distribuzione di un'applicazione contenente attività pianificate internamente. Tuttavia, se l'applicazione viene ampliata, lo stesso processo pianificato può essere eseguito più di una volta per ogni periodo pianificato. Questa situazione può provocare conseguenze indesiderate.

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>2.7.10</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 '2.7.10'
  id 'io.spring.dependency-management' version '1.0.15.RELEASE'
  id 'java'
}

Per tutte le applicazioni che usano Spring Boot 1.x, seguire la Guida alla migrazione di Spring Boot 2.0 per aggiornarle a una versione di Spring Boot supportata. Per le versioni supportate, vedere la sezione Versioni di Spring Boot e Spring Cloud di Preparare un'applicazione per la distribuzione in Azure Spring Apps.

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 monitoraggio delle prestazioni delle applicazioni in uso con le applicazioni. Azure Spring Apps supporta l'integrazione con Application Insights, New Relic, Elastic APM, Dynatrace e AppDynamics. Se l'applicazione usa un APM supportato, configurare l'integrazione nella migrazione. Se l'applicazione non usa un modulo APM supportato, prendere in considerazione l'uso di Application 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 la configurazione per tali risorse si trova di solito nella cartella src/main/directory, in un file generalmente denominato application.properties o application.yml.

Database

Per qualsiasi database SQL, identificare la stringa di connessione.

Per un'applicazione Spring Boot, le stringhe di connessione sono in genere incluse nei file di configurazione.

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:

• Repository JPA
• Repository JDBC
• Repository Cassandra
• Repository MongoDB

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.0.4.0")
      ...
    }

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.

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=tryandguess

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: big$ecr3t

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 Spring di Azure sovrascrive l'impostazione server.port nell'applicazione distribuita. Se eventuali client dipendono dalla disponibilità dell'applicazione su una porta diversa da 443, sarà necessario modificarli.

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'istanza e app di Azure Spring Apps

Effettuare il provisioning di un'istanza di Azure Spring Apps nella sottoscrizione di Azure, se non ne esiste già una. Quindi, crearvi un'applicazione. Per altre informazioni, vedere Avvio rapido: Distribuire la prima applicazione in Azure Spring Apps.

Verificare la registrazione della console e configurare le impostazioni di diagnostica

Configurare la registrazione in modo che tutto l'output venga instradato alla console e non ai file.

Dopo la distribuzione di un'applicazione in Azure Spring Apps, aggiungere un'impostazione di diagnostica per rendere disponibili gli eventi registrati per l'utilizzo, ad esempio tramite Monitoraggio di Azure Log Analytics.

Stack LogStash/ELK

Se si usa lo stack LogStash/ELK per l'aggregazione dei log, configurare l'impostazione di diagnostica per trasmettere l'output della console a un'istanza di Hub eventi di Azure. Usare quindi il plug-in LogStash EventHub per inserire gli eventi registrati in LogStash.

Splunk

Se si usa Splunk per l'aggregazione dei log, configurare l'impostazione di diagnostica per trasmettere l'output della console ad Archiviazione BLOB di Azure. Usare quindi il componente aggiuntivo Splunk per servizi cloud Microsoft per inserire gli eventi registrati in Splunk.

Configurare la risorsa di archiviazione persistente

Se una parte dell'applicazione legge o scrive nel file system locale, sarà necessario configurare l'archiviazione persistente in modo da sostituire il file system locale. Per altre informazioni, vedere Usare l'archiviazione permanente predefinita in Azure Spring Apps.

È consigliabile scrivere tutti i file temporanei nella directory /tmp. Per l'indipendenza del sistema operativo, è possibile accedere a questa directory usando System.getProperty("java.io.tmpdir"). È anche possibile usare java.nio.Files::createTempFile per creare file temporanei.

Eseguire la migrazione di tutti i certificati a Key Vault

Azure Spring Apps non fornisce l'accesso all'archivio chiavi JRE, quindi è necessario eseguire la migrazione dei certificati ad Azure KeyVault e modificare il codice dell'applicazione per accedere ai certificati in KeyVault. Per altre informazioni, vedere Introduzione ai certificati Key Vault e Libreria client dei certificati di Azure Key Vault per Java.

Configurare le integrazioni di APM (Application Performance Management)

Azure Spring Apps offre le integrazioni APM seguenti. Seguire i collegamenti per abilitare il servizio APM necessario.

• Application Insights Java In-Process Agent
• Agente Java APM elastico
• Dynatrace Java OneAgent
• AppDynamics Java Agent
• Agente Java di New Relic

Se l'applicazione non usa un modulo APM supportato, prendere in considerazione l'uso di Application Insights. Azure Spring Apps offre un'integrazione approfondita con Application Insights per la gestione delle prestazioni e la risposta in tempo reale alle aberrazioni.

Disabilitare i client e gli endpoint delle metriche nelle applicazioni

Rimuovere tutti i client o gli endpoint delle metriche esposti nelle applicazioni.

Distribuire l'applicazione

Distribuire ognuno dei microservizi migrati (non inclusi i server Spring Cloud Config e Registry), come descritto in Avvio rapido: Distribuire la prima applicazione in Azure Spring Apps.

Configurare i segreti per servizio e le impostazioni esternalizzate

È possibile inserire tutte le impostazioni di configurazione per servizio in ogni servizio come variabili di ambiente. Nel portale di Azure seguire questa procedura:

1. Passare all'istanza di App Spring di Azure e selezionare App.
2. Selezionare il servizio da configurare.
3. Seleziona Configurazione.
4. Immettere le variabili da configurare.
5. Seleziona Salva.

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 Connessione 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, le applicazioni distribuite in Azure Spring Apps non sono visibili esternamente. È possibile esporre l'applicazione rendendola pubblica con il comando seguente:

az spring app update --name <application name> --is-public true

Ignorare questo passaggio se si usa o si intende usare Spring Cloud Gateway. Per ulteriori informazioni, vedere la seguente sezione:

Dopo la 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. In questo modo l'applicazione verrà individuata dinamicamente da altre applicazioni e client Spring distribuiti. Per altre informazioni, vedere Preparare un'applicazione per la distribuzione in Azure Spring Apps. Modificare quindi tutti i client dell'applicazione per l'uso del servizio di bilanciamento del carico del client Spring. In questo modo il client può ottenere gli indirizzi di tutte le istanze in esecuzione dell'applicazione e trovare un'istanza che funziona se un'altra istanza viene danneggiata o non risponde. Per altre informazioni, vedere Spring Suggerimenti: 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'istanza di Azure Spring Apps. Se Spring Cloud Gateway è già stato distribuito, assicurarsi che sia configurato 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 di Azure Spring Apps per usarla. Per altre informazioni, vedere Configurare un'istanza di Spring Cloud Config Server per il servizio. Eseguire quindi la migrazione della configurazione seguendo questa procedura:

  1. All'interno della directory src/main/resources dell'applicazione creare un file bootstrap.yml con il contenuto seguente:

       spring:
         application:
           name: <your-application-name>
     

  2. Nel repository Git di configurazione creare un <file your-application-name.yml>, dove your-application-name è uguale a quello del passaggio precedente. Spostare le impostazioni dal file application.yml in src/main/resources nel nuovo file appena 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.

  3. Creare un file application.yml nella directory precedente. È possibile usare questo file per definire le impostazioni e le risorse che verranno condivise tra tutte le applicazioni nell'istanza di Azure Spring Apps. Tali impostazioni includono in genere origini dati, impostazioni di registrazione, configurazione di Spring Boot Actuator e altro ancora.

  4. Eseguire il commit e il push delle modifiche nel repository Git.

  5. Rimuovere il file application.properties o application.yml dall'applicazione.

• Valutare la possibilità di aggiungere una pipeline di distribuzione per distribuzioni automatiche e coerenti. Sono disponibili istruzioni per Azure Pipelines, per GitHub Actions e per Jenkins.

• Provare a usare le distribuzioni di staging per testare le modifiche del codice in produzione prima che siano disponibili per alcuni o tutti gli utenti finali. Per altre informazioni, vedere Configurare un ambiente di gestione temporanea in Azure Spring Apps.

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

• È consigliabile usare app Azure lication Insights per monitorare le prestazioni e le interazioni delle applicazioni. Per altre informazioni, vedere Application Insights Java In-Process Agent in Azure Spring Apps.

• 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 Esercitazione: Monitorare le risorse di Spring Cloud usando avvisi e gruppi di azioni.

• Valutare la possibilità di replicare la distribuzione di Azure Spring Apps in un'altra area per ridurre la latenza e maggiore affidabilità e tolleranza di errore. Usare Gestione traffico di Azure per bilanciare il carico tra le distribuzioni o usare Frontdoor di Azure per aggiungere l'offload SSL e Web Application Firewall con protezione DDoS.

• Se la replica geografica non è necessaria, è consigliabile aggiungere un gateway applicazione di Azure per aggiungere l'offload SSL e Web Application Firewall con protezione DDoS.