Die Containerisierung ist ein gängiger Ansatz für die App-Modernisierung. Für komplexere Workloads können Sie Azure Kubernetes Service verwenden. Azure Container Instances eignet sich dagegen für einfache Containerworkloads – etwa für eine einfache Webanwendung. Dieser Artikel konzentriert sich auf die Implementierung einer serverlosen Automatisierung für Container Instances auf Infrastrukturebene, wenn Application Gateway als Firewall verwendet wird.
Wir beginnen mit einem gängigen Szenario. Zum Schutz von Azure-Containerinstanzen können Sie Containergruppen in Azure Container Instances verwenden. Mithilfe von Containergruppen können Sie Azure-Containerinstanzen in einem virtuellen Netzwerk bereitstellen, damit die Container über einen privaten Azure-Endpunkt auf andere private Ressourcen oder andere Azure-Dienste zugreifen können. Kunden, die Webanwendungen hosten, verwenden üblicherweise eine Web Application Firewall wie Azure Application Gateway als Front-End für eingehenden Datenverkehr und Azure Container Instances als Back-End-Pool. Der folgende Artikel ist ein guter Startpunkt: Verfügbarmachen einer statischen IP-Adresse für eine Containergruppe.
Eine potenzielle Herausforderung bei diesem Ansatz ist die Verwendung einer nicht statischen privaten IP-Adresse als Back-End-Pool. Die private IP-Adresse wird möglicherweise während der Wartung rotiert. In diesem Fall muss der Cloudadministrator den Back-End-Pool manuell neu konfigurieren. Wenn zur Skalierung neue Container hinzugefügt werden, muss der Administrator ebenfalls die Konfiguration anpassen, um sicherzustellen, dass Datenverkehr an den richtigen Back-End-Pool weitergeleitet wird. Live- und Bereitschaftstests werden in Containergruppen nicht unterstützt, was die Identifizierung von Workloaddowntime erschwert.
In diesem Artikel werden Verbesserungen zur Bewältigung dieser gängigen Probleme durch die Einführung von Application Insights und Azure Monitor für die Überwachung und die Verwendung von Azure Functions für die automatische Rotation privater IP-Adressen beschrieben. Dieser Ansatz verbessert die Redundanz der Workload.
Mögliche Anwendungsfälle
Diese Architektur eignet sich am besten für Folgendes:
- Serverlose Bereitstellung.
- Minimalbetrieb für eine cloudnative Workload mit Automatisierung.
- Eine einfache Containerworkload, die keine erweiterte Containerorchestrierung erfordert.
- Eine hochgradig redundante, extern ausgerichtete Workload mit automatisierter Neukonfiguration.
- Eine Containerworkload, die Zugriff auf private Ressourcen erfordert (etwa auf Ressourcen, die über private Azure-Endpunkte verfügbar gemacht werden).
Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Datenfluss
Teil 1: Typischer Datenverkehrsfluss für Webanwendungen
1a. Application Gateway verfügt über eine Web Application Firewall-Funktion, die optimal für öffentlichen Datenverkehr genutzt werden kann, bevor dieser die Back-End-Workload erreicht. Application Gateway macht die öffentliche IP-Adresse verfügbar, sodass Azure DDoS Protection eine weitere Schutzebene bietet.
1b. Der Back-End-Pool von Application Gateway wird mit der privaten IP-Adresse der Azure-Containerinstanz in einer Containergruppe konfiguriert. Da Azure-Containerinstanzen in Containergruppen nicht über vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDNs) verfügen, muss die IP-Adresse verwendet werden.
1c. Container in Azure Container Instances können private Ressourcen wie Azure Cosmos DB über private Links nutzen.
Teil 2: Verbesserungen mit Automatisierung
2a. Application Gateway enthält eine Metrik für die Anzahl fehlerfreier Hosts, die als Livetest für Azure-Containerinstanzen verwendet werden kann, da Containergruppen in Container Instances keine Live- oder Bereitschaftstests unterstützen.
2b. Application Insights wird in Containern verwendet, um weitere Metriken zu erfassen. Hierzu zählen unter anderem Heartbeats, die zur Überwachung über einen benutzerdefinierten Thread an Application Insights gesendet werden können.
2c. Sie können Warnungen basierend auf Schwellenwerten konfigurieren, die in den Schritten 2a und 2b definiert wurden. Ein Beispiel: Angenommen, Ihr System verfügt über drei Containerinstanzen, die als Back-End-Pool ausgeführt werden. In diesem Fall können Sie eine Warnung konfigurieren, die ausgelöst wird, wenn die Anzahl fehlerfreier Hosts kleiner als drei ist. In einer Aktionsgruppe von Warnungsregeln können Sie eine Azure-Funktion als Aktionstyp verwenden, um die benutzerdefinierte Aktion auszulösen.
2d. In der Azure-Funktion wird ein Azure SDK verwendet, um die Konfiguration vorhandener Containerinstanzen abzurufen und die gleichen Instanzen neu zu erstellen. Diese Funktion wird durch die in Schritt 2c definierte Warnung ausgelöst. Die Ausführung dieser Funktion kann je nach Komplexität des Setups lange dauern. Da bei Azure-Funktionen ein Timeout auftreten kann, können Sie Azure Durable Functions verwenden, um zeitintensive Prozesse auszuführen und Statusaktualisierungen zu erhalten.
Komponenten
Automation
- Azure Durable Functions: Im Gegensatz zu Azure Functions ist Durable Functions zustandsbehaftet und unterstützt mehrere zustandsbehaftete Workflowmuster. In diesem Beispiel wird das Überwachen-Muster verwendet.
- Azure SDKs: Azure SDKs sind Sammlungen von Bibliotheken, die Sie für die Interaktion mit Azure-Diensten in Ihrer bevorzugten Programmiersprache verwenden können. Die SDKs bieten eine größere Flexibilität bei der Integration von Automatisierungslogik.
Überwachung
- Azure Monitor-Metriken: Dieses Feature von Azure Monitor sammelt vordefinierte numerische Daten aus Azure-Diensten.
- Aktionsgruppen: Eine Aktionsgruppe ist eine Sammlung von Benachrichtigungseinstellungen, die vom Ressourcenbesitzer definiert wurden. Sie können Benachrichtigungskanäle und Aktionen basierend auf ausgelösten Warnungen definieren.
Netzwerk
- Azure DDoS Protection: Azure DDoS Protection im Basic-Tarif ist kostenlos und für alle öffentlichen IP-Adressen aktiviert. Azure DDoS-Netzwerkschutz bietet weitere Funktionen wie etwa die Erfassung von Protokollen an anderen Standorten sowie die Möglichkeit, sich an das DDoS Protection Rapid Response-Team zu wenden.
- Azure Application Gateway: Azure Web Application Firewall schützt öffentliche Anwendungen vor Exploits wie Angriffen durch Einschleusung von SQL-Befehlen und XSS-Angriffen.
- Azure Private Link: Azure Private Link ermöglicht den Zugriff auf Azure-PaaS-Dienste über einen privaten Endpunkt im Microsoft-Backbone, um die Netzwerkzugriffssicherheit noch weiter zu verbessern.
Application
- Azure Container Instances: Azure Container Instances führt Containerimages nahtlos aus, ohne dass eine weitere Infrastruktur eingerichtet werden muss. Erwägen Sie ggf. die Verwendung von Azure Kubernetes Service (AKS) für eine erweiterte Containerorchestrierung.
- Azure Cosmos DB: Azure Cosmos DB ist eine vollständig verwaltete NoSQL-Datenbank, die mehrere Plattformen wie SQL, Cassandra und MongoDB unterstützt.
- Azure Key Vault: Aus Sicherheitsgründen speichern Entwickler Verbindungszeichenfolgen nicht als Klartext im Anwendungsquellcode. Azure Key Vault dient als zentraler Ort für die Speicherung von Geheimnissen mit verbesserter Sicherheit. Anwendungen können benötigte Schlüssel mit verbesserter Sicherheit abrufen.
Alternativen
Im vorherigen Szenario wird ein Back-End-Pool für Application Gateway aktualisiert. Alternativ können Sie eine private Azure-DNS-Zone als Ziel-Back-End für Application Gateway verwenden und mithilfe von Azure-Funktionen einen Datensatz aktualisieren, anstatt Änderungen an Application Gateway vorzunehmen. Diese Alternative würde die Bereitstellungszeit verkürzen. Andererseits kann über Application Gateway-Metriken die Hostanzahl nicht ermittelt werden, da sie von DNS abstrahiert wird. Diese Automatisierung müsste also über eine Anwendungsüberwachungslösung wie Application Insights oder Azure Monitor ausgelöst werden.
Azure bietet mehrere Optionen zum Hosten containerbasierter Workloads – beispielsweise Azure Kubernetes Service, Azure App Service und Azure Container Apps.
Azure Kubernetes Service bietet erweiterte Funktionen für die Containerorchestrierung und das Netzwerk wie etwa die Dienstressource, die in Container Instances nicht verfügbar ist. Diese Anforderung wird in dieser Referenzarchitektur berücksichtigt.
Von App Service können auch Containerworkloads gehostet werden, und die App Service-Umgebung ermöglicht Entwicklern die Bereitstellung von App Service in Azure Virtual Network. Aufgrund der Preisstruktur bietet sich Container Instances im Vergleich zu App Service für kleine Workloads an.
Azure Container Apps ist eine serverlose Container-Plattform, die auf Kubernetes basiert. Es ermöglicht Entwicklern, Anwendungen im Kubernetes-Stil zu erstellen, die keinen direkten Zugriff auf alle nativen Kubernetes-APIs und die Cluster-Verwaltung benötigen. Azure Container Apps bietet eine vollständig verwaltete Erfahrung, die auf Best Practices basiert.
Überlegungen
Verfügbarkeit
Da Live- und Bereitschaftstests in Containergruppen nicht unterstützt werden, empfiehlt es sich, Azure Monitor-Metriken und Azure Application Insights für die Überwachung zu verwenden. Containerintegrität und Uptime sind keine deterministischen Ansätze, um zu bestimmen, ob ein System vollständig funktioniert.
Operations
Azure Durable Functions wird verwendet, um die Infrastruktur neu zu konfigurieren, wenn ein Fehler in Container Instances auftritt oder sich die private IP-Adresse einer Containergruppe ändert. Wie in der Dokumentation erwähnt, dauert der Bereitstellungsprozess etwas länger. Bei Benutzern kann es zu minimaler Downtime kommen, wenn die Container nicht rechtzeitig bereit sind.
Diese Architektur fügt eine Resilienzebene hinzu. Es empfiehlt sich jedoch trotzdem, die Überwachung in der Anwendung zu konfigurieren und den Azure-Status auf Plattformausfälle zu überwachen.
Skalierbarkeit
Die CPU- und Arbeitsspeicheranforderungen werden bei der Containererstellung definiert. Daher ist keine direkte vertikale Skalierung möglich. Für die horizontale Skalierung können Sie Container zur Containergruppe hinzufügen. Beachten Sie jedoch, dass von jedem Container in der Containergruppe eine private IP-Adresse beansprucht wird. Der Grenzwert ist somit die Größe des bereitgestellten Subnetzes.
Ein weiterer wichtiger Aspekt bei der Skalierung ist der Zustand der Anwendung. Die Anwendung muss den Zustand entweder lokal oder mithilfe externer Dienste wie Azure Cache for Redis handhaben, um sicherzustellen, dass es durch die Skalierung bei Bedarf zu keinen Datenverlusten in der Anwendung kommt.
Sicherheit
Die Möglichkeit, PaaS in einem virtuellen Netzwerk bereitzustellen (VNet-Injektion), verbessert die Sicherheit nicht, wenn die Konfiguration nicht ordnungsgemäß eingerichtet ist. Die VNet-Injektion gibt Administratoren mehr Kontrolle über das Netzwerk und bietet Vorteile wie enger gefasste Netzwerksicherheitsgruppen und die Verwendung von Ressourcen, die nicht öffentlich verfügbar gemacht werden.
Private Link projiziert einen privaten Endpunkt in das virtuelle Netzwerk, wodurch die Anwendung direkt über eine private IP-Adresse auf Azure PaaS zugreifen kann. Gleichzeitig können Administratoren besser steuern, wer auf die relevante Azure-PaaS-Instanz zugreifen kann.
Wenn Sie Containerimages in Azure Container Registry speichern, können Sie Microsoft Defender für Container-Registrierungen aktivieren, um Sicherheitsrisikoüberprüfungen für Containerimages durchzuführen.
Preise
Sehen Sie sich den Azure-Preisrechner an, um die Kosten für Azure-Ressourcen zu schätzen.
Ein Beispiel für die obige Implementierung finden Sie hier.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Marcus Tee | Technical Strategy Roadmap
Nächste Schritte
- Entwerfen moderner Anwendungen in Azure
- Implementieren der Netzwerksicherheit in Azure
- Cookbook: Serverloses Computing mit Azure
Zugehörige Ressourcen
Sehen Sie sich unsere Architekturen an:
Verwandte Leitfäden: