Condividi tramite

Panoramica della migrazione delle applicazioni

  • Articolo

Nota

I piani Basic, Standard ed Enterprise saranno deprecati a partire dalla metà di marzo 2025, con un periodo di ritiro di 3 anni. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere l'annuncio di ritiro di Azure Spring Apps.

Il piano Standard a consumo e dedicato sarà deprecato a partire dal 30 settembre 2024, con un arresto completo dopo sei mesi. È consigliabile eseguire la transizione ad App Azure Container. Per altre informazioni, vedere Eseguire la migrazione del consumo di Azure Spring Apps Standard e del piano dedicato alle app Azure Container.

Questo articolo si applica a:✅ Basic/Standard ✅ Enterprise

Questo articolo offre una panoramica dell'approccio di migrazione delle app da App Spring di Azure ad App Azure Container.

Prerequisiti

Distribuire un'applicazione

App Azure Container consente di eseguire la distribuzione da registri contenitori, ad esempio Registro Azure Container (ACR) o Docker Hub. È possibile usare strumenti come il portale di Azure, l'interfaccia della riga di comando di Azure o altri strumenti per la distribuzione. Nell'esempio seguente viene illustrato come distribuire un'applicazione nell'ambiente my-container-appsgestito di destinazione. Per altre informazioni, vedere Distribuire la prima app contenitore con containerapp up o Distribuire la prima app contenitore usando il portale di Azure.

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

App Azure Container offre ora una funzionalità di anteprima per le applicazioni Java. Questa funzionalità consente agli utenti di distribuire le applicazioni direttamente da un file JAR o da un codice sorgente da un repository locale o di codice. È consigliabile distribuire app contenitore usando un'immagine del contenitore.

Variabili di ambiente

App Azure Container consente di configurare le variabili di ambiente. È possibile configurarli quando si crea una nuova app o versioni successive creando una nuova revisione.

Per modificare le variabili di ambiente tramite il portale di Azure, è necessario creare una nuova revisione in modo esplicito. Quando si usa l'interfaccia della riga di comando di Azure, è possibile aggiornare l'app con il comando az containerapp update, come illustrato nell'esempio seguente, che crea automaticamente una nuova revisione. È importante non duplicare le variabili di ambiente. Se più variabili hanno lo stesso nome, viene applicata solo l'ultima nell'elenco.

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

App Azure Container offre anche variabili di ambiente predefinite. Queste variabili offrono metadati utili della piattaforma durante il runtime. Per altre informazioni, vedere la sezione Variabili di ambiente predefinite di Gestire le variabili di ambiente in App Azure Container.

Segreti

App Azure Container consente di archiviare i valori di configurazione sensibili, noti come segreti, in modo sicuro. Questi segreti vengono definiti a livello di applicazione come coppie nome/valore e sono accessibili a tutte le revisioni dell'app contenitore.

È consigliabile archiviare i segreti in Azure Key Vault anziché immetterli direttamente. È possibile fare riferimento al valore di ogni segreto di Azure Key Vault usando uno dei formati seguenti:

  • https://myvault.vault.azure.net/secrets/mysecret fa riferimento alla versione più recente di un segreto.
  • https://myvault.vault.azure.net/secrets/mysecret/<version-ID> fa riferimento a una versione specifica di un segreto.

Per questo approccio, è necessario abilitare l'identità gestita per l'app contenitore e concedergli l'accesso a Key Vault. I criteri di accesso in Key Vault devono consentire all'app di usare GET per ottenere segreti. In alternativa, se Key Vault usa il controllo degli accessi in base al ruolo di Azure, è necessario assegnare Key Vault Secrets User il ruolo. Dopo aver configurato l'identità gestita, è possibile aggiungere un riferimento a Key Vault come segreto nell'app specificando l'URI del segreto. L'app può quindi recuperare il segreto in fase di esecuzione usando l'identità gestita.

Tenere presenti le regole seguenti:

  • La rimozione o la modifica di un segreto non influisce automaticamente sulle revisioni esistenti. Quando si aggiornano o si eliminano segreti, è necessario distribuire una nuova revisione o riavviare una versione esistente per riflettere le modifiche.
  • È anche possibile usare segreti all'interno delle regole di scalabilità.

È possibile usare i segreti nelle app contenitore facendo riferimento a tali segreti nelle variabili di ambiente o montandoli nei volumi. Nelle variabili di ambiente il valore del segreto viene popolato automaticamente. In alternativa, è possibile montare i segreti nei volumi. In questo caso, ogni segreto viene archiviato come file con il nome del segreto come nome file e il valore del segreto come contenuto del file. Questa flessibilità consente di gestire i segreti in modo sicuro e accedervi all'interno dell'ambiente dell'app. Per altre informazioni, vedere Gestire i segreti in App Azure Container.

Se il carico di lavoro protegge la configurazione sensibile e recupera le proprietà dall'insieme di credenziali delle chiavi con spring-cloud-azure-starter-keyvault-secrets la libreria, è possibile usare Azure SDK o Spring KeyVault PropertySource nelle app contenitore di Azure. Non è necessario modificare il codice durante la migrazione.

Opzioni JVM

Per stampare le opzioni JVM in App Contenitore di Azure, seguire la procedura descritta in Compilare l'immagine del contenitore da un file JAR o WAR per inserire in contenitori l'applicazione. È possibile aggiungere -XX:+PrintFlagsFinal nel ENTRYPOINT file Dockerfile, come illustrato nell'esempio seguente:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Per eseguire query sulle opzioni JVM in App Contenitore di Azure, usare la query seguente:

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

Il log seguente è un esempio che mostra le opzioni JVM dopo l'esecuzione di una query:

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Per modificare le opzioni JVM in App Azure Container, è possibile aggiungere opzioni JVM nel ENTRYPOINT dockerfile, come illustrato nell'esempio seguente:

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

Per altre informazioni sulle opzioni JVM, vedere Opzioni della macchina virtuale Java HotSpot e Configurazione delle opzioni JVM.

Storage

App Azure Spring e App Azure Container supportano entrambi l'archiviazione con ambito contenitore, il che significa che i dati archiviati nel contenitore sono disponibili solo durante l'esecuzione del contenitore. Per Azure Spring Apps, lo spazio di archiviazione totale per un'app è 5 GiB. Le app Azure Container offrono spazio di archiviazione compreso tra 1 GiB e 8 GiB a seconda del numero totale di vCPU allocati. Questa risorsa di archiviazione include tutte le risorse di archiviazione temporanee assegnate a ogni replica. Per altre informazioni, vedere la sezione Ephemeral storage (Archiviazione temporanea) di Use storage mounts in Azure Container Apps (Usare i montaggi di archiviazione nelle app contenitore di Azure).

App Azure Spring e App Azure Container supportano entrambi l'archiviazione permanente tramite File di Azure. App Azure Container supporta il montaggio di condivisioni file usando protocolli SMB e NFS. È necessario creare una definizione di archiviazione nell'ambiente gestito e quindi definire un volume di AzureFile (SMB) o NfsAzureFile (NFS) in una revisione. È possibile completare l'intera configurazione per AzureFile (SMB) nel portale di Azure. Per altre informazioni, vedere Creare un montaggio di volumi File di Azure in App Azure Container. Il supporto per il montaggio di condivisioni NFS è attualmente in anteprima. È possibile configurarlo usando l'interfaccia della riga di comando di Azure o un modello di Resource Manager. Per altre informazioni, vedere Condivisioni file di Azure NFS e la sezione Creare una condivisione file di Azure NFS di Esercitazione: Creare una condivisione file di Azure NFS e montarla in una macchina virtuale Linux usando il portale di Azure.

Identità gestita

Ogni app contenitore ha un'identità gestita assegnata dal sistema o identità gestite assegnate dall'utente per accedere alle risorse di Azure protette. Per informazioni su come gestire le identità e concedere le autorizzazioni, vedere Identità gestite in App Azure Container.

Ogni app contenitore ha un endpoint REST interno, accessibile tramite la IDENTITY_ENDPOINT variabile di ambiente, che differisce dall'endpoint usato in Azure Spring Apps. Se l'app usa una richiesta HTTP GET diretta, è necessario modificare il codice per ottenere l'endpoint corretto. Se l'app usa un'identità gestita tramite la libreria client di Identità di Azure, non sono necessarie modifiche al codice perché Identità di Azure gestisce automaticamente questo dettaglio.

Quando un carico di lavoro accede alle risorse di Azure protette, deve recuperare un token di accesso usando l'ID applicazione o l'ID client di un'identità gestita. In un ambiente Azure Spring Apps è possibile impostare l'ID client di un'identità gestita assegnata dal sistema o assegnata dall'utente. In alternativa, è possibile lasciarlo vuoto e consentire al servizio di selezionare l'ID applicazione da una delle identità gestite. In App Contenitore di Azure non è possibile specificare in modo esplicito l'ID applicazione quando si usa un'identità gestita assegnata dal sistema. Tuttavia, l'ID applicazione è necessario quando si usa un'identità gestita assegnata dall'utente.

Probe di integrità

App Azure Container e App Azure Spring supportano entrambi tutti e tre i tipi di probe di integrità, tra cui probe di avvio, probe di attività e probe di idoneità. Per le app contenitore di Azure, i probe possono usare il protocollo HTTP o TCP. exec non è ancora supportato.

In Azure Spring Apps le impostazioni del probe vengono configurate nella risorsa di distribuzione. Al contrario, per le app contenitore di Azure, le impostazioni del probe vengono definite nella risorsa dell'app contenitore. Sono disponibili le impostazioni seguenti:

Proprietà Descrizione Azure Spring Apps App contenitore di Azure
probeAction Azione del probe. Supporta HTTPGetAction, TCPSocketActione ExecAction. Non esistono proprietà per il tipo di azione. L'utente deve usare direttamente httpGet o tcpSocket .
disableProbe Indica se il probe è disabilitato. Booleano Booleano
initialDelaySeconds Numero di secondi dopo l'avvio dell'istanza dell'app prima dell'avvio dei probe. Il valore è compreso tra 1 e 60.
periodSeconds Frequenza, in secondi, per eseguire il probe. Il valore minimo è 1. Il valore è compreso tra 1 e 240, con un valore predefinito pari a 10.
timeoutSeconds Numero di secondi dopo il quale si verifica il timeout del probe. Il valore minimo è 1. Il valore è compreso tra 1 e 240, con un valore predefinito pari a 1.
failureThreshold Errori consecutivi minimi che il probe deve essere considerato non riuscito dopo l'esito positivo. Il valore minimo è 1. Il valore è compreso tra 1 e 10, con un valore predefinito pari a 3.
successThreshold I successi consecutivi minimi per il probe devono essere considerati riusciti dopo aver avuto esito negativo. Il valore minimo è 1. Il valore è compreso tra 1 e 10, con un valore predefinito pari a 1.
terminationGracePeriodSeconds La durata facoltativa in secondi del pod deve terminare normalmente in caso di errore del probe. Il valore predefinito è 90 secondi. Il valore massimo è 3600 secondi.

Attualmente, non è possibile configurare i probe per le app di Azure Container direttamente nel portale di Azure. È invece necessario configurarli usando un modello arm o un file YAML dell'app contenitore tramite l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Probe di integrità in App Azure Container.

Ridimensiona

App Azure Container supporta il ridimensionamento orizzontale tramite un set di regole di ridimensionamento. Quando viene aggiunta o modificata una regola, viene creata una nuova revisione dell'app contenitore.

Il ridimensionamento include tre categorie di trigger, HTTP, TCP e personalizzati. HTTP e TCP sono basati sul numero di connessioni di richiesta o di rete. Per altre informazioni, vedere Impostare le regole di ridimensionamento in App contenitore di Azure.

Ridimensionamento dei trigger in base alla CPU o alla memoria

Le regole di ridimensionamento delle app contenitore personalizzate si basano sul scaler KEDA basato su ScaledObject. È possibile ottenere il ridimensionamento con le app contenitore in base all'utilizzo della CPU o della memoria tramite il scaler della CPU KEDA e il scaler di memoria.

Nell'esempio seguente viene illustrata una configurazione in cui si verifica l'aumento del numero di istanze quando l'utilizzo medio della memoria supera il 25%. L'utilizzo della memoria include la memoria usata dall'app contenitore corrente e anche i pod pertinenti, ad esempio i contenitori sidecar interni. KEDA include la configurazione predefinita per impedire che l'app contenitore venga intasagliata. Per altre informazioni sulle impostazioni interne, vedere Impostare le regole di ridimensionamento nelle app contenitore di Azure. È necessario verificare il comportamento durante il runtime per assicurarsi che soddisfi le proprie esigenze.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Attivare la scalabilità in base alle metriche Java

KEDA offre un scaler di Monitoraggio di Azure, che consente il ridimensionamento in base alle metriche disponibili in Monitoraggio di Azure. È possibile usare questa funzionalità per ridimensionare le applicazioni in modo dinamico in base a metriche specifiche di Java pubblicate in Monitoraggio di Azure.

Prerequisiti

Passaggi

  1. Aggiungere segreti. Usare il comando seguente per archiviare l'ID client e il segreto dell'applicazione Microsoft Entra in App Azure Container come segreti:

    az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>

  2. Definire una regola di ridimensionamento. Usare il comando seguente per creare una regola di ridimensionamento personalizzata che usa il ridimensionamento di Monitoraggio di Azure. Questa regola attiva le azioni di ridimensionamento in base a una metrica Java specifica, ad esempio JvmThreadCount, monitorata tramite Monitoraggio di Azure.

    az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

Dettagli chiave:

  • Gestione dei segreti: le credenziali dell'applicazione, l'ID client e la password, vengono archiviate in modo sicuro come segreti.
  • Criteri di ridimensionamento: il metricName parametro identifica la metrica Java, JvmThreadCount in questo caso, usata per valutare quando deve verificarsi il ridimensionamento.
  • Valore di destinazione: il targetValue parametro imposta la soglia per il ridimensionamento, ad esempio la scalabilità quando il numero di thread supera 30.

Configurando questa regola, l'app contenitore può regolare dinamicamente il numero di istanze in base alle metriche delle prestazioni specifiche di Java, migliorando la velocità di risposta e l'utilizzo delle risorse.