Teilen über


Bereitstellen von Azure Container Apps

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 Überlegungen bei der Erstellung von Azure Container Apps-Instanzen.

In Azure Spring Apps werden Anwendungen in einer Dienstinstanz bereitgestellt, die eine vollständig verwaltete Plattform bereitstellt. Ebenso werden Container-Apps in Azure Container Apps in einer Azure Container Apps-Umgebung erstellt, die als Basishost für Anwendungen dient. Zwar stellen beide Dienste Hostingumgebungen bereit, diese unterscheiden sich jedoch in verschiedenen Aspekten, z. B. bei Preismodellen, Wartung, regionaler Unterstützung und Verwaltungsvorgängen. In diesem Artikel werden diese Unterschiede erläutert und Leitfäden zum Erstellen und Verwalten von Azure Container Apps-Umgebungen bereitgestellt.

Voraussetzungen

Azure Container Apps-Umgebung erstellen

Verwenden Sie den folgenden Befehl, um die Azure Container Apps-Umgebung zu erstellen:

az containerapp env create \
    --resource-group $RESOURCE_GROUP \
    --name $ENVIRONMENT \
    --location "$LOCATION"

Weitere Konfigurationsoptionen finden Sie unter CLI-Befehle für Azure Container Apps.

Nach dem Erstellen der Umgebung können Sie darin eine Container-App bereitstellen. Einen ausführlichen Leitfaden finden Sie im Schnellstart: Bereitstellen Ihrer ersten Container-App über das Azure-Portal.

Hinweis

Container Apps-Umgebungen werden automatisch gelöscht, wenn sie bestimmte Bedingungen erfüllen, z. B. wenn eine Umgebung länger als 90 Tage im Leerlauf ist. Eine vollständige Liste der Bedingungen finden Sie unter Azure Container Apps-Umgebungen im Abschnitt Richtlinien.

Unterstützung für Regionen

Die derzeit von Azure Container Apps unterstützten Regionen stimmen möglicherweise nicht vollständig mit den Regionen überein, die von Azure Spring Apps unterstützt werden. Sie können die aktuelle Verfügbarkeit unter Verfügbare Produkte nach Region überprüfen.

Preise

Bei einer Azure Spring Apps-Instanz basieren die Gebühren auf einem der verfügbaren Pläne: Basic, Standard oder Enterprise. In Azure Container Apps hängt die Preisgestaltung von Ihrem Umgebungstyp und den von Ihnen ausgewählten Workloadprofilen ab.

Umgebungstyp

Es gibt zwei Umgebungstypen in Azure Container Apps: Workload profile und Consumption only. Sie können den Umgebungstyp mithilfe des --enable-workload-profiles-Parameters angeben, wenn Sie Ihre Azure Container Apps-Umgebung erstellen. Standardmäßig wird --enable-workload-profiles beim Erstellen einer Workload profile-Umgebung auf true festgelegt. Wenn Sie stattdessen false festlegen, wird eine Consumption only-Umgebung erstellt.

Workload profile-Umgebungen ermöglichen Ihnen, sowohl Verbrauchs- als auch dedizierte Workloadprofile zu erstellen.

Consumption only-Umgebungen unterstützen die Erstellung von Workloadprofilen nicht.

Weitere Informationen zu Abrechnungsüberlegungen für die verschiedenen Typen finden Sie unter Azure Container Apps-Umgebungen im Abschnitt Typen. Wenn Sie beabsichtigen, Ihr eigenes virtuelles Netzwerk zu verwenden, beachten Sie die in der folgenden Tabelle angegebenen Unterschiede:

Umgebungstyp Unterstützte Plantypen Beschreibung
Workloadprofile Verbrauch, dediziert Unterstützt benutzerdefinierte Routen (User-Defined Routes; UDR), den Ausgang über NAT Gateway und das Erstellen privater Endpunkte in der Container-App-Umgebung. Die minimale erforderliche Subnetzgröße ist /27.
Nur Verbrauch Verbrauch Unterstützt keine benutzerdefinierten Routen (User Defined Routes, UDR), den Ausgang über NAT-Gateway, Peering über ein Remotegateway oder einen anderen benutzerdefinierten Ausgang. Die minimale erforderliche Subnetzgröße ist /23.

Weitere Informationen finden Sie unter Azure Container Apps-Umgebungen.

Workloadprofil

Wenn Sie eine Workload profile-Umgebung erstellen, können Sie das Standardprofil Consumption verwenden oder zusätzliche Dedicated-Profile erstellen, um Ihre spezifischen Anwendungsanforderungen zu erfüllen. In der folgenden Tabelle sind diese Optionen beschrieben:

Profiltyp Beschreibung Mögliche Anwendungen
Verbrauch Automatisch zu jeder neuen Umgebung hinzugefügt Apps, für die keine speziellen Hardwareanforderungen gelten
Dediziert (universell) Ausgleich von Arbeitsspeicher- und Computeressourcen Apps, die mehr CPU- und/oder Arbeitsspeicherressourcen erfordern
Dediziert (arbeitsspeicheroptimiert) Mehr Arbeitsspeicherressourcen Apps, die Zugriff auf umfangreiche Daten bzw. Machine Learning-Modelle im Arbeitsspeicher benötigen oder andere hohe Speicheranforderungen aufweisen
Dediziert (mit GPU-Aktivierung) (Vorschau) GPU-Aktivierung mit mehr Arbeitsspeicher- und Computeressourcen, die in den Regionen „USA, Westen 3“ und „Europa, Norden“ verfügbar sind. Apps, die eine GPU benötigen

Weitere Informationen zu Workloadprofiltypen und -größen finden Sie unter Workloadprofile in Azure Container Apps im Abschnitt Profiltypen.

Geschätzte Kosten

Verwenden Sie den Azure-Preisrechner, um die Kosten für beide Workloadprofiltypen basierend auf den Ressourcenanforderungen Ihrer Anwendung zu schätzen.

Berücksichtigen Sie Skalierungskonfigurationen und Trigger für die automatische Skalierung, da sie erhebliche Auswirkungen auf die Ressourcennutzung haben.

Weitere Informationen finden Sie unter Workloadprofile in Azure Container Apps.

Wartung

Azure Container Apps stellt ordnungsgemäße Neustarts der Anwendungen während einer zugrunde liegenden Wartung sicher. Sie können mit dem folgenden Befehl ein Wartungsfenster für Ihre App-Umgebung einrichten:

az containerapp env maintenance-config add \
    --resource-group <RESOURCE_GROUP> \
    --environment <ENVIRONMENT_NAME> \
    --weekday Monday \
    --start-hour-utc 1 \
    --duration 8

Ähnlich wie beim Feature für die geplante Wartung in Azure Spring Apps können Sie die Wochentage, die Startzeit und die Dauer (mindestens 8 Stunden) in Azure Container Apps festlegen. Container Apps führt nicht kritische Updates gemäß Ihrer Wartungskonfiguration aus.

Hinweis

Uhrzeiten im UTC-Format werden mit dem 24-Stunden-Zeitformat ausgedrückt. Wenn die Startzeit beispielsweise 13.00 Uhr sein soll, legen Sie den start-hour-utc-Wert auf „13“ fest.

Azure Container Apps garantiert, dass die Wartung innerhalb des konfigurierten Wartungsfensters beginnt, aber nicht, dass die Wartung innerhalb des Zeitfensters abgeschlossen wird.

Das konfigurierte Wartungsfenster gilt nur für nicht kritische Updates. Für kritische Updates gilt es nicht.

Weitere Informationen finden Sie unter Geplante Wartung in Azure Container Apps.

Zuverlässigkeit

Unterstützung für Verfügbarkeitszonen

In den meisten Regionen verwenden Azure Spring Apps und Azure Container Apps Verfügbarkeitszonen, sofern diese in der jeweiligen Region verfügbar sind. Eine Liste der Regionen, die Verfügbarkeitszonen unterstützen, finden Sie unter Azure-Dienste mit Unterstützung für Verfügbarkeitszonen. Azure Container Apps bieten unabhängig vom Plantyp die gleiche Zuverlässigkeitsunterstützung.

Um Verfügbarkeitszonen in Azure Container Apps zu aktivieren, müssen Sie beim Erstellen der Container Apps-Umgebung ein virtuelles Netzwerk mit einem verfügbaren Subnetz angeben. In Azure Spring Apps und Azure Container Apps wird derselbe Parameter verwendet, um Zonenredundanz zu aktivieren. Weitere Informationen zum Aktivieren von Verfügbarkeitszonen finden Sie unter Zuverlässigkeit in Azure Container Apps.

Notfallwiederherstellung

Azure Spring Apps und Azure Container Apps verwenden eine einheitliche Strategie für Notfallwiederherstellung und Geschäftskontinuität. Weitere Informationen finden Sie unter Zuverlässigkeit in Azure Container Apps im Abschnitt Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität.

Bekannte Einschränkungen

  • Start/Stopp: Mit Azure Spring Apps können Sie die gesamte Dienstinstanz oder einzelne Apps starten und beenden. Im Gegensatz dazu unterstützt Azure Container Apps Start-/Stoppfunktionen nur auf Container-App-Ebene, nicht für die gesamte Umgebung.
  • Löschen: Wenn Sie eine Azure Spring Apps-Dienstinstanz löschen, werden automatisch auch alle zugrunde liegenden Ressourcen entfernt. Im Gegensatz dazu müssen Sie bei Azure Container Apps zunächst die Unterressourcen löschen (z. B. alle Container-Apps), bevor Sie die Container Apps-Umgebung löschen.