Condividi tramite

Eseguire la migrazione di applicazioni Spring Boot al servizio app di Azure

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

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

java -version

Nel servizio app Azure i file binari per Java 8 vengono forniti da Eclipse Temtalk. Per Java 11, 17 e tutte le future versioni LTS di Java, servizio app fornisce 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, 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.

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

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.

Inventario dei segreti

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.

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>

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 Archiviazione BLOB di Azure e aggiungere Frontdoor di Azure per i download rapidi a livello globale. Per altre informazioni, vedere l'hosting di siti web statici su Azure Storage e Integrare un account di archiviazione di Azure 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 processi pianificati

I processi pianificati, ad esempio le attività dell'utilità di Quartz Scheduler o i processi Cron, non possono essere usati con il servizio app. 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 servizio app di Azure.

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

Effettuare il provisioning di 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 staging/canary o di usare gli slot di distribuzione, il piano di servizio app deve includere tale capacità aggiuntiva. È consigliabile usare piani Premium o superiori per le applicazioni Java.

Creare il piano di servizio app.

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 Avvio rapido: Creare un'app Java nel servizio app Azure.

Applicazioni non Maven

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

Una volta creata 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 dello 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 specificarle.

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 Esercitazione: Eseguire il mapping di un nome DNS personalizzato esistente a app Azure Servizio.

Sarà quindi necessario associare il certificato SSL per tale dominio all'app Web del servizio app. Per altre informazioni, vedere Proteggere un nome DNS personalizzato con un binding SSL nel servizio app di Azure.

Importare certificati back-end

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 Servizio App

Eseguire la migrazione dei processi pianificati

Per eseguire processi pianificati in Azure, è consigliabile usare un trigger Timer per Funzioni di Azure. Non è necessario eseguire la migrazione del codice del processo stesso in una funzione. La funzione può semplicemente richiamare un URL nell'applicazione per attivare il processo. Se le esecuzioni di processi devono essere richiamate dinamicamente e/o monitorate a livello centrale, provare a 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 Panoramica di App per la logica di Azure e Creare, pianificare ed eseguire attività e flussi di lavoro ricorrenti con il trigger Ricorrenza in App per la logica di Azure.

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

Riavvio e smoke test

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 al servizio app di Azure, è necessario 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