Freigeben über

Bereitstellen von Microservices in Azure-Container-Apps

Azure Container Apps
Azure Cosmos DB
Azure Service Bus

Dieses Szenario zeigt eine vorhandene Workload, die ursprünglich für Kubernetes entwickelt wurde, die für die Ausführung in Azure-Container-Apps replatformiert ist. Container Apps unterstützen Brownfield-Workloads, bei denen Teams die Infrastruktur und die Container-Orchestrierung vereinfachen möchten.

Die Beispielarbeitsauslastung ist eine containerisierte Microservices-Anwendung. Sie verwendet die gleiche Workload, die in der Microservices-Architektur für Azure Kubernetes Service (AKS) definiert ist. Diese Architektur verlagert die Workload in Container-Apps, die als Anwendungsplattform dienen.

Von Bedeutung

Diese Architektur konzentriert sich auf die Minimierung von Anwendungscodeänderungen und den Übergang von AKS zu Container-Apps als Plattformmigration. Ziel ist es, die vorhandene Implementierung zu replizieren und Code- oder Infrastrukturoptimierungen zu verzögern, die die Migration gefährden können.

Für eine Greenfield-Workload, siehe Bereitstellen von Microservices mithilfe von Container-Apps und Dapr.

Tipp

Eine Beispielimplementierung unterstützt diese Architektur und veranschaulicht einige der in diesem Artikel beschriebenen Entwurfsoptionen.

Aufbau

Diagramm, das die Laufzeitarchitektur für die Lösung zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Dienste, die dieselbe Umgebung nutzen, profitieren auf folgende Weise:

  • Interne Eingangsdaten- und Dienstermittlung
  • Einzelner Log Analytics-Arbeitsbereich für die Runtimeprotokollierung
  • Eine sichere Verwaltungsmethode für geheime Schlüssel und Zertifikate

Datenfluss

  1. Erfassungsdienst: Empfängt Clientanforderungen, puffert sie und veröffentlicht sie dann an Azure Service Bus. Es ist der einzige Eingangspunkt in die Workload.

  2. Workflowdienst: Nutzt Nachrichten von Service Bus und verteilt sie an zugrunde liegende Microservices.

  3. Paketdienst: Dient zur Paketverwaltung. Der Dienst verwaltet seinen eigenen Zustand in Azure Cosmos DB.

  4. Drohnenplanungsdienst: Kümmert sich um die Zeitplanung für die Drohnen und überwacht sie während des Flugs. Der Dienst verwaltet seinen eigenen Zustand in Azure Cosmos DB.

  5. Zustellungsdienst: Verwaltet geplante oder transitbezogene Lieferungen. Der Dienst verwaltet seinen eigenen Status in Azure Managed Redis.

  6. Abruf geheimer Schlüssel: Da es sich um eine vorhandene Workload handelt, greifen nur einige Komponenten auf Azure Key Vault zu, um geheime Laufzeitschlüssel abzurufen. Die anderen Dienste erhalten diese geheimen Schlüssel aus der Container-Apps-Umgebung.

  7. Protokolle und Metriken: Die Umgebung und alle Container-Apps geben Protokolle und Metriken aus, die von Azure Monitor-Funktionen gesammelt und visualisiert werden.

  8. Containerimages: Containerimages werden aus der vorhandenen Azure-Containerregistrierung abgerufen, die zuvor für AKS verwendet und in der Container-Apps-Umgebung bereitgestellt wurde.

Komponenten

Die Workload verwendet die folgenden Azure-Dienste in Abstimmung miteinander:

  • Container-Apps ist eine serverlose Containerplattform, die die Container-Orchestrierung und -verwaltung vereinfacht. In dieser Architektur dient Container-Apps als primäre Hostingplattform für alle Microservices.

    Die folgenden Features ersetzen viele der Funktionen der vorherigen AKS-Architektur:

    • Integrierte Dienstermittlung
    • Verwaltete HTTP- und HTTP/2-Endpunkte
    • Integrierter Lastenausgleich
    • Protokollierung und Überwachung
    • Automatische Skalierung basierend auf HTTP-Datenverkehr oder Ereignissen, die von Kubernetes-basierten ereignisgesteuerten Autocaling (KEDA) unterstützt werden
    • Anwendungsupgrades und Versionsverwaltung

  • Die Containerregistrierung ist ein verwalteter Registrierungsdienst zum Speichern und Verwalten privater Containerimages. In dieser Architektur ist es die Quelle aller Containerimages, die in der Container-Apps-Umgebung bereitgestellt werden. Die Registrierung ist die gleiche, die in der AKS-Implementierung verwendet wird.

  • Azure Cosmos DB ist ein global verteilter Datenbankdienst mit mehreren Modellen. In dieser Architektur verwendet der Drohnenplanerdienst Azure Cosmos DB als Datenspeicher.

  • Azure DocumentDB ist ein vollständig verwalteter mongoDB-kompatibler Datenbankdienst zum Erstellen moderner Anwendungen. In dieser Architektur verwendet der Paketdienst Azure DocumentDB als Datenspeicher.

  • Service Bus ist ein Cloud messaging-Dienst, der asynchrone Kommunikationsfunktionen und hybride Integration bereitstellt. In dieser Architektur behandelt sie asynchrones Messaging zwischen dem Aufnahmedienst und dem aufgabenbasierten Workflow-Microservice. Die restlichen Dienste in der vorhandenen Anwendung sind so konzipiert, dass andere Dienste sie mit HTTP-Anforderungen aufrufen können.

  • Azure Managed Redis ist ein In-Memory-Caching-Dienst. In dieser Architektur reduziert es die Latenz und verbessert den Durchsatz für häufig aufgerufene Drohnen-Lieferdaten.

  • Key Vault ist ein Clouddienst zum sicheren Speichern und Zugreifen auf geheime Schlüssel wie API-Schlüssel, Kennwörter und Zertifikate. In dieser Architektur verwenden der Drohnenplaner und die Zustellungsdienste vom Benutzer zugewiesene verwaltete Identitäten, um sich bei Key Vault zu authentifizieren und geheime Schlüssel abzurufen, die für ihre Laufzeitanforderungen erforderlich sind.

  • Azure Monitor ist eine umfassende Überwachungslösung, die Telemetriedaten sammelt und analysiert. In dieser Architektur sammelt und speichert sie Metriken und Protokolle aus allen Anwendungskomponenten über einen Log Analytics-Arbeitsbereich. Sie verwenden diese Daten, um die Anwendung zu überwachen, Warnungen und Dashboards einzurichten und Ursachenanalysen von Fehlern durchzuführen.

    • Application Insights ist ein Dienst zur Anwendungsleistungsverwaltung, der erweiterbare Überwachungsfunktionen bereitstellt. In dieser Architektur wird jeder Dienst mit dem Application Insights SDK instrumentiert, um die Anwendungsleistung zu überwachen.

Alternativen

Die erweiterte AKS-Microservices-Architektur beschreibt ein alternatives Szenario dieses Beispiels, das Kubernetes verwendet.

Szenariodetails

Sie können die Bereitstellung und Verwaltung von Microservice-Containern mithilfe von Container-Apps, einer serverlosen Umgebung für das Hosten von containerisierten Anwendungen, vereinfachen.

Fabrikam, Inc., ein fiktives Unternehmen, implementiert eine Drohnen-Lieferarbeitslast, in der Benutzer eine Drohne anfordern, um Waren für die Lieferung aufzunehmen. Wenn ein Kunde eine Abholung plant, weist ein Back-End-System eine Drohne zu und benachrichtigt den Benutzer mit einer geschätzten Abholzeit.

Die Microservices-Anwendung wurde in einem AKS-Cluster bereitgestellt. Das Fabrikam-Team nutzte jedoch nicht die erweiterten oder plattformspezifischen AKS-Features. Sie migrierten die Anwendung zu Container-Apps, wodurch sie die folgenden Aktionen ausführen konnten:

  • Verwenden Sie minimale Codeänderungen, wenn Sie die Anwendung von AKS in Container-Apps verschieben. Die Codeänderungen beziehen sich auf Observability-Bibliotheken, die Protokolle und Metriken mit Kubernetes-Knoteninformationen erweitert haben, die in der neuen Umgebung nicht relevant sind.

  • Bereitstellen der Infrastruktur und der Workload mit Bicep-Vorlagen: Für die Bereitstellung der Anwendungscontainer waren keine Kubernetes-YAML-Manifeste erforderlich.

  • Stellen Sie die Anwendung über verwaltetes Ingress bereit. Integrierte Unterstützung für externen, HTTPS-basierten Ingress, um den Aufnahmedienst freizugeben, hat die Notwendigkeit beseitigt, einen eigenen Ingress zu konfigurieren.

  • Container-Bilder aus der Container-Registry abrufen. Container-Apps sind mit allen Linux-Basisimages kompatibel, die in jedem verfügbaren Repository gespeichert sind.

  • Verwenden Sie das Überarbeitungsfeature, um anwendungslebenszyklusanforderungen zu unterstützen. Sie können mehrere Überarbeitungen einer bestimmten Container-App ausführen und den Datenverkehr zwischen ihnen für A/B-Tests oder Blue/Green Deployment Szenarien aufteilen.

  • Verwenden Sie eine verwaltete Identität, um sich bei Key Vault und Container Registry zu authentifizieren.

Mögliche Anwendungsfälle

Stellen Sie eine microservicebasierte Brownfield-Anwendung in einer Plattform as a Service (PaaS) bereit, um die Verwaltung zu vereinfachen und die Komplexität der Ausführung eines Container-Orchestrators zu vermeiden. Der Brownfield-Workload hat durch die Nutzung dieser Architektur im Vergleich zur Kubernetes-Bereitstellung aus folgenden Gründen Kosten gespart:

  • Die Auswahl von Arbeitslastprofilen
  • Weniger Zeit für die täglichen 2 operativen Aufgaben für das Betriebsteam
  • Die Möglichkeit, Überbereitstellung zu vermeiden

Hinweis

Nicht alle Arbeitslasten führen zu solchen Kosteneinsparungen.

Berücksichtigen Sie andere häufige Verwendungen von Container-Apps:

  • Führen Sie containerisierte Workloads auf einer serverlosen, verbrauchsbasierten Plattform aus.
  • Autoskalen-Anwendungen basierend auf HTTP- oder HTTPS-Datenverkehr und ereignisgesteuerten Triggern, die von KEDA unterstützt werden.
  • Minimieren Sie den Wartungsaufwand für containerisierte Anwendungen.
  • Stellen Sie API-Endpunkte bereit.
  • Hosten von Hintergrundverarbeitungsanwendungen.
  • Ereignisgesteuerte Verarbeitung ausführen.

Optimizations

Das Ziel des Workloadteams ist die Migration der vorhandenen Workload zu Container-Apps mit minimalen Codeänderungen. Sie sollten jedoch mehrere Optimierungen vornehmen, um die Architektur- und Workloadimplementierung nach der Migration zu verbessern.

Verbessern der geheimen Verwaltung

Die Workload verwendet einen hybriden Ansatz zur Verwaltung von Geheimnissen. Verwaltete Identitäten gelten nur für Dienste, bei denen der Wechsel zu verwalteten Identitäten keine Codeänderungen erfordert. Der Drohnen-Planer und Lieferdienste verwenden vom Benutzer zugewiesene verwaltete Identitäten mit Key Vault, um auf gespeicherte Geheimnisse zuzugreifen. Die verbleibenden Dienste erfordern Codeänderungen, um verwaltete Identitäten anzunehmen, sodass diese Dienste geheime Schlüssel verwenden, die die Container-Apps-Umgebung bereitstellt.

Ein besserer Ansatz besteht darin, den gesamten Code so zu aktualisieren, dass verwaltete Identitäten mithilfe der App oder Auftragsidentität anstelle von von der Umgebung bereitgestellten geheimen Schlüsseln unterstützt werden. Weitere Informationen zu Workloadidentitäten finden Sie unter Verwaltete Identitäten in Container-Apps.

Vermeiden von Designs, für die ein einzelner Überarbeitungsmodus erforderlich ist

Die Workflowdienst-Container-App wird im Einzelrevisionsmodus ausgeführt. Im Einzelrevisionsmodus hat die App eine Revision, die von null oder mehr Replikaten unterstützt wird. Ein Replikat besteht aus dem Anwendungscontainer und allen erforderlichen Sidecars. In diesem Beispiel werden keine Sidecars verwendet, sodass jedes Replikat ein einzelner Container ist. Der Workflowdienst ist nicht für die Weiterleitungskompatibilität mit Nachrichtenschemas ausgelegt. Zwei verschiedene Versionen des Diensts sollten niemals gleichzeitig ausgeführt werden.

Wenn sich das ServiceBus-Nachrichtenschema ändern muss, müssen Sie den Bus entwässern, bevor Sie die neue Workflowdienstversion bereitstellen. Ein besserer Ansatz besteht darin, den Dienstcode für zukünftige Kompatibilität zu aktualisieren und den Mehrfachüberarbeitungsmodus zu verwenden, um die mit dem Abbau von Warteschlangen verbundenen Ausfallzeiten zu reduzieren.

Erwägen Sie stellenbasierte Arbeit

Der Workflowdienst wird als langlaufende Container-Anwendung implementiert. Sie kann aber auch als Auftrag in Container-Apps ausgeführt werden. Bei einem Job handelt es sich um eine containerisierte Anwendung, die bei Bedarf gestartet wird, bis zur Fertigstellung der verfügbaren Arbeit ausgeführt wird und dann heruntergefahren wird, um Ressourcen freizugeben. Aufträge können sparsamer sein als Replikate, die fortlaufend ausgeführt werden. Das Migrieren des Diensts zur Ausführung als Container-Apps-Auftrag basierend auf der in der Warteschlange verfügbaren Arbeit kann eine praktische Option sein. Dies hängt vom typischen Warteschlangenvolumen ab und davon, wie endlich, parallelisierbar und ressourcenoptimiert der Workflowdienst geschrieben wird. Experimentieren Sie, und überprüfen Sie, um den besten Ansatz zu ermitteln.

Implementierung der Zugriffssteuerung

Die Workload verwendet das integrierte externe Eingangsfeature von Container-Apps, um den Aufnahmedienst verfügbar zu machen. Der Ansatz für die Eingangssteuerung bietet nicht die Möglichkeit, Ihren Eingangspunkt hinter einer Webanwendungsfirewall (WAF) vollständig zu positionieren oder in Azure DDoS Protection-Pläne einzuschließen. Sie müssen dringend alle weborientierten Workloads mit einem Web Application Firewall (WAF) sichern. Um diese Konfiguration in der Container-Apps-Umgebung zu erreichen, sollten Sie den integrierten öffentlichen Eingang deaktivieren und Anwendungsgateway oder Azure Front Door hinzufügen.

Hinweis

Gateways erfordern aussagekräftige Gesundheitsprüfungen, die den Ingress-Dienst in Betrieb halten und verhindern, dass er komplett heruntergefahren wird.

Modernisieren mit Dapr

Sie können die Workload weiter modernisieren, indem Sie mit dem Distributed Application Runtime (Dapr) integrieren. Sie fügt eine Abstraktion zwischen Workloadcode und Zustandsspeichern, Messagingsystemen und Dienstermittlungsmechanismen hinzu. Weitere Informationen finden Sie unter Deploy microservices with Container Apps and Dapr. Wenn Ihr Workload in Kubernetes bereits Dapr oder gängige KEDA-Scaler verwendet, ist die Migration zu Container Apps oft einfach und kann diese Fähigkeit beibehalten.

Umstellung auf Benutzerauthentifizierung und Autorisierung

Die Arbeitslast delegiert keine Autorisierung an ein Gateway. Der Eingabedienst übernimmt die Autorisierung seiner Kunden. Ein besserer Ansatz besteht darin, diese Verantwortung auf das integrierte Authentifizierungs- und Autorisierungsfeature zu entladen, das häufig als Easy Auth bezeichnet wird. Diese Änderung nutzt plattformspezifische Funktionen und reduziert benutzerdefinierten Code im Mikroservice für die Aufnahme.

Überlegungen

In den folgenden Überlegungen werden die Säulen des Microsoft Azure Well-Architected Framework implementiert. Dabei handelt es sich um eine Reihe von Leitsätzen, die Sie verwenden können, um die Qualität einer Workload zu verbessern. Weitere Informationen finden Sie unter Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie ihren Kunden leisten. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Container-Apps helfen Ihnen beim Bereitstellen, Verwalten, Warten und Überwachen der Anwendungen innerhalb der Workloads. Sie können die Zuverlässigkeit verbessern, indem Sie die wichtigsten Empfehlungen befolgen. Einige Empfehlungen werden während der Migration von Kubernetes implementiert.

  • Überarbeitungen helfen Ihnen bei der Bereitstellung von Anwendungsupdates ohne Downtime. Sie können Überarbeitungen verwenden, um die Bereitstellung von Anwendungsupdates zu verwalten und den Datenverkehr zwischen den Überarbeitungen zu teilen, um blaue/grüne Bereitstellungen und A/B-Tests zu unterstützen.

  • Mit den Features für die Beobachtbarkeit von Container-Apps erhalten Sie Einblicke in Komponenten, die in der Umgebung ausgeführt werden. Container-Apps sind in Application Insights und Log Analytics integriert. Mithilfe dieser Daten können Sie Vorgänge nachverfolgen und Warnungen basierend auf Metriken und Ereignissen im Rahmen Ihres Observability-Systems festlegen.

    Die Leistungsüberwachung hilft Ihnen, die Anwendung beim Laden zu bewerten. Metriken und Protokolle stellen Daten bereit, um Trends zu erkennen, Fehler zu untersuchen und Ursachenanalysen durchzuführen.

  • Verwenden Sie Integritäts- und Bereitschaftssonden, um langsam startende Container zu handhaben und zu verhindern, dass Datenverkehr gesendet wird, bevor sie bereit sind. Die Kubernetes-Implementierung umfasst diese Endpunkte. Verwenden Sie sie weiterhin, wenn sie effektive Signale liefern.

  • Wenn ein Dienst unerwartet beendet wird, startet Container-Apps ihn automatisch neu. Die Dienstermittlung ist aktiviert, sodass der Workflowdienst seine nachgeschalteten Microservices ermitteln kann. Verwenden Sie Resilienzrichtlinien , um Timeouts zu verarbeiten und Schaltkreistrennlogik einzuführen, ohne den Code weiter anpassen zu müssen.

  • Aktivieren Sie automatische Skalierungsregeln, um den Bedarf zu erfüllen, da Datenverkehr und Workloads steigen.

  • Verwenden Sie die dynamischen Lastenausgleichs- und Skalierungsfeatures von Container-Apps, um die Verfügbarkeit zu verbessern. Überdimensionieren Sie das Subnetz Ihrer Umgebung, sodass es immer genügend verfügbare IP-Adressen für zukünftige Replikate oder Aufträge hat.

  • Vermeiden Sie das Speichern des Zustands direkt in der Container-Apps-Umgebung, da der gesamte Zustand verloren geht, wenn das Replikat heruntergefahren wird. Externalisieren Sie den Zustand in einen dedizierten Zustandsspeicher für jeden Microservice. Diese Architektur verteilt den Zustand in drei verschiedenen Stores: Azure Managed Redis, Azure Cosmos DB für NoSQL und Azure DocumentDB.

  • Stellen Sie alle Ressourcen, einschließlich Container-Apps, mithilfe einer Multizonentopologie bereit. Weitere Informationen finden Sie unter Verfügbarkeitszonenunterstützung in Container-Apps.

    Legen Sie die Mindestreplikatanzahl für nichttransparente Anwendungen auf mindestens ein Replikat für jede Verfügbarkeitszone fest. Bei typischen Betriebsbedingungen werden Replikas zuverlässig über die Verfügbarkeitszonen in der Region verteilt und ausgeglichen.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.

Geheimnisse

  • Ihre Container-App kann vertrauliche Werte als Geheimnisse speichern und abrufen. Nachdem Sie einen geheimen Schlüssel für die Container-App definiert haben, steht es für die Verwendung durch die Anwendung und alle zugehörigen Skalierungsregeln zur Verfügung. Wenn Sie im Modus mit mehreren Überarbeitungen ausgeführt werden, teilen alle Überarbeitungen dieselben geheimen Schlüssel. Da geheime Schlüssel als Anwendungsbereichsänderungen gelten, wird beim Ändern des Werts eines geheimen Schlüssels keine neue Überarbeitung erstellt. Für alle ausgeführten Überarbeitungen zum Laden des neuen geheimen Werts müssen Sie sie jedoch neu starten. In diesem Szenario werden Anwendungs- und Umgebungsvariablenwerte verwendet.

  • Schreiben Sie den Dienstcode um, um die verwaltete Identität der App zur Authentifizierung von Abhängigkeiten anstelle von vorgabenen gemeinsamen Schlüsseln zu verwenden. Alle Abhängigkeiten verfügen über SDKs, die die verwaltete Identitätsauthentifizierung unterstützen.

  • Sie können vertrauliche Werte sicher in Umgebungsvariablen auf Anwendungsebene speichern. Wenn Sich Umgebungsvariablen ändern, erstellt die Container-App eine neue Überarbeitung.

Netzwerksicherheit

  • Um den externen Zugriff zu beschränken, wird nur der Ingestionsdienst für den externen Zugriff konfiguriert. Auf die Back-End-Dienste kann nur über das interne virtuelle Netzwerk in der Container-Apps-Umgebung zugegriffen werden und als interner Modus konfiguriert werden. Machen Sie dienste nur für das Internet verfügbar, sofern erforderlich.

    Da diese Architektur die integrierte externe Eingangsfunktion verwendet, bietet diese Lösung nicht die Möglichkeit, Ihren Eingangspunkt hinter einem WAF vollständig zu positionieren oder ihn in DDoS-Schutzpläne einzuschließen. Schützen Sie alle web-basierten Arbeitslasten mit einer Webanwendungs-Firewall. Weitere Informationen zu Ingress-Verbesserungen finden Sie unter Implementierung der Ingress-Steuerung.

  • Wenn Sie eine Umgebung erstellen, können Sie ein benutzerdefiniertes virtuelles Netzwerk bereitstellen. Andernfalls generiert und verwaltet Microsoft automatisch ein virtuelles Netzwerk. Sie können dieses von Microsoft verwaltete virtuelle Netzwerk nicht bearbeiten, z. B. durch Hinzufügen von Netzwerksicherheitsgruppen (NSGs) oder Erzwingen des Tunnelingdatenverkehrs zu einer Ausgangsfirewall. Im Beispiel wird ein automatisch generiertes virtuelles Netzwerk verwendet, aber ein benutzerdefiniertes virtuelles Netzwerk verbessert die Sicherheitskontrolle. Mit einem benutzerdefinierten Netzwerk können Sie NSGs und benutzerdefiniertes Routing (UDR)-basiertes Routing über azure Firewall anwenden.

Weitere Informationen zu Netzwerktopologieoptionen, einschließlich der Unterstützung privater Endpunkte für den Eingang, finden Sie unter Netzwerkarchitektur in Container-Apps.

Workloadidentitäten

  • Container-Apps unterstützen von Microsoft Entra verwaltete Identitäten, die es Ihrer App ermöglichen, sich bei anderen Ressourcen zu authentifizieren, die durch die Microsoft Entra-ID geschützt sind, z. B. Key Vault, ohne Anmeldeinformationen in Ihrer Container-App zu verwalten. Eine Container-App kann vom System zugewiesene Identitäten, vom Benutzer zugewiesene Identitäten oder beides verwenden. Speichern Sie geheime Schlüssel in Key Vault für Dienste, die die Microsoft Entra-ID-Authentifizierung nicht unterstützen, und verwenden Sie eine verwaltete Identität, um auf die geheimen Schlüssel zuzugreifen.

  • Verwenden Sie eine dedizierte, vom Benutzer zugewiesene verwaltete Identität für den Containerregistrierungszugriff. Container-Apps unterstützt die Verwendung einer anderen verwalteten Identität für den Betrieb der Workload als für den Zugriff auf das Container-Register. Dieser Ansatz bietet eine präzise Zugriffssteuerung. Wenn Ihre Workload über mehrere Container-Apps-Umgebungen verfügt, teilen Sie die Identität nicht über Instanzen hinweg.

  • Verwenden Sie vom System zugewiesene verwaltete Identitäten für Workloadidentitäten, um den Identitätslebenszyklus mit dem Lebenszyklus der Workloadkomponente zu verknüpfen.

Weitere Sicherheitsempfehlungen

  • Die Kubernetes-Implementierung dieser Workload bietet Schutz mithilfe von Microsoft Defender for Containers-Funktionen. In dieser Architektur bewertet Defender für Container nur die Sicherheitsanfälligkeit der Container in Ihrer Containerregistrierung. Defender für Container bietet keinen Laufzeitschutz für Container-Apps. Bewerten Sie ergänzungen mit Nicht-Microsoft-Sicherheitslösungen, wenn Laufzeitschutz eine Anforderung ist.

  • Führen Sie die Workload nicht in einer freigegebenen Container-Apps-Umgebung aus. Segmentieren Sie sie von anderen Workloads oder Komponenten, die keinen Zugriff auf diese Microservices benötigen. Erstellen Sie separate Container-Apps-Umgebungen. Apps und Aufträge, die in einer Container-Apps-Umgebung ausgeführt werden, können jeden Dienst ermitteln und erreichen, der in der Umgebung mit aktiviertem internen Eingang ausgeführt wird.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung der Kostenoptimierung.

  • Überprüfen Sie eine Beispielpreisschätzung für die Arbeitsauslastung. Verwenden Sie den Azure-Preisrechner. Konfigurationen variieren, passen Sie sie also an Ihr Szenario an.

  • In diesem Szenario sind Azure Cosmos DB, Azure Managed Redis und Service Bus Premium die wichtigsten Kostentreiber.

  • Bewerten Sie bei Containern, die in der Regel eine geringe CPU- und Arbeitsspeichermenge verbrauchen, zuerst das Verbrauchsprofil. Schätzen Sie die Kosten des Verbrauchsprofils auf Grundlage Ihrer Nutzung, um Basis-Kostendaten zu sammeln und andere Profile auszuwerten. Sie können z. B. ein dediziertes Workloadprofil für Komponenten verwenden, die eine sehr vorhersehbare und stabile Nutzung aufweisen und dedizierte Knoten freigeben können. Um die Kosten zu optimieren, halten Sie die Anzahl der Knoten in jedem dedizierten Profil als ein Vielfaches von drei, um ausreichende Compute-Hosts und eine Replikaverteilung in den Verfügbarkeitszonen zu gewährleisten.

  • Vermeiden Sie Die Berechnungskosten während der Inaktivitätszeiträume, indem Sie sicherstellen, dass Komponenten auf Null skaliert werden können, sodass Sie nur bei Bedarf bezahlen. Dieser Ansatz reduziert die Ausgaben für Apps mit variabler oder seltener Nutzung. Gesundheitschecks verhindern typischerweise die vollständige Reduzierung auf Null. In der Architektur können Sie den Workflowdienst als Job neu implementieren, um die Vorteile von *Scale-to-Zero* während Leerlaufzeiten zu nutzen. Dieser Ansatz stimmt gut mit Workloads zusammen, die einen Verbrauchsplan verwenden können.

  • Um regionsübergreifende Netzwerkgebühren zu vermeiden, stellen Sie alle Komponenten wie Zustandsspeicher und die Containerregistrierung in derselben Region bereit.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.

  • Verwenden Sie GitHub-Aktionen oder Azure Pipelines-Integration, um automatisierte kontinuierliche Integration und kontinuierliche Bereitstellungspipelinen (CI/CD) einzurichten.

  • Verwenden Sie den Multi-Revision-Modus mit Traffic-Splitting, um Änderungen an Ihrem Workloadcode und Ihren Skalierungsregeln zu testen.

  • Integrieren Sie sich mit Application Insights und Log Analytics, um Einblicke in Ihre Workload zu erhalten. Verwenden Sie denselben Log Analytics-Arbeitsbereich wie die restlichen Komponenten Ihrer Workload, um alle Arbeitsauslastungserkenntnisse zusammenzuhalten.

  • Verwenden Sie die Infrastruktur als Code (IaC), z. B. Bicep oder Terraform, um alle Infrastrukturbereitstellungen zu verwalten. Bereitstellungen umfassen die Container-Apps-Umgebung, Container-Registrierung und Mikroservice-Statusspeicher. Trennen Sie die Microservice-Bereitstellungspipelines von den Infrastrukturpipelines, da sie häufig keinen ähnlichen Lebenszyklus teilen. Ihre deklarative Pipeline für die Azure-Infrastruktur sollte alle Ressourcen mit Ausnahme der Container-App-Ressourcen bereitstellen.

  • Verwenden Sie einen imperativen Ansatz zum Erstellen, Aktualisieren und Entfernen von Container-Apps aus der Umgebung. Es ist besonders wichtig, wenn Sie die Traffic-Verschiebungslogik dynamisch zwischen verschiedenen Revisionen anpassen. Verwenden Sie eine GitHub-Aktion oder Azure Pipelines-Aufgabe in Ihren Bereitstellungsworkflows . Dieser imperative Ansatz kann auf YAML-App-Definitionen basieren. Um Fehler bei Gesundheitsprüfungen zu minimieren, stellen Sie immer sicher, dass Ihre Pipeline die Containerregistrierung mit dem neuen Container-Image bestückt, bevor Sie die Container-App bereitstellen.

    Eine wichtige Änderung der Kubernetes-Implementierung ist die Umstellung von der Verwaltung von Kubernetes-Manifestdateien, z. B. das Definieren von Deployment Kubernetes-Objekten. Kubernetes bietet über dieses Manifestobjekt einen atomaren Ansatz für die Mikroservice-Bereitstellung, bei dem entweder alles gemeinsam erfolgreich ist oder alles gemeinsam scheitert. In Container-Apps wird jeder Microservice unabhängig bereitgestellt. Ihre Bereitstellungspipelines sind für die Orchestrierung jeder Sequenzierungs- und Rollbackstrategie verantwortlich, die für eine sichere Bereitstellung erforderlich ist.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für die Leistungseffizienz.

  • Die Workload wird auf mehrere Microserviceanwendungen verteilt.

  • Jeder Microservice ist unabhängig und teilt keinen Zustand mit anderen Microservices, was eine unabhängige Skalierung ermöglicht.

  • Verwenden Sie Container-Apps-Aufträge für endliche Prozessläufe, um vorübergehende Laufzeiten zu implementieren und den Ressourcenverbrauch für Leerlaufdienste zu reduzieren. Bewerten Sie die Leistungsauswirkungen des Hoch- und Herunterfahrens von Prozessen im Vergleich zum warmen und einsatzbereiten Halten von Komponenten.

  • Die automatische Skalierung ist aktiviert. Bevorzugen Sie die ereignisbasierte Skalierung über die metrikbasierte Skalierung, sofern möglich. Beispielsweise könnte der Workflowdienst, wenn er für die Unterstützung entwickelt wurde, basierend auf der Service Bus-Warteschlangentiefe skaliert werden. Der Standardmäßige Autoscaler basiert auf HTTP-Anforderungen. Während einer Umformung ist es wichtig, mit demselben Skalierungsansatz zu beginnen und dann die Skalierungsoptimierungen später auszuwerten.

  • Anforderungen werden dynamisch auf verfügbare Replikate einer Überarbeitung ausgeglichen.

  • Metriken, einschließlich Auslastung von CPU, Arbeitsspeicher, Bandbreiteninformationen und Speicher, sind über Azure Monitor verfügbar.

Bereitstellen dieses Szenarios

Führen Sie die Schritte im README.md im Beispielszenario-Repository für Container-Apps aus.

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Beitragende:

Nächste Schritte