Bereitstellung und Tests für unternehmenskritische Workloads in Azure

Das Bereitstellen und Testen der unternehmenskritisch Umgebung ist ein wichtiger Bestandteil der gesamten Referenzarchitektur. Die einzelnen Anwendungstempel werden mithilfe von Infrastruktur als Code aus einem Quellcode-Repository bereitgestellt. Aktualisierungen der Infrastruktur und der darauf aufbauenden Anwendung sollten ohne Ausfallzeiten für die Anwendung bereitgestellt werden. Eine DevOps-CI (Continuous Integration)-Pipeline wird empfohlen, um den Quellcode aus dem Repository abzurufen und die einzelnen Zeitstempel in Azure bereitzustellen.

Bereitstellung und Updates sind der zentrale Prozess in der Architektur. Infrastruktur- und anwendungsbezogene Updates sollten auf völlig unabhängigen Zeitstempeln bereitgestellt werden. Nur die globalen Infrastrukturkomponenten der Architektur werden von den Zeitstempeln gemeinsam genutzt. Vorhandene Stempel in der Infrastruktur werden nicht berührt. Infrastrukturupdates werden nur für diese neuen Stempel bereitgestellt. Ebenso wird die neue Anwendungsversion nur für diese neuen Stempel bereitgestellt.

Die neuen Stempel werden zu Azure Front Door hinzugefügt. Der Datenverkehr wird schrittweise in die neuen Stempel verschoben. Wenn festgestellt wird, dass der Datenverkehr aus den neuen Stempeln ohne Probleme bedient wird, werden die vorherigen Stempel gelöscht.

Für die bereitgestellte Umgebung werden Penetrations-, Chaos- und Stresstests empfohlen. Proaktives Testen der Infrastruktur erkennt Schwächen und zeigt, wie sich die bereitgestellte Anwendung verhält, wenn ein Fehler auftritt.

Bereitstellung

Die Bereitstellung der Infrastruktur in der Referenzarchitektur hängt von den folgenden Prozessen und Komponenten ab:

• DevOps – Der Quellcode von GitHub und Pipelines für die Infrastruktur.

• Updates ohne Ausfallzeiten – Updates und Upgrades werden in der Umgebung mit null Ausfallzeiten für die bereitgestellte Anwendung bereitgestellt.

• Umgebungen – Kurzlebige und permanente Umgebungen, die für die Architektur verwendet werden.

• Freigegebene und dedizierte Ressourcen – Azure-Ressourcen, die für die Stempel und die gesamte Infrastruktur dedizierte und freigegeben sind.

Weitere Informationen finden Sie unter Bereitstellung und Tests für unternehmenskritische Workloads in Azure: Entwurfsaspekte

Bereitstellung: DevOps

Die DevOps-Komponenten bieten das Quellcode-Repository und die CI/CD-Pipelines für die Bereitstellung der Infrastruktur und Updates. GitHub und Azure-Pipelines wurden als Komponenten ausgewählt.

• GitHub – Enthält die Quellcode-Repositorys für die Anwendung und Infrastruktur.

• Azure-Pipelines – Die Von der Architektur verwendeten Pipelines für alle Build-, Test- und Releaseaufgaben.

Eine zusätzliche Komponente im Design, das für die Bereitstellung verwendet wird, ist Build-Agents. Microsoft Hosted Build-Agents werden als Teil von Azure-Pipelines verwendet, um die Infrastruktur und Updates bereitzustellen. Die Verwendung von Microsoft Hosted Build-Agents beseitigt die Belastung der Entwickler mit der Verwaltung und Aktualisierung des Build-Agents.

Weitere Informationen zu Azure-Pipelines finden Sie unter Was ist Azure DevOps Services?.

Weitere Informationen finden Sie unter BereitstellInfrastructure-as-Code deploymentsung und Tests für unternehmenskritische Workloads in Azure: Infrastructure-as-Code-Bereitstellungen

Bereitstellung: Updates ohne Ausfallzeiten

Die Null-Ausfallzeit-Update-Strategie in der Referenzarchitektur ist von zentraler Bedeutung für die gesamte unternehmenskritische Anwendung. Die Methode des Ersetzens anstelle des Upgrades der Stempel stellt eine neue Installation der Anwendung in einen Infrastrukturstempel sicher. Die Referenzarchitektur nutzt einen Blau-Grün-Ansatz und ermöglicht separate Test- und Entwicklungsumgebungen.

Es gibt zwei Hauptkomponenten der Referenzarchitektur:

• Infrastruktur – Azure-Dienste und -Ressourcen. Bereitgestellt mit Terraform und der zugehörigen Konfiguration.

• Anwendung – Der gehostete Dienst oder die gehostete Anwendung, die Benutzern dient. Basierend auf Docker-Containern und mit npm erstellten Artefakten in HTML und JavaScript für die Benutzeroberfläche der SPA (Single-Page-Webanwendung).

In vielen Systemen gibt es die Annahme, dass Anwendungsupdates häufiger als Infrastrukturupdates durchgeführt werden. Daher werden verschiedene Updateprozeduren für jedes Szenario entwickelt. Mit einer öffentlichen Cloudinfrastruktur können Änderungen schneller erfolgen. Es wurde ein Bereitstellungsprozess für Anwendungsupdates und Infrastrukturupdates gewählt. Ein Ansatz stellt sicher, dass Infrastruktur- und Anwendungsupdates immer synchronisiert sind. Dieser Ansatz ermöglicht folgendes:

• Ein konsistenter Prozess – Weniger Gelegenheiten für Fehler, wenn Infrastruktur- und Anwendungsupdates in einem Release, absichtlich oder nicht, gemischt werden.

• Armöglicht die Blau-Grün-Bereitstellung – Jedes Update wird mithilfe einer schrittweisen Migration des Datenverkehrs zum neuen Release bereitgestellt.

• Einfachere Bereitstellung und Debuggen der Anwendung – Der gesamte Stempel hostet nie mehrere Versionen der Anwendung nebeneinander.

• Einfaches Rollback – Der Datenverkehr kann zurück zu den Stempeln wechseln, die die vorherige Version ausführen, wenn Fehler oder Probleme auftreten.

• Vermeidung manueller Änderungen und Konfigurationsdrift – Jede Umgebung ist eine neue Bereitstellung.

Weitere Informationen finden Sie unter Bereitstellung und Testen für unternehmenskritische Workloads auf Azure: Kurzlebige Blau-Grün-Bereitstellungen

Branchingstrategie

Die Grundlage der Updatestrategie ist die Verwendung von Verzweigungen im Git-Repository. Die Referenzarchitektur verwendet drei Arten von Verzweigungen:

Verzweigung	Beschreibung
feature/* und fix/*	Die Einstiegspunkte für jede Änderung. Diese Verzweigungen werden von Entwicklern erstellt und sollten einem beschreibenden Namen wie feature/catalog-update oder fix/worker-timeout-bug erhalten. Wenn Änderungen zur Zusammenführung bereit sind, wird ein PR (Pull Request) für die main-Verzweigung erstellt. Jeder PR muss von mindestens einem Prüfer genehmigt werden. Mit begrenzten Ausnahmen muss jede Änderung, die in einem PR vorgeschlagen wird, über die E2E (End-to-End)-Validierungspipeline ausgeführt werden. Die E2E-Pipeline sollte von Entwicklern verwendet werden, um Änderungen an einer vollständigen Umgebung zu testen und zu debuggen.
main	Die kontinuierlich bewegte und stabile Verzweigung. Wird meist für Integrationstests verwendet. Änderungen an main werden nur über Pull Requests vorgenommen. Eine Verzweigungsrichtlinie untersagt das direkte Schreiben. Nächtliche Releases in der permanenten integration (int)-Umgebung werden automatisch von der main-Verzweigung ausgeführt. Die main-Verzweigung gilt als stabil. Es sollte sicher sein, dass jederzeit ein Release erstellt daraus werden kann.
release/*	Release-Verzweigungen werden nur aus der main-Verzweigung erstellt. Die Verzweigungen folgen dem Format release/2021.7.X. Verzweigungsrichtlinien werden verwendet, damit nur Repo-Administratoren release/*-Verzweigungen erstellen dürfen. Nur diese Verzweigungen werden verwendet, um die prod-Umgebung bereitzustellen.

Weitere Informationen finden Sie unter Bereitstellung und Tests für unternehmenskritische Workloads in Azure: Verzweigungsstrategie

Hotfixes

Wenn ein Hotfix dringend aufgrund eines Fehlers oder eines anderen Problems erforderlich ist und den regulären Releaseprozess nicht durchlaufen kann, ist ein Hotfixpfad verfügbar. Wichtige Sicherheitsupdates und Fixes für das Benutzererlebnis, die während des anfänglichen Tests nicht entdeckt wurden, gelten als gültige Beispiele für Hotfixes.

Der Hotfix muss in einer neuen fix-Verzweigung erstellt und dann mit einem regulären PR in main zusammengeführt werden. Anstatt eine neue Release-Verzweigung zu erstellen, wird der Hotfix im Verfahren des „Cherrypicking“ in eine bestehende Release-Verzweigung eingefügt. Diese Verzweigung wird bereits in der prod-Umgebung bereitgestellt. Die CI/CD-Pipeline, die ursprünglich die Release-Verzweigung mit allen Tests bereitgestellt hat, wird erneut ausgeführt und stellt nun den Hotfix als Teil der Pipeline bereit.

Um größere Probleme zu vermeiden, ist es wichtig, dass der Hotfix ein paar isolierte Commits enthält, die einfach herausgepickt und in die Release-Verzweigung integriert werden können. Wenn isolierte Commits nicht in die Release-Verzweigung integriert werden können, ist es ein Hinweis darauf, dass die Änderung nicht als Hotfix qualifiziert ist. Die Änderung sollte dann als vollständiges neues Release bereitgestellt und potenziell mit einem Rollback zu einer früheren stabilen Version kombiniert werden, bis das neue Release bereitgestellt werden kann.

Bereitstellung: Umgebungen

Die Referenzarchitektur verwendet zwei Arten von Umgebungen für die Infrastruktur:

• Kurzlebig – Die E2E-Validierungspipeline wird verwendet, um kurzlebige Umgebungen bereitzustellen. Kurzlebige Umgebungen werden für reine Validierungs- oder Debugging-Umgebungen für Entwickler verwendet. Validierungs-Umgebungen können aus der feature/*-Verzweigung erstellt werden. Sie unterliegen Tests und können dann zerstört werden, wenn alle Tests erfolgreich waren. Debugging-Umgebungen werden auf dieselbe Weise wie Validierungs-Umgebungen bereitgestellt, aber nicht sofort zerstört. Diese Umgebungen sollten nicht länger als ein paar Tage existieren und sollten gelöscht werden, wenn der entsprechende PR der Funktionsverzweigung zusammengeführt wird.

• Permanent – In den permanenten Umgebungen gibt es die Versionen integration (int) und production (prod). Diese Umgebungen bestehen kontinuierlich und werden nicht zerstört. Die Umgebungen verwenden feste Domänennamen wie int.mission-critical.app. In einer realen Implementierung der Referenzarchitektur sollte eine staging (pre-prod)-Umgebung hinzugefügt werden. Die staging-Umgebung wird verwendet, um release-Verzweigungen mit demselben Updateprozess wie bei prod (Blau-Grün-Bereitstellung) bereitzustellen und zu überprüfen.

  • Integration (int) – Die Version int wird nachts mit demselben Prozess wie bei prod aus der main-Verzweigung bereitgestellt. Die Umstellung des Datenverkehrs ist schneller als bei der vorherigen Release-Einheit. Anstatt den Datenverkehr wie bei prod schrittweise über mehrere Tage hinweg umzustellen, wird der Prozess für int innerhalb weniger Minuten oder Stunden abgeschlossen. Mit dieser schnelleren Umstellung wird sichergestellt, dass die aktualisierte Umgebung am nächsten Morgen bereit ist. Alte Stempel werden automatisch gelöscht, wenn alle Tests in der Pipeline erfolgreich sind.

  • Produktion (Prod) – Die Version prod wird nur aus release/*-Verzweigungen bereitgestellt. Der Umstellung des Datenverkehrs verwendet detailliertere Schritte. Ein Gate für die manuelle Genehmigung befindet sich zwischen jedem Schritt. Jedes Release erstellt neue regionale Stempel und stellt die neue Anwendungsversion für die Stempel bereit. Vorhandene Stempel werden im Prozess nicht berührt. Die wichtigste Erwägung für prod ist, dass es „Always-On“ sein sollte. Geplante oder ungeplante Ausfallzeiten sollten niemals auftreten. Die einzige Ausnahme ist bei grundlegenden Änderungen an der Datenbankebene. Möglicherweise ist ein geplantes Wartungsfenster erforderlich.

Bereitstellung: Freigegebene und dedizierte Ressourcen

Die permanenten Umgebungen (int und prod) innerhalb der Referenzarchitektur verfügen über unterschiedliche Arten von Ressourcen, je nachdem, ob sie von der gesamten Infrastruktur gemeinsam genutzt werden oder für einen einzelnen Stempel bestimmt sind. Ressourcen können einem bestimmten Release zugeordnet und nur vorhanden sein, bis die nächste Release-Einheit übernommen hat.

Release-Einheiten

Eine Release-Einheit besteht aus mehreren regionalen Stempeln pro bestimmter Release-Version. Stempel enthalten alle Ressourcen, die nicht für die anderen Stempel freigegeben werden. Diese Ressourcen sind virtuelle Netzwerke, Azure Kubernetes Service-Cluster, Event Hubs und Azure Key Vault. Azure Cosmos DB und ACR sind mit Terraform-Datenquellen konfiguriert.

Global freigegebene Ressourcen

Alle Ressourcen, die zwischen Release-Einheiten gemeinsam genutzt werden, werden in einer unabhängigen Terraform-Vorlage definiert. Diese Ressourcen sind Front Door, Azure Cosmos DB, ACR (Azure Container Registry) und die Log Analytics-Arbeitsbereiche und andere überwachungsbezogene Ressourcen. Diese Ressourcen werden bereitgestellt, bevor der erste regionale Stempel einer Release-Einheit bereitgestellt wird. In den Terraform-Vorlagen für die Stempel wird auf die Ressourcen verwiesen.

Front Door

Während Front Door eine global über Stempel hinweg freigegebene Ressource ist, unterscheidet sich seine Konfiguration geringfügig von den anderen globalen Ressourcen. Front Door muss nach der Bereitstellung eines neuen Stempels neu konfiguriert werden. Front Door muss neu konfiguriert werden, um den Datenverkehr schrittweise auf die neuen Stempel umzustellen.

Die Back-End-Konfiguration von Front Door kann nicht direkt in der Terraform-Vorlage definiert werden. Die Konfiguration wird mit Terraform-Variablen eingefügt. Die Variablenwerte werden erstellt, bevor die Terraform-Bereitstellung gestartet wird.

Die Konfiguration der einzelnen Komponenten für die Bereitstellung von Front Door wird wie folgt definiert:

• Front-End – Die Sitzungsaffinität ist konfiguriert, um sicherzustellen, dass Benutzer während einer einzigen Sitzung nicht zwischen verschiedenen Benutzeroberflächen-Versionen wechseln.

• Ursprünge – Front Door ist mit zwei Arten von Ursprungsgruppen konfiguriert:

  1. Eine Ursprungsgruppe für statischen Speicher, der die Benutzeroberfläche versorgt. Die Gruppe enthält die Websitespeicherkonten aus allen aktuell aktiven Release-Einheiten. Verschiedene Gewichtungen können den Ursprüngen aus unterschiedlichen Release-Einheiten zugewiesen werden, um den Datenverkehr schrittweise zu einer neueren Einheit zu verschieben. Jedem Ursprung aus einer Release-Einheit sollte dieselbe Gewichtung zugewiesen werden.

  2. Eine Ursprungsgruppe für die API, die auf AKS gehostet wird. Wenn Release-Einheiten mit unterschiedlichen API-Versionen vorhanden sind, ist für jede Release-Einheit eine API-Ursprungsgruppe vorhanden. Wenn alle Release-Einheiten dieselbe kompatible API bieten, werden alle Ursprünge der gleichen Gruppe hinzugefügt und verschiedenen Gewichtungen zugewiesen.

• Routingregeln – Es gibt zwei Arten von Routingregeln:

  1. Eine Routingregel für die Benutzeroberfläche, die mit der Benutzeroberflächenspeicher-Ursprungsgruppe verknüpft ist.

  2. Eine Routingregel für jede API, die derzeit von den Ursprüngen unterstützt wird. Beispiel: /api/1.0/* und /api/2.0/*.

  Wenn ein Release eine neue Version der Back-End-APIs einführt, werden die Änderungen in der Benutzeroberfläche angezeigt, die als Teil des Releases bereitgestellt wird. Eine bestimmte Version der Benutzeroberfläche ruft immer eine bestimmte Version der API-URL auf. Benutzer, die von einer Benutzeroberflächen-Version bedient werden, verwenden automatisch die jeweilige Back-End-API. Für verschiedene Instanzen der API-Version sind bestimmte Routingregeln erforderlich. Diese Regeln sind mit den entsprechenden Ursprungsgruppen verknüpft. Wenn eine neue API nicht eingeführt wurde, werden alle API-bezogenen Routingregeln mit der einzelnen Ursprungsgruppe verknüpft. In diesem Fall spielt es keine Rolle, ob einem Benutzer die Benutzeroberfläche aus einem anderen Release als der API gezeigt wird.

Bereitstellung: Bereitstellungsprozess

Ziel des Bereitstellungsprozesses ist eine Blau-Grün-Bereitstellung. Ein neues Release von einer release/*-Verzweigung wird in der prod-Umgebung bereitgestellt. Der Benutzerdatenverkehr wird schrittweise auf die Stempel für das neue Release verschoben.

Als erster Schritt im Bereitstellungsprozess einer neuen Version wird die Infrastruktur für die neue Release-Einheit mit Terraform bereitgestellt. Die Ausführung der Infrastruktur-Bereitstellungspipeline stellt die neue Infrastruktur aus einer ausgewählten Release-Verzweigung bereit. Parallel zur Infrastrukturbereitstellung werden die Containerimages erstellt oder importiert und an die global freigegebene ACR ( Azure Container Registry) gepusht. Wenn die vorherigen Prozesse abgeschlossen sind, wird die Anwendung für die Stempel bereitgestellt. Aus der Sicht der Implementierung ist es eine Pipeline mit mehreren abhängigen Phasen. Die gleiche Pipeline kann für Hotfixbereitstellungen erneut ausgeführt werden.

Nachdem die neue Release-Einheit bereitgestellt und überprüft wurde, wird sie zu Front Door hinzugefügt, um den Benutzerdatenverkehr zu empfangen.

Ein Schalter/Parameter, der zwischen Releases unterscheidet, die eine neue API-Version einführen oder nicht einführen, sollte eingeplant werden. Je nachdem, ob mit dem Release eine neue API-Version eingeführt wird, muss eine neue Ursprungsgruppe mit den API-Back-Ends erstellt werden. Alternativ können neue API-Back-Ends einer vorhandenen Ursprungsgruppe hinzugefügt werden. Neue Benutzeroberflächenspeicherkonten werden der entsprechenden vorhandenen Ursprungsgruppe hinzugefügt. Gewichtungen für neue Ursprünge sollten entsprechend der gewünschten Datenverkehrsaufteilung festgelegt werden. Eine neue Routingregel wie oben beschrieben muss erstellt werden, die der entsprechenden Ursprungsgruppe entspricht.

Als Teil der Ergänzung der neuen Release-Einheit sollten die Gewichte der neuen Ursprünge auf das gewünschten Minimum an Benutzerdatenverkehr festgelegt werden. Wenn keine Probleme festgestellt werden, sollte der Benutzerverkehr über einen bestimmten Zeitraum auf die neue Ursprungsgruppe ausgeweitet werden. Um die Gewichtungsparameter anzupassen, sollten dieselben Bereitstellungsschritte mit den gewünschten Werten erneut ausgeführt werden.

Release-Einheit Nachbereitung

Als Teil der Bereitstellungspipeline für eine Release-Einheit gibt es eine Zerstörungsphase, in der alle Stempel entfernt werden, sobald eine Release-Einheit nicht mehr benötigt wird. Der gesamte Datenverkehr wird in eine neue Release-Version verschoben. Diese Phase umfasst die Entfernung von Release-Einheits-Verweisen von Front Door. Diese Entfernung ist wichtig, um die Veröffentlichung einer neuen Version zu einem späteren Zeitpunkt zu ermöglichen. Front Door muss auf eine einzelne rlease-Einheit verweisen, um in Zukunft auf das nächste Release vorbereitet zu werden.

Checklists

Als Teil der Release-Kadenz sollte eine Prüfliste vor und nach der Veröffentlichung verwendet werden. Im folgenden Beispiel sind Elemente aufgeführt, die mindestens in einer Prüfliste enthalten sein sollten.

• Prüfliste vor der Veröffentlichung – Bevor Sie eine Version starten, überprüfen Sie Folgendes:

  • Stellen Sie sicher, dass der neueste Status der main-Verzweigung erfolgreich in der int-Umgebung bereitgestellt und getestet wurde.

  • Aktualisieren Sie die Änderungsprotokolldatei über einen PR an die main-Verzweigung.

  • Erstellen Sie aus der main-Verzweigung eine release/-Verzweigung.

• Prüfliste nach der Veröffentlichung – Bevor alte Stempel zerstört und ihre Verweise aus Front Door entfernt werden, überprüfen Sie Folgendes:

  • Cluster empfangen keinen eingehenden Datenverkehr mehr.

  • Event Hubs und andere Nachrichtenwarteschlangen enthalten keine nicht verarbeiteten Nachrichten.

Bereitstellung: Einschränkungen und Risiken der Updatestrategie

Die in dieser Referenzarchitektur beschriebene Updatestrategie weist einige Einschränkungen und Risiken auf, die erwähnt werden sollten:

• Höhere Kosten – Bei der Veröffentlichung von Updates sind viele der Infrastrukturkomponenten zweimal für den Veröffentlichungszeitraum aktiv.

• Komplexität von Front Door – Der Updateprozess in Front Door ist komplex in der Implementierung und in der Wartung. Die Möglichkeit, effektive Blau-Grün-Bereitstellungen ohne Ausfallzeiten auszuführen, hängt davon ab, ob dies ordnungsgemäß funktioniert.

• Kleine Änderungen sind zeitaufwendig – Der Updateprozess führt zu einem längeren Veröffentlichungsprozess für kleine Änderungen. Diese Einschränkung kann durch das im vorigen Abschnitt beschriebene Hotfix-Verfahren teilweise kompensiert werden.

Bereitstellung: Überlegungen zur Vorwärtskompatibilität von Anwendungsdaten

Die Updatestrategie kann mehrere Versionen einer API und Workerkomponenten unterstützen, die gleichzeitig ausgeführt werden. Da Azure Cosmos DB zwischen zwei oder mehr Versionen gemeinsam genutzt wird, besteht die Möglichkeit, dass Datenelemente, die von einer Version geändert wurden, möglicherweise nicht immer mit der Version der API oder der Worker übereinstimmen, die sie nutzen. Die API-Ebenen und Worker müssen den Entwurf für die Vorwärtskompatibilität implementieren. Frühere Versionen der API oder Workerkomponenten verarbeiten Daten, die von einer späteren Version der API oder Workerkomponente eingefügt wurden. Teile, die nicht verstanden werden, werden ignoriert.

Testen

Die Referenzarchitektur enthält verschiedene Tests, die in verschiedenen Phasen innerhalb der Testimplementierung verwendet werden.

Zu diesen Tests gehören:

• Komponententests – Diese Tests überprüfen, ob die Geschäftslogik der Anwendung erwartungsgemäß funktioniert. Die Referenzarchitektur enthält eine Beispielsuite von Komponententests, die automatisch vor jedem Containerbuild von Azure Pipelines ausgeführt werden. Wenn ein Test fehlschlägt, wird die Pipeline beendet. Build und Bereitstellung werden dann nicht fortgesetzt.

• Auslastungstests – Diese Tests helfen, die Kapazität, Skalierbarkeit und potenzielle Engpässe für eine bestimmte Arbeitsauslastung oder einen bestimmten Stapel zu bewerten. Die Referenzimplementierung enthält einen Benutzerlastgenerator, der künstliche Lastmuster erstellt, die zum Simulieren des realen Datenverkehrs verwendet werden können. Der Lastgenerator kann auch unabhängig von der Referenzimplementierung verwendet werden.

• Buildakzeptanztests – Diese Tests ermitteln, ob die Infrastruktur und die Workload verfügbar sind und sich wie erwartet verhalten. Buildakzeptanztests werden als Teil jeder Bereitstellung ausgeführt.

• Benutzeroberflächentests – Diese Tests überprüfen, ob die Benutzeroberfläche bereitgestellt wurde und wie erwartet funktioniert. Die aktuelle Implementierung erfasst nur Screenshots mehrerer Seiten nach der Bereitstellung ohne tatsächliche Tests.

• Fehlereinschleusungstests – Diese Tests können manuell automatisiert oder ausgeführt werden. Automatisierte Tests in der Architektur integrieren Azure Chaos Studio als Teil der Bereitstellungspipelines.

Weitere Informationen finden Sie unter Bereitstellung und Tests für unternehmenskritische Workloads in Azure: Validierung und Tests

Tests: Frameworks

Die Online-Referenzimplementierung nutzt, wann immer möglich, bestehende Testmöglichkeiten und Frameworks.

Framework	Testen	Beschreibung
NUnit	Einheit	Dieses Framework wird zum Testen des .NET Core-Teils der Implementierung verwendet. Komponententests werden automatisch von Azure Pipelines vor den Containerbuilds ausgeführt.
JMeter mit Azure Load Testing	Laden	Azure Load Testing ist ein verwalteter Dienst, der zum Ausführen von Apache JMeter-Lastentestdefinitionen verwendet wird.
Locust	Laden	Locust ist ein Open-Source-Framework für Auslastungstests, das in Python geschrieben ist.
Playwright	Benutzeroberfläche und Buildakzeptanz	Playwright ist eine Open-Source-Node.js-Bibliothek zum Automatisieren von Chromium, Firefox und WebKit mit einer einzelnen API. Die Playwright-Testdefinition kann auch unabhängig von der Referenzimplementierung verwendet werden.
Azure Chaos Studio	Fehlereinschleusung	Die Referenzimplementierung verwendet Azure Chaos Studio als optionalen Schritt in der E2E-Validierungspipeline, um Fehler für die Resilienzüberprüfung einzuschleusen.

Tests: Fehlereinschleusungstests und Chaos Engineering

Verteilte Anwendungen sollten resilient gegen Dienst- und Komponentenausfälle sein. Fehlereinschleusungstests (auch bekannt als Fehlereinschleusung oder Chaos Engineering) ist die Praxis, Anwendungen und Dienste realen Belastungen und Fehlern auszusetzen.

Resilienz ist eine Eigenschaft eines gesamten Systems und das Einschleusen von Fehlern hilft, Probleme in der Anwendung zu finden. Bei der Behandlung dieser Probleme können Sie die Anwendungsresilienz auf unzuverlässige Bedingungen, fehlende Abhängigkeiten und andere Fehler überprüfen.

Manuelle und automatische Tests können in der Infrastruktur ausgeführt werden, um Fehler und Probleme in der Implementierung zu finden.

Automatic

In der Referenzarchitektur ist Azure Chaos Studio integriert, um eine Reihe von Azure Chaos Studio-Experimenten bereitzustellen und auszuführen, die verschiedene Fehler auf Stempelebene einschleusen. Chaos-Experimente können als optionaler Teil der E2E-Bereitstellungspipeline ausgeführt werden. Wenn die Tests ausgeführt werden, wird der optionale Auslastungstest immer parallel ausgeführt. Der Auslastungstest wird verwendet, um die Last auf dem Cluster zu erzeugen und so die Auswirkung der eingeschleusten Fehler zu überprüfen.

Manuell

Manuelle Fehlereinschleusungstests sollten in einer E2E-Validierungsumgebung durchgeführt werden. Diese Umgebung gewährleistet vollständige repräsentative Tests ohne das Risiko von Störungen durch andere Umgebungen. Die meisten der mit den Tests erzeugten Fehler können direkt in der „Application Insights“-Ansicht Live-Metriken beobachtet werden. Die verbleibenden Fehler sind in der Fehleransicht und entsprechenden Protokolltabellen verfügbar. Andere Fehler erfordern ein tieferes Debuggen, z. B. die Verwendung von kubectl, um das Verhalten innerhalb von AKS zu beobachten.

Zwei Beispiele für Fehlereinschleusungstests für die Referenzarchitektur sind:

• DNS-basierte Fehlereinschleusung – Ein Testfall, der mehrere Probleme simulieren kann. DNS-Auflösungsfehler, die entweder auf den Ausfall eines DNS-Servers oder von Azure DNS zurückzuführen sind. DNS-basierte Tests können allgemeine Probleme mit Verbindungen zwischen einem Client und einem Dienst simulieren, z. B. wenn der BackgroundProcessor keine Verbindung mit den Event Hubs herstellen kann.

  In Szenarien mit einem Host können Sie die lokale hosts-Datei so ändern, dass die DNS-Auflösung überschrieben wird. In einer größeren Umgebung mit mehreren dynamischen Servern wie AKS ist eine hosts-Datei nicht möglich. Azure Privates DNS-Zonen können als Alternative zu Testfehlerszenarien verwendet werden.

  Azure Event Hubs und Azure Cosmos DB sind zwei der Azure-Dienste, die in der Referenzimplementierung verwendet werden, die genutzt werden können, um DNS-bezogene Fehler einzuschleusen. Die DNS-Auflösung von Event Hubs kann mit einer Azure Privates DNS-Zone bearbeitet werden, die an das virtuelle Netzwerk eines der Stempel gebunden ist. Azure Cosmos DB ist ein global replizierter Dienst mit bestimmten regionalen Endpunkten. Eine Manipulation der DNS-Einträge für diese Endpunkte kann einen Fehler für eine bestimmte Region simulieren und das Failover von Clients testen.

• Firewallblockierung – Die meisten Azure-Dienste unterstützen Firewallzugriffseinschränkungen basierend auf virtuellen Netzwerken und/oder IP-Adressen. In der Referenzinfrastruktur werden diese Einschränkungen verwendet, um den Zugriff auf Azure Cosmos DB oder Event Hubs einzuschränken. Eine einfache Vorgehensweise besteht darin, vorhandene Zulassungs-Regeln zu entfernen oder neue Blockierungs-Regeln hinzuzufügen. Mit diesem Verfahren können Fehlkonfigurationen der Firewall oder Ausfälle von Diensten simuliert werden.

  Die folgenden Beispieldienste in der Referenzimplementierung können mit einem Firewalltest getestet werden:

  Dienst	Ergebnis
  Schlüsseltresor	Wenn der Zugang zu Key Vault blockiert ist, ist die direkteste Auswirkung das Fehlschlagen des Erzeugens neuer Pods. Der Key Vault CSI-Treiber, der Geheimnisse beim Podstart abruft, kann seine Aufgaben nicht ausführen und verhindert, dass der Pod gestartet wird. Entsprechende Fehlermeldungen können bei kubectl describe po CatalogService-deploy-my-new-pod -n workload beobachtet werden. Vorhandene Pods funktionieren weiterhin, obwohl dieselbe Fehlermeldung beobachtet wird. Die Fehlermeldung wird durch die Ergebnisse der regelmäßigen Updateprüfung auf Geheimnisse generiert. Obwohl nicht getestet, wird davon ausgegangen, dass das Ausführen einer Bereitstellung nicht funktioniert, während nicht auf Key Vault zugegriffen werden kann. Terraform- und Azure CLI-Aufgaben innerhalb der Pipeline führen Anforderungen an Key Vault aus.
  Event Hubs	Wenn der Zugriff auf Event Hubs blockiert ist, schlagen neue Nachrichten, die vom CatalogService und HealthService gesendet werden, fehl. Der Abruf von Nachrichten durch den BackgroundProcess schlägt langsam fehl, wobei der gesamte Fehler innerhalb weniger Minuten fehlschlägt.
  Azure Cosmos DB	Das Entfernen der vorhandenen Firewallrichtlinie für ein virtuelles Netzwerk führt dazu, dass der Integritätsdienst mit minimaler Verzögerung fehlschlägt. Dieses Verfahren simuliert nur einen bestimmten Fall, einen totalen Azure Cosmos DB-Ausfall. Die meisten Fehler, die auf regionaler Ebene auftreten, sollten automatisch durch ein transparentes Failover des Clients auf eine andere Azure Cosmos DB-Region aufgefangen werden. Die zuvor beschriebenen DNS-basierten Fehlereinschleusungstests sind ein aussagekräftigerer Test für Azure Cosmos DB.
  ACR (Azure Container Registry)	Wenn der Zugriff auf ACR blockiert ist, funktioniert die Erstellung neuer Pods, die zuvor auf einen AKS-Knoten gepullt und zwischengespeichert wurden, weiterhin. Die Erstellung funktioniert weiterhin aufgrund der k8s-BereitstellungskennzeichnungpullPolicy=IfNotPresent. Knoten, die vor der Blockierung kein Image gepullt und zwischengespeichert haben, können keinen neuen Pod erzeugen und schlagen sofort mit ErrImagePull-Fehlern fehl. kubectl describe pod zeigt die entsprechende 403 Forbidden-Meldung an.
  AKS-Eingangs-Load Balancer	Die Änderung der Eingangsregeln für HTTP(S)(Ports 80 und 443) in der von AKS verwalteten Netzwerksicherheitsgruppe (NSG) zu Verweigern führt dazu, dass der Datenverkehr von Benutzern oder aus dem Integritätstest den Cluster nicht erreicht. Bei der Prüfung dieses Fehlers ist es schwierig, die Grundursache zu ermitteln, die als Blockade zwischen dem Netzwerkpfad von Front Door und einem regionalen Stempel simuliert wurde. Front Door erkennt diesen Fehler sofort und nimmt den Stempel aus der Rotation.