Freigeben über

Übersicht über die Anwendungsmigration

  • Artikel

Hinweis

Die Pläne Basic, Standard und Enterprise gelten ab Mitte März 2025 als veraltet und werden über einen Zeitraum von drei Jahren eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie in der Ankündigung zur Einstellung von Azure Spring Apps.

Der Plan Standardverbrauch und dediziert gilt ab dem 30. September 2024 als veraltet und wird nach sechs Monaten vollständig eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie unter Migrieren des Plans „Standardverbrauch und dediziert“ von Azure Spring Apps zu Azure Container Apps.

Dieser Artikel gilt für:✅ Basic/Standard ✅ Enterprise

Dieser Artikel enthält eine Übersicht über einen App-Migrationsansatz von Azure Spring Apps zu Azure Container Apps.

Voraussetzungen

Bereitstellen von Anwendungen

Mit Azure Container Apps können Sie aus Containerregistrierungen wie Azure Container Registry (ACR) oder Docker Hub bereitstellen. Sie können Tools wie das Azure-Portal, die Azure CLI oder andere Tools für die Bereitstellung verwenden. Das folgende Beispiel zeigt, wie Sie eine Anwendung in der verwalteten Zielumgebung my-container-apps bereitstellen. Weitere Informationen finden Sie unter Bereitstellen Ihrer ersten Container-App mit containerapp up oder Bereitstellen Ihrer ersten Container-App mithilfe des Azure-Portals.

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 bietet jetzt ein Vorschaufeature für Java-Anwendungen. Mit diesem Feature können Benutzer Anwendungen direkt aus einer JAR-Datei oder einem Quellcode aus dem lokalen oder einem Code-Repository bereitstellen. Es wird dringend empfohlen, Container Apps mithilfe eines Containerimages bereitzustellen.

Umgebungsvariablen

Mit Azure Container Apps können Sie Umgebungsvariablen konfigurieren. Sie können diese einrichten, wenn Sie eine neue App erstellen oder später, indem Sie eine neue Überarbeitung erstellen.

Um Umgebungsvariablen über das Azure-Portal zu ändern, müssen Sie eine neue Revision explizit erstellen. Bei Verwendung der Azure CLI können Sie die App mit dem Befehl az containerapp update aktualisieren, wie im folgenden Beispiel gezeigt, wodurch automatisch eine neue Überarbeitung erstellt wird. Es ist wichtig, keine Umgebungsvariablen zu duplizieren. Wenn mehrere Variablen denselben Namen haben, wird nur die letzte in der Liste wirksam.

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

Azure Container Apps bieten auch integrierte Umgebungsvariablen. Diese Variablen bieten während der Laufzeit nützliche Plattformmetadaten. Weitere Informationen finden Sie im Abschnitt Integrierte Umgebungsvariablen unter Verwalten von Umgebungsvariablen in Azure Container Apps.

Geheimnisse

Azure Container Apps hilft beim sicheren Speichern vertraulicher Konfigurationswerte, die als geheime Schlüssel bezeichnet werden. Diese geheimen Schlüssel werden auf Anwendungsebene als Name/Wert-Paare definiert und können für alle Container-App-Überarbeitungen zugänglich sein.

Es wird empfohlen, geheime Schlüssel in Azure Key Vault zu speichern, anstatt sie direkt einzugeben. Sie können mit einem der folgenden Formate auf den Wert jedes geheimen Schlüssels aus Azure Key Vault verweisen:

  • https://myvault.vault.azure.net/secrets/mysecret verweist auf die neueste Version eines Geheimnisses.
  • https://myvault.vault.azure.net/secrets/mysecret/<version-ID> verweist auf eine bestimmte Version eines Geheimnisses.

Für diesen Ansatz müssen Sie die verwaltete Identität für Ihre Container-App aktivieren und ihm Zugriff auf Key Vault gewähren. Die Zugriffsrichtlinie in Key Vault sollte es der App ermöglichen, GET zu verwenden, um geheime Schlüssel abzurufen. Wenn Key Vault die rollenbasierte Zugriffssteuerung von Azure verwendet, müssen Sie eine Key Vault Secrets User-Rolle zuweisen. Nachdem Sie verwaltete Identität eingerichtet haben, können Sie einen Key Vault-Verweis als geheimen Schlüssel in Ihrer App hinzufügen, indem Sie den URI des geheimen Schlüssels angeben. Anschließend kann die App den geheimen Schlüssel zur Laufzeit mithilfe der verwalteten Identität abrufen.

Beachten Sie die folgenden Regeln:

  • Das Entfernen oder Ändern eines geheimen Schlüssels wirkt sich nicht automatisch auf vorhandene Überarbeitungen aus. Wenn Sie geheime Schlüssel aktualisieren oder löschen, müssen Sie entweder eine neue Revision bereitstellen oder eine vorhandene neu starten, um die Änderungen widerzuspiegeln.
  • Sie können geheime Schlüssel auch innerhalb von Skalierungsregeln verwenden.

Sie können geheime Schlüssel in Container Apps verwenden, indem Sie sie in Umgebungsvariablen referenzieren oder in Volumes einbinden. In Umgebungsvariablen wird der Wert des geheimen Schlüssels automatisch ausgefüllt. Alternativ können Sie geheime Schlüssel in Volumes bereitstellen. In diesem Fall wird jeder geheime Schlüssel als Datei mit dem geheimen Namen als Dateiname und dem geheimen Wert als Inhalt der Datei gespeichert. Mit dieser Flexibilität können Sie geheime Schlüssel sicher verarbeiten und innerhalb der App-Umgebung darauf zugreifen. Weitere Informationen finden Sie unter Verwalten von geheimen Schlüsseln in Azure Container Apps.

Wenn Ihre Workload vertrauliche Konfigurationen sichert und Eigenschaften aus dem Key Vault mithilfe der spring-cloud-azure-starter-keyvault-secrets-Bibliothek abruft, können Sie entweder das Azure SDK oder den Spring KeyVault PropertySource in Azure Container Apps verwenden. Sie müssen den Code während der Migration nicht ändern.

JVM-Optionen

Um die JVM-Optionen in Azure Container Apps zu drucken, führen Sie die Schritte im Build Container Image von einem JAR oder WAR aus, um Ihre Anwendung zu containerisieren. Sie können -XX:+PrintFlagsFinal in dem ENTRYPOINT Ihrer Dockerfile-Datei hinzufügen, wie im folgenden Beispiel gezeigt:

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

Verwenden Sie die folgende Abfrage, um JVM-Optionen in Azure Container Apps abzufragen:

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

Das folgende Protokoll ist ein Beispiel für JVM-Optionen nach dem Ausführen einer Abfrage:

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

Um die JVM-Optionen in Azure Container Apps anzupassen, können Sie JVM-Optionen in dem ENTRYPOINT Ihrer Dockerfile-Datei hinzufügen, wie im folgenden Beispiel gezeigt:

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

Weitere Informationen zu JVM-Optionen finden Sie unter Java HotSpot VM-Optionen und Konfigurieren von JVM-Optionen.

Storage

Azure Spring Apps und Azure Container Apps unterstützen den containerbezogenen Speicher. Dies bedeutet, dass die im Container gespeicherten Daten nur verfügbar sind, während der Container ausgeführt wird. Für Azure Spring Apps beträgt der Gesamtspeicher für eine App 5 GiB. Azure Container Apps bieten Speicher, der von 1 GiB bis 8 GiB reicht, abhängig von der Gesamtanzahl der zugewiesenen vCPUs. Dieser Speicher enthält alle kurzlebigen Speicher, die jedem Replikat zugewiesen sind. Weitere Informationen finden Sie im Abschnitt Ephemeral Storage in Verwenden von Speichereinbindungen Azure Container Apps.

Azure Spring Apps und Azure Container Apps unterstützen den dauerhaften Speicher über Azure Files. Azure Container Apps unterstützt die Bereitstellung von Dateifreigaben mithilfe der SMB- und NFS-Protokolle. Sie müssen eine Speicherdefinition in der verwalteten Umgebung erstellen und dann ein Volume von AzureFile (SMB) oder NfsAzureFile (NFS) in einer Überarbeitung definieren. Sie können die gesamte Konfiguration für AzureFile (SMB) im Azure-Portal abschließen. Weitere Informationen finden Sie unter Erstellen einer Azure Files-Volumeeinbindung in Azure Container Apps. Unterstützung für die Einbindung von NFS-Freigaben befindet sich derzeit in der Vorschau. Sie können sie mithilfe der Azure CLI oder einer ARM-Vorlage konfigurieren. Weitere Informationen finden Sie unter NFS Azure-Dateifreigaben und im Abschnitt Erstellen einer NFS Azure-Dateifreigabe des Tutorial: Erstellen einer NFS Azure-Dateifreigabe und Bereitstellen auf einer Linux-VM mithilfe des Azure-Portals.

Verwaltete Identität

Jede Container-App verfügt über eine vom System zugewiesene verwaltete Identität oder vom Benutzer zugewiesene verwaltete Identitäten für den Zugriff auf geschützte Azure-Ressourcen. Informationen zum Verwalten von Identitäten und Erteilen von Berechtigungen finden Sie unter Verwaltete Identitäten in Azure Container Apps.

Jede Container-App verfügt über einen internen REST-Endpunkt, auf den über die IDENTITY_ENDPOINT-Umgebungsvariable zugegriffen werden kann, die sich vom in Azure Spring Apps verwendeten Endpunkt unterscheidet. Wenn Ihre App eine direkte HTTP-GET-Anforderung verwendet, müssen Sie den Code anpassen, um den richtigen Endpunkt abzurufen. Wenn Ihre App eine verwaltete Identität über die Azure Identity-Clientbibliothek verwendet, benötigen Sie keine Codeänderungen, da Azure Identity diese Details automatisch verwaltet.

Wenn eine Workload auf geschützte Azure-Ressourcen zugreift, muss ein Zugriffstoken mithilfe der Anwendungs-ID oder Client-ID einer verwalteten Identität abgerufen werden. In einer Azure Spring Apps-Umgebung können Sie die Client-ID einer vom System zugewiesenen oder vom Benutzer zugewiesenen verwalteten Identität festlegen. Alternativ können Sie sie leer lassen und dem Dienst die Anwendungs-ID aus einer der verwalteten Identitäten auswählen. In Azure Container Apps können Sie die Anwendungs-ID bei Verwendung einer vom System zugewiesenen verwalteten Identität nicht explizit angeben. Die Anwendungs-ID ist jedoch erforderlich, wenn eine vom Benutzer zugewiesene verwaltete Identität verwendet wird.

Integritätstests

Azure Container Apps und Azure Spring Apps unterstützen beide alle drei Arten von Integritätstests, einschließlich Starttest, Livetest und Bereitschaftstest. Für Azure Container Apps können Tests entweder das HTTP- oder TCP-Protokoll verwenden. exec wird noch nicht unterstützt.

In Azure Spring Apps werden Testeinstellungen für die Bereitstellungsressource konfiguriert. Im Gegensatz dazu werden für Azure Container Apps Testeinstellungen für die Container-App-Ressource definiert. Die folgenden Einstellungen sind verfügbar:

Eigenschaft Beschreibung Azure Spring Apps Azure Container Apps
probeAction Die Aktion des Tests. Unterstützt HTTPGetAction, TCPSocketAction und ExecAction. Es gibt keine Eigenschaften für den Aktionstyp. Der Benutzer muss entweder httpGet oder tcpSocket direkt verwenden.
disableProbe Gibt an, ob der Test deaktiviert ist. Boolean Boolean
initialDelaySeconds Die Anzahl von Sekunden, die nach dem Start der App-Instanz vergehen, bevor Tests initiiert werden. Der Wert liegt zwischen 1 und 60.
periodSeconds Gibt an, wie häufig (in Sekunden) ein Test durchgeführt werden soll. Der Mindestwert ist 1. Der Wert liegt zwischen 1 und 240, wobei der Standardwert 10 ist.
timeoutSeconds Die Anzahl der Sekunden, nach denen der Test eine Zeitüberschreitung aufweist. Der Mindestwert ist 1. Der Wert reicht von 1 bis 240, wobei der Standardwert 1 ist.
failureThreshold Die Mindestanzahl aufeinander folgender Fehler, nach denen ein erfolgreicher Test als nicht erfolgreich betrachtet werden soll. Der Mindestwert ist 1. Der Wert reicht von 1 bis 10, wobei der Standardwert 3 ist.
successThreshold Die Anzahl der Erfolge, die mindestens aufeinander folgen müssen, damit ein Test nach einem Fehler wieder als erfolgreich betrachtet wird. Der Mindestwert ist 1. Der Wert reicht von 1 bis 10, wobei der Standardwert 1 ist.
terminationGracePeriodSeconds Die optionale Dauer in Sekunden, die der Test benötigt, um bei einem Testfehler ordnungsgemäß zu beenden. Der Standardwert beträgt 90 Sekunden. Der Maximalwert beträgt 3600 Sekunden.

Derzeit können Sie die Tests für Azure Container Apps nicht direkt im Azure-Portal konfigurieren. Stattdessen müssen Sie sie entweder mithilfe einer ARM-Vorlage oder einer YAML-Container-App über die Azure CLI einrichten. Weitere Informationen finden Sie unter Integritätstests in Azure Container Apps.

Skalieren

Azure Container Apps unterstützen die horizontale Skalierung über eine Reihe von Skalierungsregeln. Wenn eine Regel hinzugefügt oder geändert wird, wird eine neue Überarbeitung der Container-App erstellt.

Die Skalierung hat drei Kategorien von Triggern, HTTP, TCP und benutzerdefiniert. HTTP und TCP basieren auf der Anzahl der Anforderungs- oder Netzwerkverbindungen. Weitere Informationen finden Sie unter Festlegen von Skalierungsregeln in Azure Container Apps.

Triggerskala basierend auf CPU oder Arbeitsspeicher

Die Skalierungsregeln für benutzerdefinierte Container Apps basieren auf dem ScaledObject-basierten KEDA-Scaler. Sie können die Skalierung mit Container Apps basierend auf der CPU- oder Speicherauslastung über KEDA-CPU-Scaler und Speicherskalierer erreichen.

Im folgenden Beispiel wird eine Konfiguration veranschaulicht, bei der die Skalierung auftritt, wenn die durchschnittliche Speicherauslastung 25 % überschreitet. Die Speicherauslastung umfasst den von der aktuellen Container-App verwendeten Speicher sowie die relevanten Pods, z. B. interne Sidecar-Container. KEDA enthält eine integrierte Konfiguration, um zu verhindern, dass die Container-App flackert. Weitere Informationen zu internen Einstellungen finden Sie unter Festlegen von Skalierungsregeln in Azure Container Apps. Sie sollten das Verhalten während der Laufzeit überprüfen, um sicherzustellen, dass es Ihren Anforderungen entspricht.

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"

Triggerskala basierend auf Java-Metriken

KEDA bietet einen Azure Monitor-Scaler, der die Skalierung basierend auf den in Azure Monitor verfügbaren Metriken ermöglicht. Sie können dieses Feature verwenden, um Ihre Anwendungen dynamisch basierend auf javaspezifischen Metriken zu skalieren, die in Azure Monitor veröffentlicht werden.

Voraussetzungen

Schritte

  1. Hinzufügen von Geheimnissen. Verwenden Sie den folgenden Befehl, um die Client-ID und den geheimen Schlüssel der Microsoft Entra-Anwendung in Azure Container Apps als geheime Schlüssel zu speichern:

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

  2. Definieren Sie eine Skalierungsregel. Verwenden Sie den folgenden Befehl, um eine benutzerdefinierte Skalierungsregel zu erstellen, die den Azure Monitor-Scaler verwendet. Diese Regel löst Skalierungsaktionen basierend auf einer bestimmten Java-Metrik aus, z. B. JvmThreadCount, über Azure Monitor überwacht.

    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"

Schlüsseldetails

  • Geheimnisverwaltung: Die Anmeldeinformationen der Anwendung – Client-ID und Kennwort – werden sicher als geheime Schlüssel gespeichert.
  • Skalierungskriterien: Der metricName-Parameter identifiziert die Java-Metrik (in diesem Fall JvmThreadCount), die verwendet wird, um zu bewerten, wann die Skalierung erfolgen soll.
  • Zielwert: Der targetValue-Parameter legt den Schwellenwert für die Skalierung fest, z. B. die Skalierung, wenn die Threadanzahl 30 überschreitet.

Durch das Einrichten dieser Regel kann Ihre Container-App die Anzahl der Instanzen basierend auf javaspezifischen Leistungsmetriken dynamisch anpassen und die Reaktionsfähigkeit und Ressourcenauslastung verbessern.