Přehled migrace aplikací

Poznámka:

Plány Basic, Standarda Enterprise vstoupily do důchodového období 17. března 2025. Další informace najdete v oznámení o vyřazení Azure Spring Apps.

Tento článek se vztahuje na:✅ Basic/Standard ✅ Enterprise

Tento článek obsahuje přehled přístupu k migraci aplikací z Azure Spring Apps do Azure Container Apps.

Požadavky

Existující instance Azure Spring Apps.
Existující aplikace kontejneru Azure. Další informace najdete v článku Rychlý start: Nasazení první aplikace kontejneru s využitím webu Azure Portal.

Nasazení aplikace

Azure Container Apps umožňuje nasazení z registrů kontejnerů, jako je Azure Container Registry (ACR) nebo Docker Hub. Pro nasazení můžete použít nástroje, jako je Azure Portal, Azure CLI nebo jiné. Následující příklad ukazuje, jak nasadit aplikaci do cílového spravovaného prostředí my-container-apps. Další informace najdete v tématu Nasazení první aplikace kontejneru pomocí containerapp upu nebo nasazení první aplikace kontejneru pomocí webu 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 teď nabízí funkci Preview pro aplikace v Javě. Tato funkce umožňuje uživatelům nasazovat aplikace přímo ze souboru JAR nebo zdrojového kódu z místního nebo úložiště kódu. Důrazně doporučujeme nasadit kontejnerové aplikace pomocí kontejnerového obrazu.

Proměnné prostředí

Azure Container Apps umožňuje konfigurovat proměnné prostředí. Můžete je nastavit při vytváření nové aplikace nebo později vytvořením nové revize.

Pokud chcete změnit proměnné prostředí prostřednictvím webu Azure Portal, musíte explicitně vytvořit novou revizi. Když používáte Azure CLI, můžete aplikaci aktualizovat pomocí příkazu az containerapp update, jak je znázorněno v následujícím příkladu, který automaticky vytvoří novou revizi. Je důležité neduplikovat proměnné prostředí. Pokud má více proměnných stejný název, projeví se pouze poslední proměnná v seznamu.

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

Azure Container Apps také poskytuje integrované proměnné prostředí. Tyto proměnné nabízejí užitečná metadata platformy během běhu. Další informace najdete v části Předdefinované proměnné prostředí v tématu Správa proměnných prostředí v Azure Container Apps.

Tajné kódy

Azure Container Apps pomáhá bezpečně ukládat citlivé hodnoty konfigurace, označované jako tajné kódy. Tyto tajné kódy jsou definovány na úrovni aplikace jako páry název/hodnota a jsou přístupné všem revizím aplikace kontejneru.

Doporučujeme ukládat tajné kódy ve službě Azure Key Vault, místo abyste je museli zadávat přímo. Na hodnotu každého tajného kódu ze služby Azure Key Vault můžete odkazovat pomocí jednoho z následujících formátů:

https://myvault.vault.azure.net/secrets/mysecret odkazuje na nejnovější verzi tajného kódu.
https://myvault.vault.azure.net/secrets/mysecret/<version-ID> odkazuje na konkrétní verzi tajného kódu.

Pro tento přístup musíte pro aplikaci kontejneru povolit spravovanou identitu a udělit jí přístup ke službě Key Vault. Zásady přístupu ve službě Key Vault by měly aplikaci GET umožnit získání tajných kódů. Případně pokud Key Vault používá řízení přístupu na základě role Azure, musíte přiřadit Key Vault Secrets User roli. Po nastavení spravované identity můžete do aplikace přidat odkaz na key Vault jako tajný klíč zadáním identifikátoru URI tajného kódu. Pak může aplikace načítat tajemství za běhu pomocí spravované identity.

Mějte na paměti následující pravidla:

Odebrání nebo změna tajného kódu nemá automaticky vliv na existující revize. Když aktualizujete nebo odstraňujete tajné kódy, musíte buď nasadit novou revizi, nebo restartovat existující verzi, aby se projevily změny.
Tajné kódy můžete použít také v rámci pravidel škálování.

Tajné kódy můžete v kontejnerových aplikacích použít tak, že na ně odkazujete v proměnných prostředí nebo je můžete připojit ve svazcích. V proměnných prostředí se hodnota tajného kódu vyplní automaticky. Případně můžete tajné kódy připojit ke svazkům. V tomto případě se každý tajný klíč uloží jako soubor s názvem tajného kódu jako názvem souboru a hodnotou tajného kódu jako obsah souboru. Tato flexibilita umožňuje bezpečně zpracovávat tajné kódy a přistupovat k nim v prostředí aplikace. Další informace najdete v tématu Správa tajných kódů v Azure Container Apps.

Pokud vaše úloha zabezpečuje citlivou konfiguraci a načítá vlastnosti z trezoru klíčů s knihovnou spring-cloud-azure-starter-keyvault-secrets , můžete v Azure Container Apps použít sadu Azure SDK nebo Spring KeyVault PropertySource . Během migrace nemusíte měnit kód.

Možnosti prostředí JVM

Pokud chcete zobrazit možnosti prostředí JVM v Azure Container Apps, postupujte podle kroků v části Vytvoření image kontejneru z JAR nebo WAR abyste kontejnerizovali svou aplikaci. Do -XX:+PrintFlagsFinal svého souboru Dockerfile můžete přidat ENTRYPOINT, jak je znázorněno v následujícím příkladu:

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

Pokud chcete dotazovat možnosti JVM v Azure Container Apps, použijte následující dotaz:

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

Následující protokol je příkladem, který zobrazuje možnosti JVM po spuštění dotazu:

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

Pokud chcete upravit možnosti JVM v Azure Container Apps, můžete do souboru Dockerfile přidat možnosti ENTRYPOINT JVM, jak je znázorněno v následujícím příkladu:

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

Další informace o možnostech prostředí JVM naleznete v tématu Java HotSpot VM Options and Configuring JVM Options.

Storage

Azure Spring Apps i Azure Container Apps podporují úložiště v rozsahu kontejneru, což znamená, že data uložená v kontejneru jsou dostupná jenom v době, kdy je kontejner spuštěný. Pro Azure Spring Apps je celkové úložiště pro aplikaci 5 GiB. Azure Container Apps nabízí úložiště, které se pohybuje od 1 GiB do 8 GiB v závislosti na celkovém počtu přidělených vCPU. Toto úložiště zahrnuje veškeré dočasné úložiště přiřazené ke každé replice. Další informace najdete v části Dočasné úložiště části Použití připojení úložiště v Azure Container Apps.

Azure Spring Apps i Azure Container Apps podporují trvalé úložiště prostřednictvím služby Azure Files. Azure Container Apps podporuje připojení sdílených složek pomocí protokolů SMB a NFS. Ve spravovaném prostředí je potřeba vytvořit definici úložiště a pak v revizi definovat svazek souborů AzureFile (SMB) nebo NfsAzureFile (NFS). Celou konfiguraci pro AzureFile (SMB) můžete dokončit na webu Azure Portal. Další informace najdete v tématu Vytvoření svazku Azure Files v Azure Container Apps. Podpora připojení sdílených složek NFS je aktuálně ve verzi Preview. Můžete ho nakonfigurovat pomocí Azure CLI nebo šablony ARM. Další informace najdete v tématu Sdílené složky Azure NFS a část Vytvoření sdílené složky Azure NFS v části Vytvoření klasické sdílené složky Azure.

Spravovaná identita

Každá aplikace kontejneru má spravovanou identitu přiřazenou systémem nebo spravované identity přiřazené uživatelem pro přístup k chráněným prostředkům Azure. Informace o správě identit a udělování oprávnění najdete v tématu Spravované identity v Azure Container Apps.

Každá aplikace kontejneru má interní koncový bod REST přístupný prostřednictvím IDENTITY_ENDPOINT proměnné prostředí, která se liší od koncového bodu používaného v Azure Spring Apps. Pokud vaše aplikace používá přímý požadavek HTTP GET , musíte upravit kód, aby získal správný koncový bod. Pokud vaše aplikace používá spravovanou identitu prostřednictvím klientské knihovny Azure Identity, nepotřebujete žádné změny kódu, protože azure Identity tyto podrobnosti spravuje automaticky.

Když úloha přistupuje k chráněným prostředkům Azure, musí načíst přístupový token pomocí ID aplikace nebo ID klienta spravované identity. V prostředí Azure Spring Apps můžete nastavit ID klienta spravované identity přiřazené systémem nebo přiřazené uživatelem. Případně ji můžete nechat prázdnou a nechat službu vybrat ID aplikace z jedné ze spravovaných identit. V Azure Container Apps nemůžete explicitně zadat ID aplikace při použití spravované identity přiřazené systémem. ID aplikace se však vyžaduje při použití spravované identity přiřazené uživatelem.

Sondy stavu

Azure Container Apps i Azure Spring Apps podporují všechny tři typy sond stavu, včetně spouštěcí sondy, sondy životnosti a sondy připravenosti. Pro Azure Container Apps můžou sondy používat protokol HTTP nebo TCP. exec zatím se nepodporuje.

Nastavení sondy v Azure Spring Apps se konfiguruje na prostředku nasazení. Naproti tomu pro Azure Container Apps se nastavení sondy definuje v prostředku kontejnerové aplikace. K dispozici jsou následující nastavení:

Vlastnost	Popis	Azure Spring Apps	Azure Container Apps
`probeAction`	Činnost sondy.	Podporuje `HTTPGetAction`, `TCPSocketAction`a `ExecAction`.	Typ akce neobsahuje žádné vlastnosti. Uživatel musí použít buď `httpGet` nebo `tcpSocket` přímo.
`disableProbe`	Určuje, jestli je sonda deaktivovaná.	logický	logický
`initialDelaySeconds`	Počet sekund po spuštění instance aplikace před zahájením sond.		Hodnota se pohybuje od 1 do 60.
`periodSeconds`	Jak často v sekundách má být sonda prováděna.	Minimální hodnota je 1.	Hodnota se pohybuje od 1 do 240 s výchozí hodnotou 10.
`timeoutSeconds`	Počet sekund, po kterých vyprší časový limit sondy.	Minimální hodnota je 1.	Hodnota se pohybuje od 1 do 240 s výchozí hodnotou 1.
`failureThreshold`	Minimální počet po sobě jdoucích selhání pro považování sondy za selhanou po předchozím úspěchu.	Minimální hodnota je 1.	Hodnota se pohybuje od 1 do 10 s výchozí hodnotou 3.
`successThreshold`	Minimální počet po sobě jdoucích úspěchů pro to, aby byla sonda považována za úspěšnou po selhání.	Minimální hodnota je 1.	Hodnota je v rozsahu od 1 do 10 s výchozí hodnotou 1.
`terminationGracePeriodSeconds`	Volitelná doba trvání v sekundách, během které se pod má řádně ukončit při selhání sondy.	Výchozí hodnota je 90 sekund.	Maximální hodnota je 3600 sekund.

V současné době nemůžete nakonfigurovat sondy pro Azure Container Apps přímo na webu Azure Portal. Místo toho je potřeba je nastavit pomocí šablony ARM nebo souboru YAML kontejnerové aplikace prostřednictvím Azure CLI. Další informace najdete v tématu Zdravotní sondy v Azure Container Apps.

Měřítko

Azure Container Apps podporuje horizontální škálování prostřednictvím sady pravidel škálování. Při přidání nebo změně pravidla se vytvoří nová revize aplikace kontejneru.

Škálování má tři kategorie triggerů, HTTP, TCP a vlastní. Http a TCP jsou založené na počtu požadavků nebo síťových připojení. Další informace najdete v tématu Nastavení pravidel škálování ve službě Azure Container Apps.

Aktivace škálování na základě procesoru nebo paměti

Pravidla škálování vlastních aplikací kontejnerů jsou založená na škálovacím nástroji KEDA založeném na ScaledObjectu. Škálování aplikacemi v kontejnerech můžete dosáhnout pomocí škálovačů KEDA, a to na základě využití procesoru nebo paměti: škálovač CPU a škálovač paměti.

Následující příklad ukazuje konfiguraci, ve které dochází k horizontálnímu navýšení kapacity, když průměrné využití paměti překročí 25 %. Využití paměti zahrnuje paměť používanou aktuální kontejnerovou aplikací a také relevantní pody, jako jsou interní sidecar kontejnery. KEDA obsahuje integrovanou konfiguraci, která brání kolísání kontejnerové aplikace. Další informace o interních nastaveních najdete v tématu Nastavení pravidel škálování v Azure Container Apps. Měli byste ověřit chování během běhu, abyste měli jistotu, že splňuje vaše potřeby.

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"

Aktivace škálování na základě metrik Javy

KEDA nabízí škálovač Azure Monitoru, který umožňuje škálování na základě metrik dostupných ve službě Azure Monitor. Tuto funkci můžete použít k dynamickému škálování aplikací na základě metrik specifických pro Javu publikovaných ve službě Azure Monitor.

Požadavky

Registrace aplikace v Microsoft Entra ID. Další informace naleznete v tématu Rychlý start: registrace aplikace pomocí platformy identity Microsoft.
Udělte oprávnění. Přiřaďte zaregistrované aplikaci roli Monitoring Reader pro prostředek Azure Container Apps.

Kroky

Přidejte tajné kódy. Pomocí následujícího příkazu uložte ID klienta a tajný kód aplikace Microsoft Entra ve službě Azure Container Apps jako tajné kódy:

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

Definujte pravidlo škálování. Pomocí následujícího příkazu vytvořte vlastní pravidlo škálování, které používá škálovací nástroj služby Azure Monitor. Toto pravidlo aktivuje akce škálování na základě konkrétní metriky Javy, jako je například JvmThreadCount, monitorovaná prostřednictvím služby 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"

Klíčové podrobnosti

Správa tajných kódů: Přihlašovací údaje aplikace – ID klienta a heslo – jsou bezpečně uložené jako tajné kódy.
Kritéria škálování: Parametr metricName identifikuje metriku Java – JvmThreadCount v tomto případě – která se používá k vyhodnocení, kdy by mělo dojít ke škálování.
Cílová hodnota: Parametr targetValue nastaví prahovou hodnotu pro škálování – například škálování, když počet vláken překročí 30.

Nastavením tohoto pravidla může vaše aplikace kontejneru dynamicky upravit počet instancí na základě metrik výkonu specifických pro Javu, což zlepšuje rychlost odezvy a využití prostředků.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-08-19

Sdílet prostřednictvím

Přehled migrace aplikací

Požadavky

Nasazení aplikace

Proměnné prostředí

Tajné kódy

Možnosti prostředí JVM

Storage

Spravovaná identita

Sondy stavu

Měřítko

Aktivace škálování na základě procesoru nebo paměti

Aktivace škálování na základě metrik Javy

Požadavky

Kroky

Klíčové podrobnosti

Váš názor

Další materiály