Azure Container Apps

Azure Container Apps (ACA) ist ein vollständig verwalteter, serverloser Dienst zum Hosten von Containern, der auf Kubernetes und KEDA (Kubernetes Event-Driven Autoscaling) basiert. Anders als bei AKS müssen Sie weder die Steuerungsebene noch Knotenpools oder Kubernetes-Manifeste direkt verwalten. Stattdessen stellen Sie Container über eine einfache CLI oder YAML-Definition bereit, und Azure übernimmt die gesamte Orchestrierung. ACA eignet sich ideal für Microservices, API-Backends, ereignisgesteuerte Worker und Hintergrundverarbeitungsaufgaben, die dynamisch skaliert werden müssen, einschließlich der Skalierung auf null.

Eine Container Apps-Umgebung ist die isolierte Grenze, innerhalb derer eine oder mehrere Container Apps ausgeführt werden. Alle Apps in einer Umgebung verwenden dasselbe virtuelle Netzwerk und denselben Log Analytics-Arbeitsbereich. Umgebungen sind auf eine Region und eine Ressourcengruppe begrenzt. Sie können mehrere Umgebungen bereitstellen, um Teams oder Phasen voneinander zu isolieren (Produktion und Staging). Eine Umgebung kann optional per VNet-Injection in Ihr eigenes virtuelles Netzwerk integriert werden, damit Container Apps und andere Azure-Dienste ohne Nutzung des öffentlichen Internets privat kommunizieren können.

Um eine Container App bereitzustellen, geben Sie das Containerimage (aus Azure Container Registry oder einer beliebigen öffentlichen Registry), die Anzahl der Replikate und Umgebungsvariablen an. Wenn Sie externen Ingress aktivieren, ist die App über eine automatisch generierte HTTPS-URL öffentlich erreichbar. Die Ingress-Konfiguration umfasst den Zielport, die Aufteilung des Datenverkehrs für Blue-Green-Bereitstellungen und die Festlegung, ob nur HTTP oder HTTPS zulässig ist. ACA ruft das Image zum Zeitpunkt der Bereitstellung ab. Die Umgebung muss über Abrufberechtigungen für die Registry verfügen.

Container Apps skaliert mithilfe von KEDA-Scalern, die auf Grundlage externer Metriken ausgelöst werden. Zu den integrierten KEDA-Scalern gehören: HTTP-Datenverkehr (gleichzeitige Anforderungen pro Replikat), Azure Service Bus-Warteschlangentiefe (wartende Nachrichten), Azure Storage Queue, Cron (zeitbasiert) und CPU/Speicher. Wenn die Scaler-Metrik auf null fällt und minReplicas auf 0 gesetzt ist, skaliert Container Apps auf null – dadurch entstehen keine Compute-Kosten, bis neue Anforderungen eingehen. Die Skalierung auf null eignet sich hervorragend für ereignisgesteuerte Worker mit unregelmäßiger Auslastung.

Dapr (Distributed Application Runtime) ist eine portable, ereignisgesteuerte Laufzeitumgebung, die die Entwicklung von Microservices vereinfacht. Container Apps bietet eine native Dapr-Integration – Sie aktivieren sie pro App mit einem einzigen Flag. Dapr stellt Bausteine bereit für: Dienstaufrufe (mit Wiederholungsversuchen und mTLS), Pub/Sub-Nachrichtenübermittlung (Abstraktion von Service Bus und Event Hubs), Zustandsverwaltung (Abstraktion von Redis und Cosmos DB) sowie Ausgabebindings. Mit Dapr kommunizieren Microservices über den Dapr-Sidecar, ohne die Details der zugrunde liegenden Infrastruktur kennen zu müssen.

Jede Bereitstellung einer Container App erstellt eine neue Revision. Im Modus mit mehreren Revisionen können Sie den Datenverkehr für Blue-Green- oder Canary-Bereitstellungen auf mehrere Revisionen aufteilen. Beispielsweise können Sie 10 % des Datenverkehrs an eine neue Revision und 90 % an die aktuelle stabile Revision senden. Überwachen Sie Fehlerraten und Latenz der neuen Revision, bevor Sie deren Datenverkehrsanteil auf 100 % erhöhen. Alte Revisionen können deaktiviert werden, bleiben jedoch im Verlauf erhalten. Dadurch ist ein sofortiges Rollback möglich, indem der Datenverkehrsanteil wieder zurückgesetzt wird.

Container Apps unterstützt zwei Möglichkeiten zum Einbinden von Konfigurationen: Umgebungsvariablen (für nicht vertrauliche Konfigurationen wie Featureflags oder API-URLs) und Geheimnisse (für vertrauliche Werte wie Verbindungszeichenfolgen). Geheimnisse werden auf der Ebene der Container App gespeichert und über Umgebungsvariablen oder Dapr-Komponenten referenziert. Für die sicherste Konfiguration referenzieren Sie Geheimnisse aus Azure Key Vault mithilfe einer verwalteten Identität, sodass der geheime Wert zur Laufzeit abgerufen und niemals in der Konfigurationsebene der Container App gespeichert wird.

Container Apps Jobs erweitern die Plattform um Unterstützung für Workloads mit Ausführung bis zum Abschluss – Container, die gestartet werden, ihre Aufgabe erledigen und beendet werden. Jobs unterstützen drei Trigger-Typen: Manuell (über API oder CLI ausgelöst), Geplant (Cron-Ausdruck) und Ereignisgesteuert (der KEDA-Scaler löst jede Ausführung aus). Jobs werden nur für die tatsächliche Ausführungszeit abgerechnet und eignen sich ideal für die Batchverarbeitung, die Berichtserstellung, Datenbankmigrationen und ML-Inferenzpipelines, die regelmäßig oder als Reaktion auf Ereignisse ausgeführt werden.

Container Apps sendet Systemlogs (Plattformereignisse wie die Erstellung von Revisionen und die Skalierung) sowie Konsolenlogs (die stdout/stderr-Ausgabe Ihrer Anwendung) an den Log Analytics-Arbeitsbereich, der mit der Umgebung verknüpft ist. Fragen Sie Logs mit KQL ab: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Zu den integrierten Azure Monitor-Metriken gehören die Anzahl der Replikate, die Anzahl der Anforderungen, die Anforderungs-Latenz sowie die CPU-/Arbeitsspeicherauslastung pro Replikat – alles ohne zusätzliche Konfiguration im Azure-Portal verfügbar.

Auswahl der richtigen Azure-Containerplattform: Container Apps eignet sich am besten für Microservices, ereignisgesteuerte Worker und APIs, wenn Sie die Vorteile von Kubernetes nutzen möchten, ohne den Cluster verwalten zu müssen – insbesondere, wenn eine Skalierung auf null von Vorteil ist. AKS eignet sich am besten, wenn Sie vollständige Kontrolle über Kubernetes, benutzerdefinierte Operatoren oder bestimmte Knotenkonfigurationen (GPU, hoher Arbeitsspeicher) benötigen. App Service eignet sich am besten für herkömmliche Webanwendungen und APIs, wenn das Entwicklerteam ein einfaches PaaS-Modell ohne den Verwaltungsaufwand für Container bevorzugt. Alle drei unterstützen Container; der Unterschied liegt im Verhältnis zwischen Verwaltungsaufwand und Kontrolle.

Container Apps unterstützt zwei Ingress-Modi: Extern (öffentlich über einen HTTPS-Endpunkt mit Lastenausgleich und automatischem TLS erreichbar) und Intern (nur innerhalb derselben Container-Apps-Umgebung oder von Ressourcen erreichbar, die über VNet-Peering verbunden sind). Interner Ingress wird für Backenddienste verwendet, die niemals dem Internet zugänglich gemacht werden sollen. Apps können sich innerhalb derselben Umgebung über den automatisch generierten internen DNS-Namen http://myapi gegenseitig aufrufen. Dadurch wird eine einfache Kommunikation zwischen Diensten ermöglicht, ohne ein API-Gateway bereitzustellen.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Azure Container Apps bietet serverloses Containerhosting auf Basis von Kubernetes und KEDA, ohne dass ein Cluster verwaltet werden muss; KEDA-Scaler ermöglichen eine Skalierung auf null basierend auf Warteschlangentiefe, HTTP-Datenverkehr oder Cron-Zeitplänen; und die Dapr-Integration vereinfacht die Kommunikation zwischen Microservices und die Zustandsverwaltung. Als Nächstes verbinden wir alle Komponenten zu einem vollständigen End-to-End-Entwicklerworkflow.