Eseguire la migrazione di applicazioni Spring Boot a Azure Container Apps

Questa guida descrive gli elementi da tenere presenti quando si vuole eseguire la migrazione di un'applicazione Spring Boot esistente da eseguire in Azure Container 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 a contenitori in Azure Kubernetes Service (indicazioni pianificate)
• Eseguire la migrazione di applicazioni JAR eseguibili a Azure Virtual Machines (linee guida pianificate)

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:

• Nessun singleton può essere garantito di essere veramente single.
• È probabile che i dati non salvati su un supporto esterno vengano persi più rapidamente rispetto a quanto accadrebbe su un server fisico singolo o macchina virtuale.

Prima di eseguire la migrazione ad Azure Container Apps, controllare che il codice non contenga stati locali che non devono essere persi o duplicati. 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:

• Azure Cache for Redis
• Azure Cosmos DB
• Un altro database esterno, ad esempio Azure SQL, Azure Database for MySQL o Azure Database for PostgreSQL.
• Azure Storage, 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.

Azure Container Apps offre diversi tipi di archiviazione. L'archiviazione effimera può leggere e scrivere dati temporanei ed essere disponibile per un contenitore o una replica in esecuzione. Azure File fornisce una risorsa di archiviazione permanente e può essere condivisa tra più contenitori. Per altre informazioni, vedere Usare i montaggi di archiviazione in Azure Container Apps.

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 Azure Blob Storage e l'aggiunta di Azure CDN per download veloci a livello globale. Per altre informazioni, vedere Static website hosting in Azure Storage and Quickstart: Integrare un account Azure storage con Azure CDN.

Contenuto statico pubblicato dinamicamente

Se l'applicazione supporta contenuti statici, caricati o generati dall'applicazione stessa, che rimangono invariati dopo la sua creazione, è possibile integrare Azure Blob Storage e Azure CDN. È anche possibile usare una funzione Azure per gestire i caricamenti e attivare gli aggiornamenti della rete CDN quando necessario. È stata fornita un'implementazione di esempio per l'uso in Caricamento e precaricamento della rete CDN di contenuti statici con Azure Functions.

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 l'applicazione Dockerfile e si distribuisce un'applicazione in contenitori in Azure Container Apps, si assume il controllo completo sulla distribuzione, incluse le versioni JRE/JDK.

Per la distribuzione da elementi, Azure Container Apps 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 di tutto la migrazione dell'applicazione a una delle versioni supportate di Java nell'ambiente corrente, quindi procedere con i passaggi di migrazione rimanenti. Assicurarsi di testare completamente la configurazione risultante. Usare la versione stabile più recente della distribuzione Linux in questi test.

Per ottenere la versione corrente Java, accedere al server di produzione ed eseguire il comando seguente:

java -version

Per le versioni supportate di Java, Spring Boot e Spring Cloud, e per le istruzioni di aggiornamento, vedere Panoramica di Java su Azure Container Apps.

Determinare se l'applicazione si basa su attività pianificate

Un'applicazione temporanea, ad esempio processi cron Unix o applicazioni in tempo reale brevi basate sul framework Spring Batch, deve essere eseguita come processo in Azure Container Apps. Per altre informazioni, vedere Jobs in Azure Container Apps. Se l'applicazione è un'applicazione a esecuzione prolungata ed esegue regolarmente attività usando un framework di pianificazione, ad esempio Quarzi o Spring Batch, Azure Container Apps può ospitare tale applicazione. Tuttavia, l'applicazione deve gestire il ridimensionamento in modo appropriato per evitare le race condition in cui le stesse istanze dell'applicazione vengono eseguite più volte per il periodo pianificato durante un aumento del numero di istanze o l'aggiornamento progressivo.

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.

Intenditore

Nei progetti Maven, la versione di Spring Boot si trova in genere 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 si trova in genere nella plugins sezione, 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. ** Azure Container Apps non offre supporto integrato per l'integrazione con 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 Azure 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 è 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, le stringhe di connessione sono generalmente presenti nei file di configurazione quando dipende da un database esterno. Di seguito è riportato un esempio di 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

Di seguito è riportato un esempio di 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 di MongoDB

Broker di messaggi JMS

Identificare il broker o i broker in uso cercando nel file di configurazione del build (in genere, un pom.xml o build.gradle) che elenca le dipendenze pertinenti.

Ad esempio, un'applicazione Spring Boot che usa ActiveMQ in genere conterrà 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, trova le impostazioni corrispondenti. Nelle applicazioni Spring Boot è in genere possibile trovarli nei file application.properties e application.yml nella directory dell'applicazione.

Ecco un esempio di ActiveMQ da un file application.properties :

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 relativa alla messaggistica spring boot.

Ecco un esempio IBM MQ da un file application.yaml :

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 IBM MQ Spring.

Identificare le cache esterne

Identificare eventuali 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 Spring Session 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 le informazioni di riferimento su Spring Security.
• Per la configurazione di Spring Security di Auth0, vedere la documentazione di Auth0 Spring Security.
• Per la configurazione di PingFederate Spring Security, vedere le istruzioni Auth0 PingFederate.

Identificare i client che si basano su una porta non standard

Azure Container Apps consente di esporre la porta in base alla configurazione delle risorse Azure Container Apps. 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 è in genere possibile trovare tali stringhe nel file application.properties o application.yml .

Certificati di inventario

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 disponibilità operativa e l'Accordo sul Livello di Servizio (SLA) per le applicazioni che si sta migrando.

Migrazione

Creare un ambiente Azure Container Apps e distribuire le app

Effettuare il provisioning di un'istanza di Azure Container Apps nella sottoscrizione di Azure. Il suo ambiente di hosting sicuro viene creato insieme a esso. Per altre informazioni, vedere Quickstart: 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 Azure Container Apps, è possibile configurare le opzioni di registrazione nell'ambiente App contenitore per definire una o più destinazioni dei log. Queste destinazioni possono includere Azure Monitor Log Analytics, Azure Hub eventi 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 Log storage and monitoring options in Azure Container Apps.For detailed configuration instruction, see Log storage and monitoring options in Azure Container Apps.

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 in Azure Container Apps.

Eseguire la migrazione di tutti i certificati a Key Vault

Azure Container Apps supporta la comunicazione sicura tra le app. L'applicazione non deve gestire il processo di stabilire comunicazioni sicure. È possibile caricare il certificato privato in Azure Container Apps o usare un certificato gestito gratuito fornito da Azure Container Apps. L'uso di Azure Key Vault per gestire i certificati è un approccio consigliato. Per altre informazioni, vedere Certificates in Azure Container Apps.

Configurare le integrazioni di APM (Application Performance Management)

Indipendentemente dal fatto che l'app venga distribuita da un'immagine del contenitore o dal codice, Azure Container Apps non interferisce 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, Azure Application Insights è un'opzione. Per altre informazioni, vedere Using Azure Monitor Application Insights 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 Deploy Azure Container Apps 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 Azure Container Apps.

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 on-premises, considerare l'implementazione di una soluzione di identità ibrida 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, è consigliabile usare Spring Security per usare il provider di identità tramite OAuth2/OpenID Connect o SAML.

Esporre l'applicazione

Per impostazione predefinita, un'applicazione distribuita in Azure Container Apps è 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 Networking in Azure Container Apps environment.

Fase 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 Azure Container Apps. Modificare quindi tutti i client dell'applicazione in modo che usino il Load Balancer Spring Client. 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 funzioni 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 Azure Container Apps. 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 Azure Container Apps. 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-tua-applicazione>.yml , dove your-application-name è lo stesso del passaggio precedente. Spostare le impostazioni dal file application.yml in src/main/resources al nuovo file creato. Se le impostazioni erano in precedenza in un file con estensione properties , convertirle prima 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 Azure Container Apps. Tali impostazioni includono in genere origini dati, impostazioni di registrazione, configurazione di Spring Boot Actuator e altro ancora.

  4. Effettua 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 gestito da Spring Admin per abilitare un'interfaccia amministrativa per le applicazioni web Spring Boot che espongono endpoint dell'actuator. Per altre informazioni, vedere Configurare il componente di amministrazione di Spring Boot in Azure Container Apps.

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

• Considera l'uso delle revisioni delle app container, delle etichette di revisione e dei pesi del traffico in ingresso per abilitare l'implementazione blue-green, che consente di testare le modifiche del codice nell'ambiente di produzione prima che siano disponibili per alcuni o per tutti gli utenti finali. Per altre informazioni, vedere Blue-Green Deployment in Azure Container Apps.

• Prendere in considerazione l'aggiunta di associazioni di servizi per connettere l'applicazione ai database 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 ulteriori informazioni, consultare le metriche Java per le app Java in Azure Container Apps.

• È consigliabile aggiungere Azure Monitor regole di avviso e gruppi di azioni per rilevare e risolvere rapidamente le condizioni aberranti. Per altre informazioni, vedere Impostare gli avvisi in Azure Container Apps.

• Considerare la possibilità di replicare l'app attraverso le zone della regione abilitando la ridondanza tra zone di Azure Container Apps. Il traffico viene bilanciato e indirizzato automaticamente alle repliche se si verifica un'interruzione della zona. Per altre informazioni sulle impostazioni ridondanti, vedere Reliability in Azure Container Apps.

• Valutare la possibilità di proteggere Azure Container Apps da exploit e vulnerabilità comuni usando Web Application Firewall nel gateway applicazione. Per altre informazioni, vedere Protect Azure Container Apps con Web Application Firewall su Application Gateway.