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
- Ein aktives Azure-Abonnement. Sollten Sie über keins verfügen, können Sie ein kostenloses Azure-Konto erstellen.
- Azure-Befehlszeilenschnittstelle.
- Der Ressourcenanbieter
Microsoft.App
ist in Ihrem Azure-Abonnement registriert. Weitere Informationen finden Sie unter Azure-Ressourcenanbieter und -typen.
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.