Overzicht van toepassingsmigratie

Artikel
02/04/2025

Notitie

De Basic-, Standard- en Enterprise-abonnementen worden afgeschaft vanaf medio maart 2025, met een pensioenperiode van 3 jaar. We raden u aan om over te stappen naar Azure Container Apps. Zie de aankondiging over buitengebruikstelling van Azure Spring Apps voor meer informatie.

Het standaardverbruik en het speciale abonnement worden vanaf 30 september 2024 afgeschaft, met een volledige afsluiting na zes maanden. We raden u aan om over te stappen naar Azure Container Apps. Zie Azure Spring Apps Standard-verbruik en toegewezen abonnement migreren naar Azure Container Apps voor meer informatie.

Dit artikel is van toepassing op:✅ Basic/Standard ✅ Enterprise

Dit artikel bevat een overzicht van een app-migratiebenadering van Azure Spring Apps naar Azure Container Apps.

Vereisten

Een bestaand Azure Spring Apps-exemplaar.
Een bestaande Azure-container-app. Zie voor meer informatie Quickstart: uw eerste container-app implementeren met behulp van Azure Portal.

Een app implementeren

Met Azure Container Apps kunt u implementeren vanuit containerregisters, zoals Azure Container Registry (ACR) of Docker Hub. U kunt hulpprogramma's zoals Azure Portal, De Azure CLI of andere gebruiken voor de implementatie. In het volgende voorbeeld ziet u hoe u een toepassing implementeert in de beheerde doelomgeving my-container-apps. Zie Uw eerste container-app implementeren met containerapp up of Uw eerste container-app implementeren met behulp van Azure Portal voor meer informatie.

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 biedt nu een preview-functie voor Java-toepassingen. Met deze functie kunnen gebruikers toepassingen rechtstreeks vanuit een JAR-bestand of broncode implementeren vanuit een lokaal bestand of een codeopslagplaats. We raden u ten zeerste aan container-apps te implementeren met behulp van een containerinstallatiekopieën.

Omgevingsvariabelen

Met Azure Container Apps kunt u omgevingsvariabelen configureren. U kunt deze instellen wanneer u een nieuwe app maakt of later door een nieuwe revisie te maken.

Als u omgevingsvariabelen wilt wijzigen via Azure Portal, moet u expliciet een nieuwe revisie maken. Wanneer u de Azure CLI gebruikt, kunt u de app bijwerken met de opdracht az containerapp update, zoals wordt weergegeven in het volgende voorbeeld, waarmee automatisch een nieuwe revisie wordt gemaakt. Het is belangrijk om omgevingsvariabelen niet te dupliceren. Als meerdere variabelen dezelfde naam hebben, wordt alleen de laatste in de lijst van kracht.

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

Azure Container Apps biedt ook ingebouwde omgevingsvariabelen. Deze variabelen bieden nuttige platformmetagegevens tijdens runtime. Zie de sectie Ingebouwde omgevingsvariabelen van Omgevingsvariabelen beheren in Azure Container Apps voor meer informatie.

Geheimen

Met Azure Container Apps kunt u gevoelige configuratiewaarden, ook wel geheimen genoemd, veilig opslaan. Deze geheimen worden gedefinieerd op toepassingsniveau als naam/waardeparen en zijn toegankelijk voor alle revisies van container-apps.

U wordt aangeraden geheimen op te slaan in Azure Key Vault in plaats van ze rechtstreeks in te voeren. U kunt verwijzen naar de waarde van elk geheim uit Azure Key Vault met behulp van een van de volgende indelingen:

https://myvault.vault.azure.net/secrets/mysecret verwijst naar de nieuwste versie van een geheim.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> verwijst naar een specifieke versie van een geheim.

Voor deze aanpak moet u beheerde identiteit inschakelen voor uw container-app en deze toegang verlenen tot Key Vault. Met het toegangsbeleid in Key Vault kan de app GET geheimen ophalen. Als Key Vault gebruikmaakt van op rollen gebaseerd toegangsbeheer van Azure, moet u ook een rol toewijzen Key Vault Secrets User . Nadat u een beheerde identiteit hebt ingesteld, kunt u een Key Vault-verwijzing toevoegen als een geheim in uw app door de URI van het geheim op te geven. Vervolgens kan de app geheim ophalen tijdens runtime met behulp van de beheerde identiteit.

Houd rekening met de volgende regels:

Het verwijderen of wijzigen van een geheim heeft niet automatisch invloed op bestaande revisies. Wanneer u geheimen bijwerkt of verwijdert, moet u een nieuwe revisie implementeren of een bestaande opnieuw starten om de wijzigingen weer te geven.
U kunt ook geheimen binnen schaalregels gebruiken.

U kunt geheimen in container-apps gebruiken door ernaar te verwijzen in omgevingsvariabelen of door ze in volumes te koppelen. In omgevingsvariabelen wordt de waarde van het geheim automatisch ingevuld. U kunt ook geheimen in volumes koppelen. In dit geval wordt elk geheim opgeslagen als een bestand met de geheime naam als de bestandsnaam en de geheime waarde als de inhoud van het bestand. Dankzij deze flexibiliteit kunt u geheimen veilig afhandelen en openen in de app-omgeving. Zie Geheimen beheren in Azure Container Apps voor meer informatie.

Als uw workload gevoelige configuratie beveiligt en eigenschappen ophaalt uit Key Vault met spring-cloud-azure-starter-keyvault-secrets bibliotheek, kunt u Azure SDK of Spring KeyVault PropertySource gebruiken in Azure Container Apps. U hoeft de code niet te wijzigen tijdens de migratie.

JVM-opties

Als u de JVM-opties in Azure Container Apps wilt afdrukken, volgt u de stappen in Build Container Image van een JAR of WAR om uw toepassing in een container te plaatsen. U kunt uw ENTRYPOINT Dockerfile toevoegen-XX:+PrintFlagsFinal, zoals wordt weergegeven in het volgende voorbeeld:

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

Gebruik de volgende query om query's uit te voeren op JVM-opties in Azure Container Apps:

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

Het volgende logboek is een voorbeeld van JVM-opties na het uitvoeren van een query:

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

Als u de JVM-opties in Azure Container Apps wilt aanpassen, kunt u JVM-opties toevoegen aan uw ENTRYPOINT Dockerfile, zoals wordt weergegeven in het volgende voorbeeld:

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

Zie Java HotSpot VM Options and Configuring JVM Options (JVM-opties configureren) voor meer informatie over JVM-opties.

Storage

Azure Spring Apps en Azure Container Apps bieden beide ondersteuning voor opslag binnen het bereik van containers. Dit betekent dat de gegevens die zijn opgeslagen in de container alleen beschikbaar zijn terwijl de container wordt uitgevoerd. Voor Azure Spring Apps is de totale opslag voor een app 5 GiB. Azure Container Apps biedt opslag die varieert van 1 GiB tot 8 GiB, afhankelijk van het totale aantal toegewezen vCPU's. Deze opslag omvat alle tijdelijke opslag die aan elke replica is toegewezen. Zie de sectie Tijdelijke opslag van opslagkoppelingen gebruiken in Azure Container Apps voor meer informatie.

Azure Spring Apps en Azure Container Apps ondersteunen beide permanente opslag via Azure Files. Azure Container Apps ondersteunt het koppelen van bestandsshares met behulp van SMB- en NFS-protocollen. U moet een opslagdefinitie maken in de beheerde omgeving en vervolgens een volume van AzureFile (SMB) of NfsAzureFile (NFS) definiëren in een revisie. U kunt de volledige configuratie voor AzureFile (SMB) voltooien in Azure Portal. Zie Een Azure Files-volumekoppeling maken in Azure Container Apps voor meer informatie. Ondersteuning voor het koppelen van NFS-shares is momenteel beschikbaar als preview-versie. U kunt deze configureren met behulp van de Azure CLI of een ARM-sjabloon. Zie NFS Azure-bestandsshares en de sectie Een NFS Azure-bestandsshare maken in de zelfstudie: Een NFS Azure-bestandsshare maken en koppelen op een Virtuele Linux-machine met behulp van Azure Portal.

Beheerde identiteit

Elke container-app heeft een door het systeem toegewezen beheerde identiteit of door de gebruiker toegewezen beheerde identiteiten voor toegang tot beveiligde Azure-resources. Zie Beheerde identiteiten in Azure Container Apps voor meer informatie over het beheren van identiteiten en het verlenen van machtigingen.

Elke container-app heeft een intern REST-eindpunt dat toegankelijk is via de IDENTITY_ENDPOINT omgevingsvariabele, die verschilt van het eindpunt dat wordt gebruikt in Azure Spring Apps. Als uw app een directe HTTP-aanvraag GET gebruikt, moet u de code aanpassen om het juiste eindpunt op te halen. Als uw app gebruikmaakt van een beheerde identiteit via de Azure Identity-clientbibliotheek, hebt u geen codewijzigingen nodig omdat Azure Identity deze details automatisch beheert.

Wanneer een workload toegang heeft tot beveiligde Azure-resources, moet er een toegangstoken worden opgehaald met behulp van de toepassings-id of client-id van een beheerde identiteit. In een Azure Spring Apps-omgeving kunt u de client-id instellen van een door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit. U kunt deze ook leeg laten en de service de toepassings-id laten selecteren uit een van de beheerde identiteiten. In Azure Container Apps kunt u de toepassings-id niet expliciet opgeven wanneer u een door het systeem toegewezen beheerde identiteit gebruikt. De toepassings-id is echter vereist wanneer u een door de gebruiker toegewezen beheerde identiteit gebruikt.

Statuscontroles

Azure Container Apps en Azure Spring Apps ondersteunen beide alle drie de typen statustests, waaronder opstarttest, livenesstest en gereedheidstest. Voor Azure Container Apps kunnen tests gebruikmaken van het HTTP- of TCP-protocol. exec wordt nog niet ondersteund.

In Azure Spring Apps worden testinstellingen geconfigureerd voor de implementatieresource. Voor Azure Container Apps worden daarentegen testinstellingen gedefinieerd in de container-app-resource. De volgende instellingen zijn beschikbaar:

Eigenschappen	Beschrijving	Azure Spring Apps	Azure Container Apps
`probeAction`	De actie van de test.	Ondersteunt `HTTPGetAction`, `TCPSocketAction`en `ExecAction`.	Er zijn geen eigenschappen voor het actietype. De gebruiker moet een `httpGet` van beide of `tcpSocket` rechtstreeks gebruiken.
`disableProbe`	Geeft aan of de test is uitgeschakeld.	Booleaanse waarde	Booleaanse waarde
`initialDelaySeconds`	Het aantal seconden nadat het app-exemplaar is gestart voordat tests worden gestart.		De waarde varieert van 1 tot 60.
`periodSeconds`	Hoe vaak, in seconden, om de test uit te voeren.	Minimumwaarde is 1.	De waarde varieert van 1 tot 240, met een standaardwaarde van 10.
`timeoutSeconds`	Het aantal seconden waarna er een time-out optreedt voor de test.	Minimumwaarde is 1.	De waarde varieert van 1 tot 240, met een standaardwaarde van 1.
`failureThreshold`	De minimaal opeenvolgende fouten voor de test die als mislukt worden beschouwd nadat de test is geslaagd.	Minimumwaarde is 1.	De waarde varieert van 1 tot 10, met een standaardwaarde van 3.
`successThreshold`	De minimale opeenvolgende successen voor de test worden beschouwd als geslaagd nadat deze is mislukt.	Minimumwaarde is 1.	De waarde varieert van 1 tot 10, met een standaardwaarde van 1.
`terminationGracePeriodSeconds`	De optionele duur in seconden dat de pod probleemloos moet worden beëindigd bij een mislukte test.	De standaardwaarde is 90 seconden.	De maximumwaarde is 3600 seconden.

Op dit moment kunt u de tests voor Azure Container Apps niet rechtstreeks configureren in Azure Portal. In plaats daarvan moet u ze instellen met behulp van een ARM-sjabloon of een YAML-bestand voor een container-app via de Azure CLI. Zie Statustests in Azure Container Apps voor meer informatie.

Schaal wijzigen

Azure Container Apps ondersteunt horizontaal schalen via een set schaalregels. Wanneer een regel wordt toegevoegd of gewijzigd, wordt er een nieuwe revisie van de container-app gemaakt.

Schalen heeft drie categorieën triggers, HTTP, TCP en aangepast. HTTP en TCP zijn gebaseerd op het aantal aanvragen of netwerkverbindingen. Zie Schaalregels instellen in Azure Container Apps voor meer informatie.

Triggerschaal op basis van CPU of geheugen

De aangepaste regels voor het schalen van container-apps zijn gebaseerd op keda-scaler op basis van ScaledObject. U kunt schalen met container-apps op basis van CPU- of geheugengebruik via KEDA CPU-schaal en geheugenschaal.

In het volgende voorbeeld ziet u een configuratie waarbij uitschalen plaatsvindt wanneer het gemiddelde geheugengebruik hoger is dan 25%. Het geheugengebruik omvat het geheugen dat wordt gebruikt door de huidige container-app en ook de relevante pods, zoals interne sidecarcontainers. KEDA bevat ingebouwde configuratie om te voorkomen dat de container-app flapt. Zie Schaalregels instellen in Azure Container Apps voor meer informatie over interne instellingen. Controleer het gedrag tijdens runtime om ervoor te zorgen dat het voldoet aan uw behoeften.

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"

Triggerschaal op basis van metrische Java-gegevens

KEDA biedt een Azure Monitor-scaler, waarmee u kunt schalen op basis van metrische gegevens die beschikbaar zijn in Azure Monitor. U kunt deze functie gebruiken om uw toepassingen dynamisch te schalen op basis van Java-specifieke metrische gegevens die zijn gepubliceerd naar Azure Monitor.

Vereisten

Een clienttoepassing registreren in Microsoft Entra ID. Zie voor meer informatie Snelle start: een toepassing registreren bij het Microsoft-identiteitsplatform.
Machtigingen verlenen. Wijs de geregistreerde toepassing de Monitoring Reader rol toe voor uw Azure Container Apps-resource.

Stappen

Geheimen toevoegen. Gebruik de volgende opdracht om de client-id en het geheim van de Microsoft Entra-toepassing op te slaan in Azure Container Apps als geheimen:

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

Definieer een schaalregel. Gebruik de volgende opdracht om een aangepaste schaalregel te maken die gebruikmaakt van de Azure Monitor-schaalaanpassing. Met deze regel worden schaalacties geactiveerd op basis van een specifieke Java-metrische gegevens, zoals JvmThreadCountbewaakt via 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"

Belangrijke details

Geheimenbeheer: de referenties van de toepassing - client-id en wachtwoord - worden veilig opgeslagen als geheimen.
Schaalcriteria: de metricName parameter identificeert de Java-metrische gegevens ( JvmThreadCount in dit geval ) die worden gebruikt om te evalueren wanneer schalen moet plaatsvinden.
Doelwaarde: Met de targetValue parameter wordt de drempelwaarde voor schalen ingesteld, bijvoorbeeld wanneer het aantal threads groter is dan 30.

Door deze regel in te stellen, kan uw container-app het aantal exemplaren dynamisch aanpassen op basis van Java-specifieke prestatiemetrieken, waardoor de reactiesnelheid en het resourcegebruik worden verbeterd.

Delen via

Overzicht van toepassingsmigratie

Vereisten

Een app implementeren

Omgevingsvariabelen

Geheimen

JVM-opties

Storage

Beheerde identiteit

Statuscontroles

Schaal wijzigen

Triggerschaal op basis van CPU of geheugen

Triggerschaal op basis van metrische Java-gegevens

Vereisten

Stappen

Belangrijke details

Feedback

Aanvullende resources