Eseguire la migrazione di applicazioni Spring Boot ad App Azure Container

Articolo
10/01/2024

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.

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 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:
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 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.
3. 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.
4. Eseguire il commit e il push delle modifiche nel repository Git.
5. 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.

Condividi tramite