Condividi tramite

Eseguire la migrazione di applicazioni Spring Boot a Azure App Service

Questa guida descrive gli elementi da tenere presenti quando si vuole eseguire la migrazione di un'applicazione Spring Boot esistente a Azure App Service.

Prima della migrazione

Per garantire una corretta migrazione, prima di iniziare completare i passaggi di valutazione e inventario descritti nelle sezioni seguenti.

Passare a una piattaforma supportata

Il servizio app offre versioni specifiche di Java SE. Per garantire la compatibilità, eseguire la migrazione dell'applicazione a una delle versioni supportate dell'ambiente corrente prima di continuare con uno dei passaggi rimanenti. Assicurarsi di testare completamente la configurazione risultante. Usare la versione stabile più recente della distribuzione Linux in questi test.

Annotazioni

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 Java, accedere al server di produzione ed eseguire il comando seguente:

java -version

In Azure App Service, i file binari per Java 8 vengono forniti da EclipseTemo. Per Java 11, 17 e tutte le future versioni LTS di Java, il servizio app fornisce il Microsoft Build of OpenJDK. Questi file binari sono disponibili gratuitamente per il download nei siti seguenti:

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/directory , in un file denominato in genere application.properties o application.yml. Controllare inoltre le variabili di ambiente della distribuzione di produzione per eventuali impostazioni di configurazione pertinenti.

Banche dati

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:

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.

Annotazioni

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

Fornitori di identità

Identificare tutti i provider di identità usati dall'applicazione. Per informazioni su come configurare i provider di identità, consultare gli argomenti seguenti:

Tutte le altre risorse esterne

Non è possibile documentare tutte le possibili dipendenze esterne in questa guida. È responsabilità del team verificare che ogni dipendenza esterna dell'applicazione possa essere soddisfatta dopo una migrazione del servizio app.

Segreti di inventario

Password e stringhe sicure

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 è probabile che tali stringhe si trovino in 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>

Determinare se e come viene usato il file system

Qualsiasi utilizzo del file system nel server applicazioni richiede modifiche della configurazione o, in casi rari, dell'architettura. È possibile identificare alcuni o tutti gli scenari seguenti.

Contenuto statico di sola lettura

Se l'applicazione attualmente serve contenuto statico, è necessario un percorso alternativo. È consigliabile spostare contenuto statico in Azure Blob Storage e aggiungere Azure Front Door per i download rapidi a livello globale. Per altre informazioni, vedere Static website hosting in Azure Storage e Integrate un account Azure Storage con Azure Front Door.

Casi speciali

Alcuni scenari di produzione possono richiedere ulteriori modifiche o imporre limitazioni aggiuntive. Sebbene tali scenari siano poco frequenti, è importante assicurarsi che siano inapplicabili all'applicazione o risolti correttamente.

Determinare se l'applicazione si basa su attività programmate

I processi pianificati, ad esempio le attività dell'utilità di Quartz Scheduler o i processi Cron, non possono essere usati con App Service. Il servizio app non impedisce la distribuzione interna di un'applicazione contenente attività pianificate. 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.

Fare l'inventario di tutte le attività programmate, sia all'interno che all'esterno del processo dell'applicazione.

Determinare se l'applicazione contiene codice specifico del sistema operativo

Se l'applicazione contiene codice con dipendenze dal sistema operativo host, è necessario effettuare il refactoring per rimuovere tali dipendenze. Ad esempio, potrebbe essere necessario sostituire qualsiasi uso di / o \ nei percorsi del file system con File.Separator o Paths.get se l'applicazione è in esecuzione in Windows.

Identificare tutti i processi/daemon esterni in esecuzione nei server di produzione

I processi in esecuzione all'esterno del server applicazioni, ad esempio i daemon di monitoraggio, dovranno essere migrati altrove o eliminati.

Identificare la gestione delle richieste non-HTTP o porte multiple

Il servizio app supporta solo un singolo endpoint HTTP su una singola porta. Se l'applicazione è in ascolto su più porte o accetta richieste che usano protocolli diversi da HTTP, non usare Azure App Service.

Migrazione

Parametrizzare la configurazione

Assicurarsi che tutte le coordinate delle risorse esterne(ad esempio le stringhe di connessione del database) e altre impostazioni personalizzabili possano essere lette dalle variabili di ambiente. Se si esegue la migrazione di un'applicazione Spring Boot, tutte le impostazioni di configurazione devono essere già esterne. Per altre informazioni, vedere Externalized Configuration (Configurazione esterna) nella documentazione di Spring Boot.

Ecco un esempio che fa riferimento a una SERVICEBUS_CONNECTION_STRING variabile di ambiente da un file application.properties :

spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000

Configurare un piano di servizio app

Nell'elenco dei piani di servizio disponibili selezionare il piano le cui specifiche soddisfano o superano quelle dell'hardware di produzione corrente.

Annotazioni

Se si prevede di eseguire distribuzioni di staging/canary o di usare gli slot di distribuzione, il piano App Service deve includere la capacità aggiuntiva necessaria. È consigliabile usare piani Premium o superiori per le applicazioni Java.

Creare il piano App Service.

Creare e distribuire app Web

È necessario creare un'app Web nel piano di servizio app (scegliendo "Java SE" come stack di runtime) per ogni file JAR eseguibile che si intende eseguire.

Applicazioni Maven

Se l'applicazione viene compilata da un file POM Maven, usare il plug-in Webapp per Maven per creare l'app Web e distribuire l'applicazione. Per altre informazioni, vedere Quickstart: Creare un'app Java in Azure App Service.

Applicazioni non Maven

Se non è possibile usare il plug-in Maven, sarà necessario effettuare il provisioning dell'app Web tramite altri meccanismi, ad esempio:

Dopo aver creato l'app Web, usare uno dei meccanismi di distribuzione disponibili per distribuire l'applicazione. Se possibile, l'applicazione deve essere caricata in /home/site/wwwroot/app.jar. Se non si vuole rinominare il file JAR in app.jar, è possibile caricare uno script della shell con il comando per eseguire il file JAR. Incollare quindi il percorso completo di questo script nella casella di testo File di avvio nella sezione Configurazione del portale. Lo script di avvio non viene eseguito dalla directory in cui si trova. Pertanto, usare sempre percorsi assoluti per fare riferimento ai file nello script di avvio , ad esempio . java -jar /home/myapp/myapp.jar

Eseguire la migrazione delle opzioni di runtime JVM

Se l'applicazione richiede opzioni di runtime specifiche, usare il meccanismo più appropriato per specificarli.

Configurare un dominio personalizzato e SSL

Se l'applicazione Web sarà visibile in un dominio personalizzato, sarà necessario eseguirne il mapping a tale dominio. Per altre informazioni, vedere Tutorial: Eseguire il mapping di un nome DNS personalizzato esistente a Azure App Service.

Sarà quindi necessario associare il certificato SSL per quel dominio alla Web App del servizio App Service. Per ulteriori informazioni, consultare Proteggere un nome DNS personalizzato con un binding SSL in Azure App Service.

Importare certificati backend

Tutti i certificati per la comunicazione con i sistemi back-end, ad esempio i database, devono essere resi disponibili al servizio app. Per altre informazioni, vedere Aggiungere un certificato SSL nel servizio app.

Eseguire la migrazione di coordinate di risorse esterne e altre impostazioni

Seguire questa procedura per eseguire la migrazione delle stringhe di connessione e di altre impostazioni.

Annotazioni

Per tutte le impostazioni dell'applicazione Spring Boot con parametri con variabili nella sezione Parametrizza la configurazione , tali variabili di ambiente devono essere definite nella configurazione dell'applicazione. Tutte le impostazioni dell'applicazione Spring Boot non parametrizzate in modo esplicito con le variabili di ambiente possono comunque essere sottoposte a override tramite Configurazione applicazione. Per esempio:

spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000

Configurazione dell'applicazione App Service

Eseguire la migrazione dei processi pianificati

Per eseguire processi pianificati in Azure, è consigliabile usare un trigger Timer per Azure Functions. Non è necessario eseguire la migrazione del codice del lavoro in una funzione. La funzione può semplicemente richiamare un URL nell'applicazione per attivare il processo. Se tali esecuzioni di processo devono essere richiamate dinamicamente e/o rilevate centralmente, è consigliabile usare Spring Batch.

In alternativa, è possibile creare un'app per la logica con un trigger Ricorrenza per richiamare l'URL senza scrivere codice all'esterno dell'applicazione. Per altre informazioni, vedere Overview - Che cos'è Azure Logic Apps? e Creare, pianificare ed eseguire attività e flussi di lavoro ricorrenti con il trigger Ricorrenza in Azure Logic Apps.

Annotazioni

Per evitare un uso improprio, potrebbe essere necessario assicurarsi che l'endpoint di chiamata del processo richieda le credenziali. In questo caso, la funzione di trigger dovrà fornire le credenziali.

Eseguire la migrazione e abilitare il provider di identità

Se l'applicazione richiede l'autenticazione o l'autorizzazione, assicurarsi che siano configurate per accedere al provider di identità usando le indicazioni seguenti:

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

Riavvio e test di fumo

Infine, sarà necessario riavviare l'app Web per applicare tutte le modifiche alla configurazione. Al termine del riavvio, verificare che l'applicazione venga eseguita correttamente.

Dopo la migrazione

Ora che è stata eseguita la migrazione dell'applicazione a Azure App Service verificare che funzioni come previsto. Dopo aver completato questa operazione, sono disponibili alcune raccomandazioni che consentono di rendere l'applicazione più nativa del cloud.

Consigli

  • Last updated on