Översikt över programmigrering

Artikel
02/04/2025

Kommentar

Basic-, Standard- och Enterprise-planerna kommer att vara inaktuella från och med mitten av mars 2025, med en 3-årig pensionsperiod. Vi rekommenderar att du övergår till Azure Container Apps. Mer information finns i meddelandet om azure Spring Apps-pensionering.

Standardförbrukningen och den dedikerade planen kommer att vara inaktuell från och med den 30 september 2024, med en fullständig avstängning efter sex månader. Vi rekommenderar att du övergår till Azure Container Apps. Mer information finns i Migrera Azure Spring Apps Standard-förbrukning och dedikerad plan till Azure Container Apps.

Den här artikeln gäller för:✅ Basic/Standard ✅ Enterprise

Den här artikeln innehåller en översikt över en appmigreringsmetod från Azure Spring Apps till Azure Container Apps.

Förutsättningar

En befintlig Azure Spring Apps-instans.
En befintlig Azure-containerapp. För mer information, se Snabbstart: Distribuera din första containerapp med hjälp av Azure-portalen.

Distribuera ett program

Med Azure Container Apps kan du distribuera från containerregister, till exempel Azure Container Registry (ACR) eller Docker Hub. Du kan använda verktyg som Azure Portal, Azure CLI eller andra för distributionen. I följande exempel visas hur du distribuerar ett program till den hanterade målmiljön my-container-apps. Mer information finns i Distribuera din första containerapp med containerapp up eller Distribuera din första containerapp med hjälp av Azure Portal.

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

Azure Container Apps erbjuder nu en förhandsversionsfunktion för Java-program. Med den här funktionen kan användare distribuera program direkt från en JAR-fil eller källkod från en lokal lagringsplats eller en kodlagringsplats. Vi rekommenderar starkt att du distribuerar containerappar med hjälp av en containeravbildning.

Miljövariabler

Med Azure Container Apps kan du konfigurera miljövariabler. Du kan konfigurera dem när du skapar en ny app eller senare genom att skapa en ny revision.

Om du vill ändra miljövariabler via Azure Portal måste du skapa en ny revision explicit. När du använder Azure CLI kan du uppdatera appen med kommandot az containerapp update, som du ser i följande exempel, som skapar en ny revision automatiskt. Det är viktigt att du inte duplicerar miljövariabler. Om flera variabler har samma namn börjar bara den sista i listan att gälla.

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

Azure Container Apps innehåller även inbyggda miljövariabler. Dessa variabler erbjuder användbara plattformsmetadata under körning. Mer information finns i avsnittet Inbyggda miljövariabler i Hantera miljövariabler i Azure Container Apps.

Hemligheter

Azure Container Apps hjälper till att lagra känsliga konfigurationsvärden, så kallade hemligheter, på ett säkert sätt. Dessa hemligheter definieras på programnivå som namn/värde-par och är tillgängliga för alla revisioner av containerappar.

Vi rekommenderar att du lagrar hemligheter i Azure Key Vault i stället för att ange dem direkt. Du kan referera till värdet för varje hemlighet från Azure Key Vault med något av följande format:

https://myvault.vault.azure.net/secrets/mysecret refererar till den senaste versionen av en hemlighet.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> refererar till en specifik version av en hemlighet.

För den här metoden måste du aktivera hanterad identitet för containerappen och ge den åtkomst till Key Vault. Åtkomstprincipen i Key Vault bör tillåta att appen använder GET för att hämta hemligheter. Om Key Vault använder rollbaserad åtkomstkontroll i Azure måste du också tilldela Key Vault Secrets User roll. När du har konfigurerat en hanterad identitet kan du lägga till en Key Vault-referens som en hemlighet i din app genom att ange hemlighetens URI. Sedan kan appen hämta hemligheten vid körning med hjälp av den hanterade identiteten.

Tänk på följande regler:

Att ta bort eller ändra en hemlighet påverkar inte befintliga revisioner automatiskt. När du uppdaterar eller tar bort hemligheter måste du antingen distribuera en ny revision eller starta om en befintlig för att återspegla ändringarna.
Du kan också använda hemligheter i skalningsregler.

Du kan använda hemligheter i containerappar genom att referera till dem i miljövariabler eller montera dem i volymer. I miljövariabler fylls hemlighetens värde i automatiskt. Du kan också montera hemligheter i volymer. I det här fallet lagras varje hemlighet som en fil med det hemliga namnet som filnamn och det hemliga värdet som filens innehåll. Med den här flexibiliteten kan du hantera hemligheter på ett säkert sätt och komma åt dem i appmiljön. Mer information finns i Hantera hemligheter i Azure Container Apps.

Om din arbetsbelastning skyddar känslig konfiguration och hämtar egenskaper från Key Vault med spring-cloud-azure-starter-keyvault-secrets bibliotek kan du använda antingen Azure SDK eller Spring KeyVault PropertySource i Azure Container Apps. Du behöver inte ändra koden under migreringen.

JVM-alternativ

Om du vill skriva ut JVM-alternativen i Azure Container Apps följer du stegen i Skapa containeravbildning från en JAR eller WAR för att containerisera ditt program. Du kan lägga till -XX:+PrintFlagsFinal i ENTRYPOINT Dockerfile, som du ser i följande exempel:

# 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"]

Om du vill köra frågor mot JVM-alternativ i Azure Container Apps använder du följande fråga:

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

Följande logg är ett exempel som visar JVM-alternativ när du har kört en fråga:

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

Om du vill justera JVM-alternativen i Azure Container Apps kan du lägga till JVM-alternativ i ENTRYPOINT Dockerfile enligt följande exempel:

# 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"]

Mer information om JVM-alternativ finns i Java HotSpot VM-alternativ och Konfigurera JVM-alternativ.

Storage

Både Azure Spring Apps och Azure Container Apps stöder lagring med containeromfattning, vilket innebär att data som lagras i containern endast är tillgängliga när containern körs. För Azure Spring Apps är den totala lagringen för en app 5 GiB. Azure Container Apps erbjuder lagring som sträcker sig från 1 GiB till 8 GiB beroende på det totala antalet tilldelade virtuella processorer. Den här lagringen innehåller all tillfällig lagring som tilldelats varje replik. Mer information finns i avsnittet Tillfällig lagring i Använda lagringsmonteringar i Azure Container Apps.

Både Azure Spring Apps och Azure Container Apps stöder permanent lagring via Azure Files. Azure Container Apps stöder montering av filresurser med hjälp av SMB- och NFS-protokoll. Du måste skapa en lagringsdefinition i den hanterade miljön och sedan definiera en volym med AzureFile (SMB) eller NfsAzureFile (NFS) i en revision. Du kan slutföra hela konfigurationen för AzureFile (SMB) i Azure Portal. Mer information finns i Skapa en Azure Files-volymmontering i Azure Container Apps. Stöd för montering av NFS-resurser finns för närvarande i förhandsversion. Du kan konfigurera den med hjälp av Azure CLI eller en ARM-mall. Mer information finns i NFS Azure-filresurser och avsnittet Skapa en NFS Azure-filresurs i Självstudie: Skapa en NFS Azure-filresurs och montera den på en virtuell Linux-dator med hjälp av Azure Portal.

Hanterad identitet

Varje containerapp har en systemtilldelad hanterad identitet eller användartilldelade hanterade identiteter för åtkomst till skyddade Azure-resurser. Information om hur du hanterar identiteter och beviljar behörigheter finns i Hanterade identiteter i Azure Container Apps.

Varje containerapp har en intern REST-slutpunkt som är tillgänglig via IDENTITY_ENDPOINT miljövariabeln, som skiljer sig från slutpunkten som används i Azure Spring Apps. Om din app använder en direkt HTTP-begäran GET måste du justera koden för att få rätt slutpunkt. Om din app använder en hanterad identitet via Azure Identity-klientbiblioteket behöver du inga kodändringar eftersom Azure Identity hanterar den här informationen automatiskt.

När en arbetsbelastning har åtkomst till skyddade Azure-resurser måste den hämta en åtkomsttoken med hjälp av program-ID:t eller klient-ID:t för en hanterad identitet. I en Azure Spring Apps-miljö kan du ange klient-ID för en systemtilldelad eller användartilldelad hanterad identitet. Du kan också lämna den tom och låta tjänsten välja program-ID från en av de hanterade identiteterna. I Azure Container Apps kan du inte uttryckligen ange program-ID:t när du använder en systemtilldelad hanterad identitet. Program-ID:t krävs dock när du använder en användartilldelad hanterad identitet.

Hälsotillståndsavsökningar

Azure Container Apps och Azure Spring Apps stöder båda alla tre typerna av hälsoavsökningar, inklusive startavsökning, livenessavsökning och beredskapsavsökning. För Azure Container Apps kan avsökningar använda antingen HTTP- eller TCP-protokoll. exec stöds inte ännu.

I Azure Spring Apps konfigureras avsökningsinställningarna för distributionsresursen. För Azure Container Apps definieras däremot avsökningsinställningar för containerappresursen. Följande inställningar är tillgängliga:

Property	beskrivning	Azure Spring Apps	Azure Container Apps
`probeAction`	Avsökningens åtgärd.	Stöder `HTTPGetAction`, `TCPSocketAction`och `ExecAction`.	Det finns inga egenskaper för åtgärdstypen. Användaren måste använda antingen `httpGet` eller `tcpSocket` direkt.
`disableProbe`	Anger om avsökningen är inaktiverad.	Booleskt	Booleskt
`initialDelaySeconds`	Antalet sekunder efter att appinstansen startar innan avsökningar initieras.		Värdet varierar från 1 till 60.
`periodSeconds`	Hur ofta, i sekunder, för att utföra avsökningen.	Minimivärdet är 1.	Värdet sträcker sig från 1 till 240, med standardvärdet 10.
`timeoutSeconds`	Antalet sekunder efter vilken avsökningen överskrider tidsgränsen.	Minimivärdet är 1.	Värdet sträcker sig från 1 till 240, med standardvärdet 1.
`failureThreshold`	De minsta efterföljande felen för avsökningen som ska betraktas som misslyckade efter att ha lyckats.	Minimivärdet är 1.	Värdet sträcker sig från 1 till 10, med standardvärdet 3.
`successThreshold`	Minsta lyckade resultat i följd för att avsökningen ska anses vara lyckad efter att ha misslyckats.	Minimivärdet är 1.	Värdet sträcker sig från 1 till 10, med standardvärdet 1.
`terminationGracePeriodSeconds`	Den valfria varaktigheten i sekunder som podden måste avslutas korrekt vid avsökningsfel.	Standardvärdet är 90 sekunder.	Det maximala värdet är 3 600 sekunder.

För närvarande kan du inte konfigurera avsökningarna för Azure Container Apps direkt på Azure Portal. I stället måste du konfigurera dem med hjälp av antingen en ARM-mall eller en YAML-fil för containerappen via Azure CLI. Mer information finns i Hälsoavsökningar i Azure Container Apps.

Skala

Azure Container Apps stöder horisontell skalning via en uppsättning skalningsregler. När en regel läggs till eller ändras skapas en ny revision av containerappen.

Skalning har tre kategorier av utlösare, HTTP, TCP och anpassade. HTTP och TCP baseras på antalet begäranden eller nätverksanslutningar. Mer information finns i Ange skalningsregler i Azure Container Apps.

Utlösarskalning baserat på CPU eller minne

Skalningsreglerna för anpassade containerappar baseras på ScaledObject-baserad KEDA-skalning. Du kan uppnå skalning med containerappar baserat på PROCESSOR- eller minnesanvändning via KEDA CPU Scaler och Memory Scaler.

I följande exempel visas en konfiguration där utskalning sker när den genomsnittliga minnesanvändningen överskrider 25 %. Minnesanvändningen innehåller det minne som används av den aktuella containerappen och även relevanta poddar, till exempel interna sidovagnscontainrar. KEDA innehåller inbyggd konfiguration för att förhindra att containerappen flaxar. Mer information om interna inställningar finns i Ange skalningsregler i Azure Container Apps. Du bör kontrollera beteendet under körningen för att se till att det uppfyller dina behov.

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"

Utlösarskalning baserat på Java-mått

KEDA erbjuder en Azure Monitor-skalning som möjliggör skalning baserat på mått som är tillgängliga i Azure Monitor. Du kan använda den här funktionen för att skala dina program dynamiskt baserat på Java-specifika mått som publiceras till Azure Monitor.

Förutsättningar

Registrera ett klientprogram i Microsoft Entra ID. Mer information finns i Snabbstart: registrera ett program med Microsoft Identity Platform.
Bevilja behörigheter. Tilldela det registrerade programmet Monitoring Reader rollen för din Azure Container Apps-resurs.

Steg

Lägg till hemligheter. Använd följande kommando för att lagra Microsoft Entra-programmets klient-ID och hemlighet i Azure Container Apps som hemligheter:

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

Definiera en skalningsregel. Använd följande kommando för att skapa en anpassad skalningsregel som använder Azure Monitor-skalning. Den här regeln utlöser skalningsåtgärder baserat på ett specifikt Java-mått, till exempel , övervakat JvmThreadCountvia Azure Monitor.

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"

Nyckelinformation

Hantering av hemligheter: Programmets autentiseringsuppgifter – klient-ID och lösenord – lagras på ett säkert sätt som hemligheter.
Skalningsvillkor: Parametern metricName identifierar Java-måttet – JvmThreadCount i det här fallet – som används för att utvärdera när skalning ska ske.
Målvärde: Parametern targetValue anger tröskelvärdet för skalning – till exempel skalning när antalet trådar överskrider 30.

Genom att konfigurera den här regeln kan containerappen dynamiskt justera antalet instanser baserat på Java-specifika prestandamått, vilket förbättrar svarstiden och resursanvändningen.

Dela via

Översikt över programmigrering

Förutsättningar

Distribuera ett program

Miljövariabler

Hemligheter

JVM-alternativ

Storage

Hanterad identitet

Hälsotillståndsavsökningar

Skala

Utlösarskalning baserat på CPU eller minne

Utlösarskalning baserat på Java-mått

Förutsättningar

Steg

Nyckelinformation

Feedback

Ytterligare resurser