Besonderheiten und Hürden von Azure Container Apps

Compute Ressourcen für containerisierte Anwendungen

Teams stehen verschiedene Optionen für die Bereitstellung von containerisierten Anwendungen zur Verfügung, darunter Azure Container Apps, Azure Kubernetes Service (AKS), Azure App Service, Azure Container Instances und weitere Plattformen. Jede dieser Lösungen bringt spezifische Vorteile und Einsatzbereiche mit sich, sodass die Wahl der passenden Technologie stark von den individuellen Anforderungen eines Projekts abhängt.

Azure Container Apps ist eine serverlose Plattform, die sich ideal für Microservices, ereignisgesteuerte Anwendungen und flexible Skalierungsanforderungen eignet. Im Gegensatz dazu bietet AKS eine umfassende Kontrolle über die Kubernetes-Infrastruktur, während Azure App Service speziell für Webanwendungen optimiert ist. Azure Container Instances ermöglichen schnelle und isolierte Bereitstellungen, während Azure Functions auf serverlose, kurzlebige Prozesse fokussiert ist. Weitere Alternativen wie Azure Spring Apps und Azure Red Hat OpenShift richten sich an spezifische Entwicklungsansätze und Unternehmensanforderungen.

In diesem Blogbeitrag erhalten Sie eine detaillierte Übersicht über Azure Container Apps, deren Einsatzmöglichkeiten und besondere Merkmale. Zudem werden die wichtigsten Unterschiede zu anderen Containerlösungen in Azure beleuchtet, sodass Sie eine fundierte Entscheidung für Ihre Cloud-Architektur treffen können.

Für die Verwendung von Azure Container Apps müssen wir zwei wesentlichen Komponenten Verstehen - Azure Container App Environments & Azure Container Apps.

Azure Container App Environments

Azure Container App Environments sind die oberste logische Einheit innerhalb von Azure Container Apps. Sie dienen als übergreifende Ressource zur Verwaltung mehrerer Container-Apps und ermöglichen eine gemeinsame Nutzung von Netzwerk-, Skalierungs- und Konfigurationsoptionen.

Azure Container Apps bietet zwei unterschiedliche Workload-Plan-Typen, die sich je nach Anforderungen und Nutzungsszenario eignen:

• Consumption Only: Dieser Plan stellt ausschließlich serverlose Compute-Ressourcen bereit, sodass nur die tatsächlich genutzten Ressourcen in Rechnung gestellt werden. Dies kann für Anwendungen mit stark schwankender Last sinnvoll sein. Allerdings kann auch der „Workload Profiles“-Plan serverlose Skalierung unterstützen, weshalb „Consumption Only“ nur in Ausnahmefällen eine vorteilhafte Wahl ist.
• Workload Profiles: Dieser Plan ermöglicht neben serverloser Skalierung auch die Definition fester CPU- und Arbeitsspeicher-Ressourcen (SKUs) für Ihre Container-Umgebung. Dies eignet sich besonders für Anwendungen mit stabiler Last oder wenn eine garantierte Performance erforderlich ist. Im Gegensatz zum „Consumption Only“-Plan bietet dieser Typ mehr Kontrolle über die zugrunde liegenden Ressourcen.

In einem Container App Environment vom Typ "Workload Profile" können Sie mehrere Arten von Skus parallel Nutzen, sodass in einem Container App Environment die folgende beispielhafte Aufteilung möglich wäre:

• Workload Profile Dedicated 1 (SKU: General Purpose D-series mit 4 vCPUs und 16GB RAM) : 2 Apps
• Workload Profile Dedicated 2 (SKU: General Purpose D-series mit 4 vCPUs und 16GB RAM) : 1 App
• Workload Profile Consumption (Bis zu 4 vCPUs und 8GB RAM): 15 Apps

Der Grund sich für den Workload Profile Typ zu entscheiden ist zudem aufgrund der Limitierung des Consumption Only Typs auf 2 vCPUs und 4GB RAM pro App zu begründen. Mit dem Workload Profile Typ sind sie langfristig flexibler und können auf sich ändernde Ressourcenanforderungen besser reagieren.

Der Vorteil von Consumption (Workload Profile) und Consumption Only Container Apps Environments ist, dass für Anwendungen Scaling Rules verwendet werden können. So können Sie Regeln definieren, um die erforderten Ressourcen je nach Bedarf zu skalieren. Bei planbaren und konstanten Ressourcen-Allokationen können jedoch Workload Profiles kostengünstiger sein.

Beispiel mit gleichzeitiger Verwendung von Consumption und Workload Profile Container Apps Environments:

Netzwerkarchitektur von Container App Environments

In diesem Abschnitt zeige ich Ihnen alle wichtigen Eigenschaften und Einschränkungen die Sie bei der Bereitstellung Ihrer Container Apps berücksichtigen sollten.

Entscheidungsgrundlage 1: VNet-Integration

Container App Environments können in Ihrem eigenen VNet oder im Mandanten von Microsoft erstellt werden. Damit Sie volle Kontrolle über Ihr Container Apps Environment haben, empfehle ich Ihnen ein dediziertes Container Apps Environment in Ihrem eigenen VNet zu erstellen. Wenn Sie Ihr bestehendes VNet nutzen können Sie ohne Probleme Network Security Groups für Ihren Container Apps Environment Subnet konfigurieren und die private Kommunikation zu anderen Ressourcen im selben VNet gewährleisten.

Subnet-Konfiguration für Azure Container Apps Environments:

• Dediziertes Subnetz: Die Integration virtueller Netzwerke erfordert ein dediziertes Subnetz
• Unveränderliche Größe: Subnetzgrößen können nach der Erstellung nicht mehr geändert werden
• Delegation: Ihr Subnetz muss an Microsoft.App/environments delegiert werden
• Infrastruktur-Reservierung: Container Apps reserviert automatisch 12 IP-Adressen für die Infrastruktur (unabhängig von der Skalierung)

Ein weiterer Grund für die Auswahl des Workload Profiles Container Apps Environments ist die Verfügbarkeit von User Defined Routes (UDR):

Mit User Defined Routen können Sie den aus den Container Apps ausgehenden Traffic zunächst auf eine Azure Application Firewall routen.

Entscheidungsgrundlage 2: Virtuelle IP-Konfiguration

Die Konfiguration des Ingress-Traffics erfolgt im Abschnitt ingress, wo verschiedene Einstellungen vorgenommen werden können:

• Zugriffsebene: Die Container-App kann entweder als intern oder extern erreichbar konfiguriert werden. Dabei wird die Umgebungsvariable CONTAINER_APP_ENV_DNS_SUFFIX genutzt, um automatisch das vollqualifizierte Domänennamen-Suffix (FQDN) der Umgebung aufzulösen. Innerhalb derselben Umgebung können Anwendungen direkt über ihren Namen miteinander kommunizieren.
• Datenverkehrs-Aufteilungsregeln: Es lassen sich Regeln definieren, um den eingehenden Datenverkehr auf verschiedene Revisionen der Anwendung zu verteilen. Dies ermöglicht z. B. schrittweise Rollouts oder A/B-Tests. Weitere Details zur Konfiguration der Datenverkehrsverteilung sind in der Azure-Dokumentation zu finden.

In der folgenden Abbildung ist der Netzwerk Traffic unter Verwendung eines Application Gateways für ingress Traffic dargestellt und anschließend ein Beispiel bei dem der Container App Ingress Typ auf extern gestellt wurde und die Default FQDN im Internet erreichbar ist:

Einsatz von Load Balancern

Azure Container Apps bieten eine flexible Plattform für den Betrieb containerisierter Anwendungen in der Azure Cloud. Doch oft stellt sich die Frage: Wie lassen sich Container Apps optimal in bestehende Architekturen mit Load Balancing, globaler Verteilung und Sicherheitsanforderungen integrieren? In diesem Abschnitt beleuchten wir verschiedene Kombinationen von Azure Container Apps mit Application Gateway und Front Door sowie die entsprechenden Anforderungen bei der Netzwerkkonfiguration.

1. Application Gateway mit Azure Container Apps

Szenario: Application Gateway wird als Reverse Proxy und Web Application Firewall (WAF) vor den Container Apps geschaltet. Diese Architektur ist besonders für interne und externe Webanwendungen geeignet, die TLS-Terminierung, Routing auf Basis von Hostnamen oder Web Application Firewall-Schutz benötigen.

Netzwerkkonfiguration: Application Gateway wird in einem eigenen Subnetz innerhalb eines Azure Virtual Networks (VNet) bereitgestellt. Bei einer privaten Azure Container Apps-Umgebung müssen diese ebenfalls in ein VNet integriert werden, um eine direkte Kommunikation zu ermöglichen. Falls die Container Apps öffentlich erreichbar sind, kann das AGW als Reverse Proxy mit Public IP arbeiten.

2. Azure Front Door mit Azure Container Apps

Szenario: Azure Front Door wird als globales Content Delivery Network (CDN) und Load Balancer für geografisch verteilte Anwendungen eingesetzt. Dies eignet sich insbesondere für Szenarien mit Multi-Region-Deployments.

Netzwerkkonfiguration: Front Door unterstützt keine direkte VNet-Integration, da es ein globaler Dienst ist. Um Azure Container Apps mit privatem Zugriff zu nutzen, ist ein zusätzliches Azure Private Link erforderlich. Alternativ müssen die Container Apps über eine öffentliche IP oder einen öffentlich erreichbaren Domainnamen verfügbar sein.

3. Kombination aus Application Gateway und Front Door

Szenario: Eine Kombination beider Dienste ermöglicht es, Front Door als globalen Load Balancer zu nutzen, während Application Gateway innerhalb einer Region detailliertere Routing- und Sicherheitsmechanismen übernimmt.

Netzwerkkonfiguration: Hierbei wird Front Door als globaler Einstiegspunkt verwendet, während Application Gateway in einem VNet innerhalb der Region operiert. Falls Container Apps privat gehostet sind, müssen sie über Private Link mit Front Door kommunizieren oder über das Application Gateway erreichbar gemacht werden.

4. Zusätzliche Möglichkeiten

Azure Load Balancer (ALB)

Szenario: Wenn Container Apps in einem VNet betrieben werden (z. B. mit Workload Profiles), kann ein interner oder externer Azure Load Balancer verwendet werden, um den Traffic auf verschiedene Instanzen zu verteilen.

Vorteile:

• Geringe Latenz, da es sich um einen Layer-4-Load-Balancer handelt (TCP/UDP).
• Unterstützt sowohl öffentliche als auch private IPs.

Einschränkungen:

• Kein integriertes SSL/TLS-Offloading oder WAF-Funktionalität – in Kombination mit Azure Application Gateway nutzbar.

Azure Traffic Manager (ATM)

Szenario: Wird oft in Multi-Region- oder Multi-Cloud-Architekturen eingesetzt, um den Traffic global auf verschiedene Azure Container Apps zu verteilen.

Vorteile:

• DNS-basierter Load Balancer für globale Hochverfügbarkeit.
• Unterstützung für verschiedene Routing-Methoden (Leistungsbasiert, Geografisch, Failover, Gewichtung).

Einschränkungen:

• Keine direkte Integration mit privaten VNets; es steuert den Traffic nur über DNS und nicht in Echtzeit.

Die Hierarchie einer Azure Container App im Detail

Nachdem wir die Besonderheiten bei der Konfiguration von Container Apps Environments betrachtet haben, möchte ich Ihnen in diesem Abschnitt die relevanten Eigenschaften von Container Apps darlegen.

Container App – Die oberste Ebene

Eine Azure Container App stellt die gesamte Anwendung dar. Sie kann aus einem oder mehreren Containern bestehen, die gemeinsam in einer Umgebung betrieben werden. Die Container App definiert globale Konfigurationen wie Autoskalierungsregeln, Netzwerkkonfiguration und Identitätsmanagement.

Revisionen - Versionierung der Anwendung

Jede Container App besitzt eine oder mehrere Revisionen. Eine Revision ist eine Instanz der Anwendung mit einer spezifischen Konfiguration. Änderungen an der Container App (z. B. Updates an Umgebungsvariablen oder Container-Images) erzeugen eine neue Revision. Revisionsspezifische Aspekte sind: Bereitstellung neuer Versionen ohne Downtime, Traffic-Verteilung auf mehrere Revisionen und Rollbacks auf vorherige Revisionen.

Replikate – Skalierung innerhalb einer Revision

Innerhalb einer Revision werden Replikate erzeugt, die die eigentlichen Container-Instanzen darstellen. Replikate ermöglichen eine horizontale Skalierung und stellen sicher, dass genügend Instanzen laufen, um die Last zu bewältigen. Sie folgen den festgelegten Skalierungsregeln (z. B. CPU-/Speichernutzung oder HTTP-Anfragen pro Sekunde).

Container – Die Anwendungskomponenten

Jedes Replikat enthält einen oder mehrere Container, die gemeinsam als eine Einheit laufen. Container innerhalb eines Replikats teilen sich Ressourcen und kommunizieren über localhost. Typischerweise gibt es zwei Arten von Containern:

• Anwendungscontainer: Der Hauptcontainer, der die Kernfunktionalität der Anwendung bereitstellt.
• Sidecar-Container: Zusätzliche Container für unterstützende Aufgaben wie Logging, Monitoring oder Service-Mesh-Funktionalität.

Init-Container - Vorbereitende Schritte vor dem Start der Anwendungskomponenten

Init-Container sind spezielle Container, die vor den regulären Anwendungscontainern gestartet werden. Sie dienen dazu, einmalige Aufgaben auszuführen, wie:

• Laden von Konfigurationsdateien
• Warten auf Abhängigkeiten (z. B. eine Datenbankverbindung)
• Initialisieren von Ressourcen

In der folgenden Abbildung sind die Unterschiede und Hierarchien ebenfalls dargestellt:

Übersicht weiterer Funktionen

Microservices und Kommunikation: DAPR

DAPR (Distributed Application Runtime) vereinfacht die Kommunikation zwischen Microservices und ermöglicht es, Anwendungen mit robusten, portablen APIs zu entwickeln. Es bietet eine standardisierte Lösung für Herausforderungen wie State Management, Service Invocation und Event-Streaming.

Traffic Splitting

Mit Traffic Splitting können verschiedene Versionen einer Anwendung parallel betrieben werden. Dies ermöglicht schrittweise Rollouts von neuen Versionen, A/B-Tests oder Blue/Green-Deployments, ohne dass die Benutzererfahrung beeinträchtigt wird.

Sicherheit: mTLS und Network Security Groups (NSG)

Für eine sichere Kommunikation innerhalb von Container Apps sorgt mTLS (Mutual Transport Layer Security), das sicherstellt, dass alle Verbindungen zwischen den Diensten verschlüsselt sind. Zusätzlich bieten NSGs (Network Security Groups) detaillierte Steuerungsmöglichkeiten, um den Netzwerkzugriff auf Container und Services zu regulieren und abzusichern.

Leistung: GPUs für anspruchsvolle Workloads

Für rechenintensive Aufgaben wie maschinelles Lernen oder grafische Berechnungen bieten GPUs eine erhebliche Leistungssteigerung. Container Apps unterstützen den Einsatz von GPUs, um auch in anspruchsvolleren Szenarien optimale Leistung zu erzielen.

Verwaltung sensibler Daten: Secrets Management

Mit dem Secrets Management können sensible Daten, wie API-Schlüssel, Passwörter oder Zertifikate, sicher gespeichert und verwaltet werden. Container Apps ermöglichen es, diese Daten verschlüsselt in einer zentralen Verwaltung in Key Vaults zu speichern und nur autorisierten Services zugänglich zu machen.

Zugriffsmanagement: Integrierte Authentifizierung

Die integrierte Authentifizierung ermöglicht eine einfache Implementierung von Sicherheitsprotokollen und die Verwaltung von Benutzerzugriffen. Dies sorgt dafür, dass nur berechtigte Benutzer und Dienste auf Ressourcen zugreifen können.

Skalierung: Automatisches Scaling

Dank des automatischen Scalings passen sich Container Apps dynamisch an die Anforderungen an. Egal, ob die Last steigt oder sinkt – die Plattform stellt sicher, dass stets genügend Ressourcen verfügbar sind, ohne dass manuelle Eingriffe erforderlich sind.

Monitoring und Protokollierung: Logging und Monitoring

Logging und Monitoring sind essentielle Funktionen für die Überwachung der Anwendungsperformance. Container Apps bieten detaillierte Einblicke in den Zustand der Anwendung, um Fehler schnell zu identifizieren und die Leistung zu optimieren.

Persistente Datenspeicherung: Storage Mounts & Blob Storage

Mit Storage Mounts können Container auf persistenten Speicher zugreifen, sodass Daten auch nach dem Neustart von Containern erhalten bleiben. Dies ist besonders wichtig für Anwendungen, die langfristige Speicherung und konsistente Daten benötigen.

Serverless-Komponenten: Functions

Die Integration von Functions ermöglicht es, serverlose Komponenten in Container Apps zu integrieren. Dies bietet eine effiziente Möglichkeit, kleinere, eventgesteuerte Aufgaben auszuführen, ohne eine vollständige Infrastruktur verwalten zu müssen.

Fazit

Die Vielzahl an Funktionen, die Container Apps bieten, macht sie zu einer der vielseitigsten Plattformen für moderne Cloud-Anwendungen. Von der sicheren Kommunikation über die Verwaltung von Geheimnissen bis hin zu leistungsstarken Skalierungsmechanismen – Container Apps eröffnen Entwicklern eine Welt voller Möglichkeiten, um skalierbare, sichere und effiziente Anwendungen zu erstellen.

Hilfreiche Links für die weiterführende Recherche

• Compute Ressourcen Übersicht
  • https://learn.microsoft.com/en-us/azure/container-apps/compare-options
• Container Apps Environment Übersicht
  • https://learn.microsoft.com/en-us/azure/container-apps/environment
  • https://www.bene.haus/container-app-environments/
  • https://techcommunity.microsoft.com/blog/appsonazureblog/generally-available-azure-container-apps-workload-profiles-more-networking-featu/3913345
  • Container Apps Environment Typen
    • https://learn.microsoft.com/en-us/azure/container-apps/structure
    • https://learn.microsoft.com/en-us/azure/container-apps/plans
  • Consumption Only Fragen und Antworten
    • https://learn.microsoft.com/en-us/azure/container-apps/environment-type-consumption-only
  • Workload Profile Übersicht
    • https://learn.microsoft.com/en-us/azure/container-apps/workload-profiles-overview
    • https://www.codit.eu/blog/dive-into-azure-container-apps-workload-profiles/?country_sel=be
  • Netzwerkkonfiguration
    • https://learn.microsoft.com/en-us/azure/container-apps/networking?tabs=workload-profiles-env%2Cazure-cli
    • Ingress Traffic in Container Apps
      • https://learn.microsoft.com/en-us/azure/container-apps/ingress-overview
    • Egress Traffic in Container Apps
      • https://learn.microsoft.com/en-us/azure/container-apps/user-defined-routes
    • Frontdoor und Container Apps durch Private Link
      • https://learn.microsoft.com/en-us/azure/container-apps/how-to-integrate-with-azure-front-door
      • https://github.com/microsoft/azure-container-apps/issues/867
      • https://azureholic.medium.com/azure-container-apps-private-endpoints-and-azure-front-door-6885d0a98bc7
      • https://stackoverflow.com/questions/74257530/how-to-use-azure-front-door-with-azure-container-apps
    • Application Gateway und Container Apps
      • https://medium.com/microsoftazure/centralized-inbound-gateway-options-for-azure-container-apps-aca-with-appgw-terraform-sample-95ce957284b9
    • Kombination Frontdoor und Application Gateway
      • https://techcommunity.microsoft.com/blog/appsonazureblog/integrating-workload-profile-container-app-with-front-door-and-application-gatew/4217335