Lernprogramm: Erstellen einer hoch verfügbaren Multi-Region-App in Azure App Service

Hochverfügbarkeit und Fehlertoleranz sind wesentliche Komponenten einer gut konzipierten Lösung. Eine robuste Konfiguration umfasst einen Notfallplan für unerwartete Fehler, um Ausfallzeiten zu reduzieren und Systeme automatisch laufen zu lassen.

Wenn Sie eine App in der Cloud bereitstellen, wählen Sie eine Region in dieser Cloud für die App-Infrastrukturbasis aus. Wenn Sie eine App nur in einer einzelnen Region bereitstellen und diese Region nicht mehr verfügbar ist, ist die App ebenfalls nicht verfügbar. Der Mangel an Verfügbarkeit kann unter den Bedingungen des Service Level Agreement (SLA) der App inakzeptabel sein. Um die Verfügbarkeit sicherzustellen, stellen Sie die App und ihre Dienste in mehreren Regionen in der Cloud bereit.

In diesem Lernprogramm wird beschrieben, wie Sie eine hochverwendige Web-App mit mehreren Regionen bereitstellen. Das Verfahren implementiert ein einfaches Szenario, das aus einer Web-App und Azure Front Door besteht. Sie können die Konzepte erweitern, um andere Infrastrukturmuster zu unterstützen. Wenn Ihre App beispielsweise eine Verbindung mit einem Azure Datenbankangebot oder Speicherkonto herstellt, lesen Sie Aktive Georeplikation für SQL-Datenbanken und Azure Storage Redundanz. Eine Referenzarchitektur für ein detaillierteres Szenario finden Sie im Reliable Web App-Muster für .NET.

In diesem Tutorial lernen Sie Folgendes:

Voraussetzungen

Wenn Sie kein Azure Konto haben, erstellen Sie ein free-Konto bevor Sie beginnen.

Für dieses Tutorial benötigen Sie Folgendes:

• Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Get started with Azure Cloud Shell.

  

• Wenn Sie CLI-Referenzbefehle lieber lokal ausführen möchten, install die Azure CLI. Wenn Sie Windows oder macOS verwenden, ziehen Sie in Betracht, Azure CLI in einem Docker-Container auszuführen. Weitere Informationen finden Sie unter How to run the Azure CLI in a Docker container.

  • Wenn Sie eine lokale Installation verwenden, melden Sie sich mit dem Befehl az login beim Azure CLI an. Um den Authentifizierungsprozess abzuschließen, führen Sie die in Ihrem Terminal angezeigten Schritte aus. Weitere Anmeldeoptionen finden Sie unter Authentifizieren bei Azure mithilfe von Azure CLI.

  • Wenn Sie dazu aufgefordert werden, installieren Sie die Azure CLI Erweiterung bei der ersten Verwendung. Weitere Informationen zu Erweiterungen finden Sie unter Use and manage extensions with the Azure CLI.

  • Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.

Überprüfen der Szenarioarchitektur

Das folgende Architekturdiagramm zeigt die Infrastruktur, die Sie in diesem Tutorial erstellen. Sie besteht aus zwei identischen App Service-Apps in separaten Regionen. Die erste Web-App befindet sich in der aktiven Region. Es ist die primäre App, die für die Verarbeitung eingehender Datenverkehr verantwortlich ist. Die zweite App befindet sich im Standbybereich und wartet auf die Verfügbarkeit der primären App. Azure Front Door versucht, den Datenverkehr an die primäre Web-App weiterzuleiten. Wenn die primäre Region nicht verfügbar ist, wird der Datenverkehr an das Standbyweb weitergeleitet. Im Diagramm stellt die gepunktete Linie das Routing des Datenverkehrs auf Grundlage des Regionsstatus dar. Zugriffsbeschränkungen sind so konfiguriert, dass der direkte Zugriff auf die Apps über das Internet blockiert wird.

Azure bietet verschiedene Optionen für den Lastenausgleich und das Datenverkehrsrouting. Azure Front Door ist für dieses Lernprogramm ausgewählt, da es internetorientierte Web-Apps umfasst, die auf Azure App Service in mehreren Regionen bereitgestellt werden. Wenn sich Ihre Konfiguration vom Beispiel in diesem Lernprogramm unterscheidet, sehen Sie Auswählen einer Lastenausgleichslösung für Ihr Szenario.

Das Szenario in diesem Lernprogramm bietet das folgende Verhalten:

• Identische App Service-Apps werden in zwei separaten Regionen bereitgestellt.
• Der öffentliche Datenverkehr, der direkt an die Web-Apps gesendet wird, wird blockiert.
• Azure Front Door leitet den Datenverkehr an die aktive App in der primären Region weiter.
• Die Standby-App in der sekundären Region ist bei Bedarf bereit, den Datenverkehr zu bedienen.

Erstellen einer Ressourcengruppe

Für dieses Lernprogramm benötigen Sie zwei Instanzen einer Web-App, die in verschiedenen Azure Regionen ausgeführt wird.

1. Überprüfen Sie die verfügbaren Regionspaare , und wählen Sie zwei gekoppelte Regionen für Ihre Web-Apps aus.

   In diesem Lernprogramm werden die beiden Regionen als <primary-region> (eastus) und <standby-region> (westus) bezeichnet.

2. Erstellen Sie eine Ressourcengruppe für alle Ressourcen, die Sie in diesem Lernprogramm konfigurieren. In diesem Lernprogramm wird die Ressourcengruppe am <primary-region> Standort erstellt.

   az group create --name <resource-group> --location <primary-region>
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --name	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --location	<primary-region>	Der Standort der Region für die Ressourcengruppe. In diesem Lernprogramm wird dieselbe Region für die Ressourcengruppe und die primäre Webanwendung verwendet.	eastus

   Verwenden Sie in einer tatsächlichen Implementierung separate Ressourcengruppen für jede Region/Ressource. Die Trennung ermöglicht die Isolierung von Ressourcen in einer Notfallwiederherstellungssituation.

   Weitere Informationen finden Sie in der Az Group Create Command Reference.

Erstellen von zwei App Service-Plänen

Erstellen Sie zwei App Service-Pläne, eine für jede Web-App. Erstellen Sie jeden Plan am Standort der Region, an dem Sie die entsprechende App erstellen möchten.

Für diesen Befehl verwenden Sie das Bereichspaar , das Sie zuvor ausgewählt haben. Verwenden Sie die aktive Region für die primäre Web-App und die passive Region für die Standby-Web-App.

Führen Sie den folgenden Befehl aus, um den App Service-Plan für die primäre Web-App zu erstellen, und führen Sie den Befehl erneut aus, um den Plan für die Standby-App zu erstellen.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

Weitere Informationen finden Sie im Az appservice plan create command reference.

Erstellen von zwei Anwendungen

Erstellen Sie zwei App Service-Web-Apps. Platzieren Sie jede App an einem entsprechenden App Service-Plan und an einem entsprechenden Standort der Region.

1. Identifizieren Sie die --runtime Sprachversion für die Web-Apps.

   Sie können den folgenden Befehl für die Liste der verfügbaren Laufzeiten ausführen:

   az webapp list-runtimes
   

   Wenn Sie die in diesem Lernprogramm beschriebene Beispiel-Node.js App verwenden möchten, legen Sie den <language-version> Wert auf NODE:24-lts.

2. Erstellen Sie zwei Web-Apps. Führen Sie den folgenden Befehl aus, um die primäre Web-App zu erstellen, und führen Sie den Befehl erneut aus, um die Standby-App zu erstellen.

   az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --name	<web-app-name>	Der Name der Web-App. Jede App muss einen global eindeutigen Namen haben. Die gültigen Zeichen sind a-z, 0-9und -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --name	<app-service-plan>	Der Name des App-Dienstplans für die Web-App.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	Die Laufzeitsprachenversion für die Web-App.	NODE:24-lts

   Weitere Informationen finden Sie in der Az webapp create command reference.

3. Identifizieren Sie den defaultHostName Wert für jede Web-App. Das Hostnamenformat ist <web-app-name>.azurewebsites.net.

   Scannen Sie die Befehlsausgabe für jede Web-App, und suchen Sie den Wert, oder führen Sie den folgenden Befehl für jede Web-App aus:

   az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --name	<web-app-name>	Der Name der Web-App.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group

   Im Azure-Portal ist der Hostname für jede App auf der Web-App Overviewseite sichtbar.

   Notieren Sie die Hostnamenwerte für später. Sie verwenden die Hostnamen, um die Back-End-Adressen für Azure Front Door Bereitstellung zu definieren.

4. Bestätigen Sie, dass Sie auf die neuen Web-Apps zugreifen können.

   1. Geben Sie in einem Browser den Hostnamen für die primäre Web-App ein, z. B. zava-primary-app.azurewebsites.net.

      Wenn die Verbindung erfolgreich ist, wird die folgende Meldung angezeigt:

      

   2. Wiederholen Sie den Test mit dem Hostnamen für Ihre Standby-Web-App.

Konfigurieren von Azure Front Door

Eine Bereitstellung mit mehreren Regionen kann eine aktiv-aktive oder aktiv-passive Konfiguration verwenden. Die primäre Region ist aktiv, und der Standbybereich ist passiv.

• Bei einer Aktiv/Aktiv-Konfiguration werden Anforderungen auf mehrere aktive Regionen verteilt.
• Eine aktiv-passive Konfiguration führt Instanzen im Standbybereich (passiv) weiter, sendet jedoch keinen Datenverkehr an diese Region, es sei denn, der primäre (aktive) Bereich schlägt fehl.

mit Azure Front Door können Sie beide Konfigurationen aktivieren. Weitere Informationen zum Entwerfen von Apps für hohe Verfügbarkeit und Fehlertoleranz finden Sie in der Prüfliste zur Entwurfsüberprüfung zur Zuverlässigkeit.

Erstellen eines Profils

Erstellen Sie eine Instanz von Azure Front Door Premium zum Weiterleiten von Datenverkehr an Ihre Web-Apps.

1. Überprüfen Sie den Azure Front Door Tiervergleich und wählen Sie die Stufe für Ihre Bereitstellung aus.

   In diesem Lernprogramm wird Azure Front Door Premium (Premium_AzureFrontDoor) verwendet.

   Wenn Sie Azure Front Door Standard bereitstellen möchten, beachten Sie, dass die Standardebene die Bereitstellung von verwalteten Regeln mit der WAF-Richtlinie nicht unterstützt.

2. Führen Sie den folgenden Befehl aus, um das Profil zu erstellen:

   az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --profile-name	<front-door-profile>	Der Name für das Azure Front Door Profil. Der Name muss innerhalb der Ressourcengruppe eindeutig sein.	zava-profile
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --sku	<front-door-tier>	Die Tarif-SKU von Azure Front Door für die Bereitstellung.	Premium_AzureFrontDoor (empfohlen) Standard_AzureFrontDoor

   Weitere Informationen finden Sie im Befehlsreferenz zu az afd profile create.

Hinzufügen eines Endpunkts

Erstellen Sie einen Endpunkt in Ihrem Profil. Nachdem Sie den ersten Endpunkt erstellt haben, können Sie mehrere Endpunkte in Ihrem Profil erstellen.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

Weitere Informationen finden Sie in der Befehlsreferenz für az afd endpoint create.

Erstellen einer Ursprungsgruppe

Wenn Sie auf Azure Front Door deployen, benötigen Sie einen Ursprungs-Server, der als Endpunkt für das Back-End Ihrer Webanwendung dient. Weitere Informationen finden Sie unter Origins und Ursprungsgruppen in Azure Front Door. Die Ursprünge werden in einer Ursprungsgruppe gespeichert.

Erstellen Sie eine Ursprungsgruppe in Ihrem Azure Front Door Profil, um Ursprünge für Ihre beiden Web-Apps zu enthalten.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

Weitere Informationen finden Sie in der Befehlsreferenz zu az afd origin-group create.

Hinzufügen von Ursprüngen zur Ursprungsgruppe

Fügen Sie ihrer Azure Front Door Ursprungsgruppe einen Ursprung für jede Ihrer Web-Apps hinzu.

1. Fügen Sie einen Ursprung für die primäre Web-App hinzu. Legen Sie den Parameter --priority auf 1 fest, wodurch Azure Front Door informiert wird, dass diese App der primäre Empfänger für Datenverkehr ist.

   az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
      --origin-group-name <front-door-origin-group> \
      --origin-name <web-app-origin-name> \
      --origin-host-header <web-app-name>.azurewebsites.net \
      --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
      --http-port <origin-port> --https-port <origin-secure-port>
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	Der Hostname für Ihre primäre Web-App. Der Hostname kombiniert den Web-App-Namen, wie z. B. zava-primary-app, mit dem Hostbezeichner azurewebsites.net.	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	Der Name Ihres Azure Front Door Profils.	zava-profile
   --origin-group-name	<front-door-origin-group>	Der Name der Azure Front Door Ursprungsgruppe.	zava-origin-group
   --origin-name	<web-app-origin-name>	Der Name des Ursprungs für die primäre Webanwendung. Der Name muss innerhalb der Ursprungsgruppe eindeutig sein.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	Der Hostheader, der für Anforderungen an den primären Ursprung der Webanwendung gesendet werden muss. Wenn Sie keinen Wert angeben, bestimmt der Anforderungshost diesen Wert. Azure CDN Ursprünge, z. B. Web-Apps, Blob Storage und Cloud Services, verlangen, dass dieser Hostheader standardmäßig mit dem Ursprungshostnamen übereinstimmt.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	Die Priorität für diesen Ursprung innerhalb der Ursprungsgruppe. Legen Sie für die primäre Web-App die Priorität auf 1 fest. Azure Front Door verwendet die Prioritätswerte für den Lastenausgleich über Ursprünge und aktive Regionen hinweg. Der Wert muss zwischen 1 und 5 sein.	1
   --weight	<origin-weight>	Die Gewichtung des Ursprungs innerhalb der Ursprungsgruppe für den Lastenausgleich. Der Wert muss zwischen 1 und 1000 sein.	1000
   --enabled-state	<origin-state>	Gibt an, ob dieser Ursprung für den Empfang von Datenverkehr aktiviert werden soll.	Enabled
   --http-port	<origin-port>	Der Port, der für HTTP-Anforderungen an den Ursprung verwendet wird.	80
   --https-port	<origin-secure-port>	Der Port, der für sichere HTTPS-Anforderungen an den Ursprung verwendet wird.	443

   Weitere Informationen finden Sie in der Befehlsreferenz az afd origin create.

2. Führen Sie den Befehl erneut aus und fügen Sie eine Herkunft für die Standby-Webapp hinzu. Der Befehl verwendet dieselben Parameter, aber mit den folgenden eindeutigen Parameterwerten:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --host-name	<web-app-name>.azurewebsites.net	Der Hostname für Ihre Standby-Web-App.	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	Der Name des Ursprungs für die Standby-Web-App.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	Der Hostheader, der für Anforderungen an den Ursprung der Standby-Webanwendung gesendet werden soll.	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	Die Priorität für diesen Ursprung innerhalb der Ursprungsgruppe. Legen Sie für die Standby-Web-App die Priorität auf 2 fest. Azure Front Door versucht, den gesamten Datenverkehr an den primären Ursprung zu leiten. Wenn die primäre Quelle nicht verfügbar ist, wird der Datenverkehr zur Standby-Quelle umgeleitet.	2

Hinzufügen einer Routenregel

Fügen Sie eine Routingregel hinzu, um den Azure Front Door Endpunkt der Ursprungsgruppe zuzuordnen. Die Route leitet Anforderungen vom Endpunkt an Ihre Ursprungsgruppe weiter.

1. Erstellen Sie eine Routenregel, um den Azure Front Door Endpunkt der Ursprungsgruppe zuzuordnen:

   az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
      --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
      --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link> 
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --profile-name	<front-door-profile>	Der Name Ihres Azure Front Door Profils.	zava-profile
   --endpoint-name	<front-door-endpoint>	Der Name des Endpunkts unter Ihrem Azure Front Door Profil.	zava-endpoint
   --forwarding-protocol	<protocol-type>	Das Protokoll, das von dieser Routenregel beim Weiterleiten des Datenverkehrs an die Back-End-Apps verwendet wird.	MatchRequest
   --route-name	<route-rule-name>	Der Name der Routenregel. Muss innerhalb des Azure Front Door-Profils eindeutig sein.	zava-route-rule
   --https-redirect	<secure-redirect>	Gibt an, ob HTTP-Datenverkehr automatisch an HTTPS-Datenverkehr umgeleitet werden soll.	Enabled
   --origin-group-name	<front-door-origin-group>	Der Name der Azure Front Door Ursprungsgruppe.	zava-origin-group
   --supported-protocols	<protocol-list>	Die Liste der unterstützten Protokolle für diese Routenregel. Verwenden Sie ein Leerzeichen, um die Protokolltypen zu trennen.	Http Https
   --link-to-default-domain	<domain-link>	Gibt an, ob diese Route mit der Standardendpunktdomäne verknüpft ist.	Enabled

   Weitere Informationen finden Sie in der Befehlsreferenz zu az afd route create.

2. Lassen Sie etwa 15 Minuten für die Bereitstellung. Es kann einige Zeit dauern, bis die Änderungen global verteilt werden.

Zugriff nur über Azure Front Door einschränken

Sie können derzeit direkt auf Ihre Web-Apps zugreifen, indem Sie deren Hostnamen in einen Browser eingeben. Wenn Sie Zugriffsbeschränkungen für Ihre Apps festlegen, können Sie sicherstellen, dass der Datenverkehr Ihre Apps nur über Azure Front Door erreicht.

Azure Front Door Features funktionieren am besten, wenn der Datenverkehr nur über den Dienst fließt. Es empfiehlt sich, Ihre Web-App-Ursprünge so zu konfigurieren, dass Datenverkehr blockiert wird, der nicht über Azure Front Door gesendet wird. Sonst kann der Datenverkehr die Azure Front Door Webanwendungsfirewall, den DDoS-Schutz und andere Sicherheitsfunktionen umgehen.

Der Datenverkehr von Azure Front Door zu Ihren Apps stammt aus einer bekannten Gruppe von IP-Bereichen, die im AzureFrontDoor.Backend-Diensttag definiert sind. Mithilfe einer Einschränkungsregel für Service-Tags können Sie den Datenverkehr darauf beschränken, nur von Azure Front Door zu stammen.

1. Rufen Sie den Bezeichner für Ihr Azure Front Door Profil ab.

   Sie benötigen die Profil-ID, um sicherzustellen, dass der Datenverkehr nur von Ihrer spezifischen Azure Front Door Instanz stammt. Die Zugriffseinschränkung filtert die eingehenden Anforderungen basierend auf dem eindeutigen HTTP-Header, der aus Ihrem Azure Front Door Profil gesendet wurde.

   az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --profile-name	<front-door-profile>	Der Name Ihres Azure Front Door Profils.	zava-profile

   Die Befehlsausgabe zeigt die Profil-ID an (32-stelliger alphanumerischer Wert):

   "0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"
   

   Im nächsten Schritt verwenden Sie die Profil-ID für den <profile-identifier> Wert.

2. Führen Sie den folgenden Befehl aus, um Zugriffsbeschränkungen für Ihre primäre Web-App festzulegen, und führen Sie den Befehl erneut aus, um Einschränkungen für die Standby-App festzulegen.

   az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
      --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --name	<web-app-name>	Der Name der Web-App, für die Sie Zugriffsbeschränkungen festlegen.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Geben Sie die Priorität der Zugriffseinschränkungsregel für alle für das Profil definierten Regeln an. Ein niedrigerer Wert entspricht einer höheren Priorität.	100
   --service-tag	<tag-name>	Ein von Azure Front Door erkannter Diensttagname. Die Zugriffsbeschränkungen gelten für den IP-Bereich, der durch das Diensttag angegeben wird.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Geben Sie einen oder mehrere eindeutige HTTP-Header für zusätzliche Filterung eingehenden Datenverkehrs an. Die Zugriffseinschränkungen filtern die eingehenden Anforderungen basierend auf dem eindeutigen HTTP-Header, der von Ihrem Azure Front Door Profil gesendet wurde. Die Kopfzeile kombiniert das Azure Front Door-Präfix und den Profilbezeichner für die Azure Front Door-Instanz.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Weitere Informationen finden Sie in der Befehlsreferenz zu az webapp config access-restriction add.

Testen von Zugriffsbeschränkungen

Bestätigen Sie, dass Ihre Zugriffsbeschränkungen den direkten Zugriff auf Ihre Apps verhindern.

1. Geben Sie in einem Browser den Hostnamen für die primäre Web-App ein, z. B. zava-primary-app.azurewebsites.net.

   Die Verbindung sollte mit der folgenden Meldung fehlschlagen:

   

2. Wiederholen Sie den Test mit dem Hostnamen für Ihre Standby-Web-App, z.B. zava-standby-app.azurewebsites.net.

Azure Front Door-Bereitstellung testen

Wenn Sie das Azure Front Door Standard- oder Premium-Profil erstellen, kann es einige Zeit dauern, bis die Konfiguration global bereitgestellt wird. Nach Abschluss der Bereitstellung können Sie auf den Frontend-Host zugreifen.

1. Rufen Sie den Hostnamen Ihres Azure Front Door-Endpunkts ab:

   az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"
   

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

   Parameter	Wert	BESCHREIBUNG	Beispiel
   --resource-group	<resource-group>	Die Ressourcengruppe, die die in diesem Lernprogramm erstellten Ressourcen enthält.	zava-resource-group
   --profile-name	<front-door-profile>	Der Name Ihres Azure Front Door Profils.	zava-profile
   --endpoint-name	<front-door-endpoint>	Der Name des Endpunkts unter Ihrem Azure Front Door Profil.	zava-endpoint

   Die Befehlsausgabe zeigt den Endpunkthostnamen an:

   "zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"
   

   Der Hostname besteht aus dem Endpunktnamen, einem eindeutigen alphanumerischen Hash, einem Bezeichner und dem Azure Front Door Suffix. Im nächsten Schritt verwenden Sie den Endpunkthostnamen.

   Weitere Informationen finden Sie in der Befehlsreferenz zu az afd endpoint show.

2. Geben Sie in einem Browser den Endpunkt-Hostnamen wie z. B. zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net ein.

   Ihre Anforderung sollte automatisch an Ihre primäre App in der aktiven Region weitergeleitet werden.

   Wenn die Verbindung erfolgreich ist, wird die folgende Meldung angezeigt:

   

3. Testen Sie das sofortige globale Failover zwischen den Apps in den gekoppelten Regionen.

   1. Geben Sie in einem Browser den Endpunkt-Hostnamen ein, zum Beispiel zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Beenden Sie die primäre App, indem Sie den Befehl "az webapp stop " ausführen.

      Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

      az webapp stop --name <primary-web-app> --resource-group <resource-group>
      

   3. Aktualisieren Sie Ihren Browser.

      Wenn Datenverkehr ordnungsgemäß an die Standby-App in der anderen Region umgeleitet wurde, sollte die gleiche Seite und Meldung angezeigt werden.

      Tipp

      Möglicherweise müssen Sie die Seite mehrmals aktualisieren, bis das Failover abgeschlossen ist.

      Sie können bestätigen, dass Azure Front Door zur Standby-App umgeleitet wird, indem Sie den Status der Web-Apps im Azure-Portal überprüfen. Auf der Seite "Übersicht" für die primäre Web-App sollte die Startoption verfügbar sein (nicht abgeblennt). Auf der Seite "Übersicht" für die Standby-Web-App sollte die Startoption nicht verfügbar sein (grau).

   4. Führen Sie den az webapp stop Befehl erneut aus, und beenden Sie die Standby-App .

      Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

      az webapp stop --name <standby-web-app> --resource-group <resource-group>
      

   5. Aktualisieren Sie Ihren Browser erneut.

      Wenn die Standby-App auch stoppt, sollte der gesamte Datenverkehr gestoppt werden. Dieses Mal sollte eine Fehlermeldung angezeigt werden:

      

   6. Führen Sie den az webapp start Befehl aus, und starten Sie die Standby-App neu.

      Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen:

      az webapp start --name <standby-web-app> --resource-group <resource-group>
      

   7. Aktualisieren Sie Ihren Browser, und Es sollte eine erfolgreiche App-Verbindung angezeigt werden.

Die Überprüfung bestätigt, dass Sie jetzt wie vorgesehen auf Ihre Apps über Azure Front Door- und Failoverfunktionen zugreifen können.

Wenn Sie mit Failovertests fertig sind, starten Sie die primäre App neu.

Bereinigen von Ressourcen

In den vorherigen Schritten haben Sie Azure Ressourcen in einer Ressourcengruppe erstellt. Wenn Sie nicht erwarten, dass diese Ressourcen in Zukunft benötigt werden, löschen Sie die Ressourcengruppe, indem Sie den folgenden Befehl in der Cloud Shell ausführen.

Ersetzen Sie den <placeholder> Parameterwert durch die Informationen für Ihre eigene Ressource:

az group delete --name <resource-group>

Die Ausführung dieses Befehls kann einige Minuten dauern.

Bereitstellung von ARM oder Bicep

Die in diesem Lernprogramm erstellten Ressourcen können mithilfe einer Azure Resource Manager Vorlage (ARM-Vorlage) oder Bicep Vorlage bereitgestellt werden. Sie können mit der hochmodernen, multi-regionalen Web-App-Bicep-Datei auf GitHub beginnen. Mit dieser Vorlage können Sie eine sichere, hoch verfügbare End-to-End-Lösung mit zwei Web-Apps in verschiedenen Regionen hinter Azure Front Door erstellen.

Informationen zum Bereitstellen von ARM- und Bicep-Vorlagen finden Sie unter Deploy Bicep-Dateien mit dem Azure CLI.

Häufig gestellte Fragen

In diesem Lernprogramm haben Sie eine Basisinfrastruktur bereitgestellt, um eine Mehrregion-Web-App zu aktivieren. Der App-Dienst bietet Features, mit denen Sie sicherstellen können, dass Sie Anwendungen ausführen, die bewährte Methoden und Empfehlungen für die Sicherheit befolgen.

Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen, mit denen Sie Ihre Apps weiter schützen und Ihre Ressourcen entsprechend bewährten Methoden bereitstellen und verwalten können.

Verwalten und Bereitstellen von Infrastruktur- und Azure-Ressourcen

In diesem Lernprogramm haben Sie die Azure CLI verwendet, um Ihre Infrastrukturressourcen bereitzustellen. Erwägen Sie die Konfiguration eines Continuous Deployment-Mechanismus zum Verwalten Ihrer Anwendungsinfrastruktur. Da Sie Ressourcen in verschiedenen Regionen bereitstellen, müssen Sie diese Ressourcen in den Regionen unabhängig verwalten. Um sicherzustellen, dass die Ressourcen in den einzelnen Regionen identisch sind, sollte Infrastruktur als Code (IaC), wie ein ARM-Template oder Terraform, mit Bereitstellungspipelines wie Azure Pipelines oder GitHub-Actions verwendet werden. Wenn Sie diese Konfiguration entsprechend einrichten, löst jede Änderung an Ressourcen Updates in allen Bereitstellungsregionen aus. Weitere Informationen finden Sie unter Konfigurieren von kontinuierlicher Bereitstellung für Azure App Service.

Verwenden Sie Staging-Slots für die sichere Bereitstellung in der Produktionsumgebung

Das direkte Bereitstellen von Anwendungscode in Produktions-Apps und Slots wird nicht empfohlen. Es ist wichtig, dass Sie einen sicheren Ort haben, um Ihre Apps zu testen und Änderungen zu überprüfen, bevor Sie zur Produktion wechseln. Verwenden Sie eine Kombination aus Staging-Slots und Slot-Swap, um Code aus der Testumgebung in die Produktion zu verschieben.

In dieser Anleitung haben Sie die Basisinfrastruktur erstellt, die den Einsatz von Staging-Slots ermöglicht. Sie können Bereitstellungsplätze für jede Instanz Ihrer Web-App erstellen und die kontinuierliche Bereitstellung für diese Stagingplätze mit GitHub Actions konfigurieren. Wie bei der Infrastrukturverwaltung wird auch die Konfiguration der kontinuierlichen Bereitstellung für Den Anwendungsquellcode empfohlen, um sicherzustellen, dass Änderungen in allen Regionen synchronisiert bleiben. Wenn Sie die kontinuierliche Bereitstellung nicht konfigurieren, müssen Sie jede App in jeder Region bei jeder Codeänderung manuell aktualisieren.

Gehen Sie wie folgt vor, um Staging-Slots zu verwenden:

1. Für dieses Verfahren benötigen Sie eine App, die für die Bereitstellung in Ihrer App Service-App bereit ist.

   Falls Sie das Tutorial abgeschlossen haben, können Sie Ihre primäre Web-App und die Standby-Web-App verwenden. Sie benötigen jedoch einen App Service-Plan, der ausreichende Bereitstellungsplätze unterstützt. Weitere Informationen finden Sie unter Azure Abonnement- und Dienstbeschränkungen, Kontingente und Einschränkungen.

   Wenn Sie nicht über eine App verfügen, können Sie mit der beispiel-App Node.js Hallo Welt beginnen. Forken Sie das GitHub-Repository, damit Sie Ihre eigene Kopie haben, um Änderungen daran vorzunehmen.

2. Konfigurieren Sie die App Service-Stapeleinstellungen für Ihre Web-Apps.

   Stapeleinstellungen beziehen sich auf die Für Ihre App verwendete Sprachversion oder Laufzeit.

   Sie können die Einstellungen im Azure Portal konfigurieren oder den Befehl az webapp config set verwenden. Wenn Sie das Node.js Beispiel verwenden, legen Sie die Stapeleinstellungen auf Node 24 LTS.

   1. Wechseln Sie im Azure-Portal zu Ihrer primary Web-App.

   2. Wählen Sie im linken Menü die Option "Einstellungenkonfiguration"> aus.

   3. Konfigurieren Sie auf der Registerkarte "Stapeleinstellungen " die folgenden Einstellungen:

      1. Wählen Sie den Stapelwert aus, z. B. Node.

      2. Wählen Sie den Versionswert aus, z. B. Node 24 LTS.

      3. Wählen Sie Anwenden.

   4. Wiederholen Sie den Vorgang, um die App Service-Stapeleinstellungen für Ihre Standby-Web-App zu konfigurieren.

3. Einrichten der kontinuierlichen Bereitstellung im Azure-Portal. Ausführliche Anleitungen zum Konfigurieren der kontinuierlichen Bereitstellung mit Anbietern wie GitHub Actions finden Sie unter Configure continuous deployment to Azure App Service.

4. Führen Sie den folgenden Befehl aus, um einen Staging-Slot mit dem Namen stage für Ihre primäre Web-App zu erstellen.

   az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>
   

5. Führen Sie den az webapp deployment slot create Befehl erneut aus und erstellen Sie einen Staging-Slot mit dem Namen stage für die Standby-Web-App.

6. Konfigurieren Sie die kontinuierliche Bereitstellung mit GitHub Actions für jeden Staging-Slot:

   1. Wechseln Sie im Azure-Portal zu Ihrer primary Web-App.

   2. Wählen Sie im linken Menü Bereitstellung>Bereitstellungsplätze aus.

   3. Suchen Sie den Stage-Platz in der Liste, und wählen Sie den Platz aus, um den Detailbereich zu öffnen.

   4. Wählen Sie im linken Menü Bereitstellung>Bereitstellungscenter aus.

   5. Legen Sie auf der Registerkarte Settings die Option Source auf GitHub fest:

      

   6. Wenn Sie zum ersten Mal aus GitHub bereitstellen, wählen Sie Authorize aus, und folgen Sie den Autorisierungsaufforderungen. Wenn Sie die Bereitstellung aus dem Repository eines anderen Benutzers durchführen möchten, klicken Sie auf Konto ändern.

   7. Nachdem Sie Ihr Azure Konto mit GitHub autorisiert haben, wählen Sie die Organization, Repository und Branch zum Konfigurieren von CI/CD aus. Wenn Sie eine Organisation oder ein Repository nicht finden können, müssen Sie möglicherweise weitere Berechtigungen für GitHub aktivieren. Weitere Informationen finden Sie unter Verwalten des Benutzerzugriffs auf die Repositorys Ihrer Organisation.

      Wenn Sie die Node.js-Beispiel-App verwenden, verwenden Sie die folgenden Einstellungen.

      Einstellung	Wert
      Organisation	<your-GitHub-organization>
      Repository	nodejs-docs-hello-world
      Filiale	Standard

   8. Wählen Sie Speichern aus.

Neue Commits im ausgewählten Repository und Branch werden nun fortlaufend in Ihrem App Service-App-Slot bereitgestellt. Sie können die Commits und Bereitstellungen auf der Registerkarte Protokolle nachverfolgen.

Eine Standardworkflowdatei, die ein Veröffentlichungsprofil zur Authentifizierung bei App Service verwendet, wird Ihrem GitHub-Repository hinzugefügt. Sie können diese Datei anzeigen, indem Sie zum Verzeichnis <repo-name>/.github/workflows/ wechseln.

Deaktivieren der Standardauthentifizierung für App Service

Sie können den Zugriff auf die FTP- und SCM-Endpunkte auf Benutzer beschränken, die von Microsoft Entra ID authentifiziert werden, indem Sie die Standardauthentifizierung deaktivieren.

Wenn Sie ein Tool für die kontinuierliche Bereitstellung verwenden, um Den Anwendungsquellcode bereitzustellen, erfordert das Deaktivieren der Standardauthentifizierung zusätzliche Schritte zum Konfigurieren der kontinuierlichen Bereitstellung. Sie können z. B. kein Veröffentlichungsprofil verwenden, da es nicht Microsoft Entra Anmeldeinformationen verwendet. Stattdessen müssen Sie entweder einen Dienstprinzipal oder OpenID Connect-Anmeldeinformationen verwenden.

Die folgenden Befehle deaktivieren die einfache Authentifizierung für die primäre Web-App und den Staging-Slot des App Service sowie die Standby-Web-App und den Staging-Slot. Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen.

1. Deaktivieren Sie den FTP-Zugriff für die Produktionswebsites und Stagingplätze für Ihre primäre Web-App:

   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name>/slots/stage --set properties.allow=false
   

2. Führen Sie die Befehle für Ihre Standby-Web-App erneut aus.

3. Deaktivieren Sie den Standardauthentifizierungszugriff auf den WebDeploy-Port und die SCM-Website für die Produktionswebsites und Stagingplätze für Ihre primäre Web-App:

   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app>/slots/stage --set properties.allow=false
   

4. Führen Sie die Befehle für Ihre Standby-Web-App erneut aus.

Weitere Informationen zum Deaktivieren der Standardauthentifizierung, einschließlich des Testens und Überwachens von Anmeldungen, finden Sie unter Deaktivieren der Standardauthentifizierung in App Service-Bereitstellungen.

Kontinuierliche Bereitstellung verwenden, wenn die Standardauthentifizierung deaktiviert ist

Wenn Sie die Standardauthentifizierung für Ihre App Service-Apps zulassen, können Sie eine der verfügbaren Bereitstellungsmethoden für App Service verwenden. Sie können beispielsweise das Veröffentlichungsprofil verwenden, das Sie im Abschnitt "Bereitstellungs-Slots" konfiguriert haben.

Wenn Sie die Standardauthentifizierung für Ihre App Service-Apps deaktivieren, erfordert die kontinuierliche Bereitstellung einen Dienstprinzipal oder OpenID Connect für die Authentifizierung. Wenn Sie GitHub Actions als Code-Repository verwenden, lesen Sie die Deploy to Azure App Service by using GitHub Actions. Das Lernprogramm enthält schrittweise Anleitungen zum Erstellen eines Dienstprinzipals oder von OpenID Connect zum Bereitstellen in App Service mithilfe von GitHub Actions. Sie können den Vorgang auch abschließen, indem Sie das Verfahren im nächsten Abschnitt ausführen.

Erstellen Sie ein Diensthauptkonto und Anmeldeinformationen mit GitHub Actions.

Konfigurieren der kontinuierlichen Bereitstellung mit GitHub Actions und einem Dienstprinzipal:

1. Erstellen Sie den Dienstprinzipal für Ihre primäre Web-App und Standby-Web-App:

   Ersetzen Sie die folgenden <placeholder> Parameterwerte durch die Informationen für Ihre eigenen Ressourcen.

   az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
   

   Die Ausgabe ist ein JSON-Objekt mit den Anmeldeinformationen für die Rollenzuweisung, die Zugriff auf Ihre App Service-Apps gewähren.

   {
     "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
     "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "activeDirectoryGraphResourceId": "https://graph.windows.net/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
     "galleryEndpointUrl": "https://gallery.azure.com/",
     "managementEndpointUrl": "https://management.core.windows.net/"
   }
   

   Der JSON-Code enthält Ihren geheimen Clientschlüssel, der derzeit nur angezeigt wird.

   Tipp

   Es empfiehlt sich, mindesten Zugriff zu gewähren. In diesem Beispiel ist der Bereich nur auf die Apps beschränkt, nicht auf die gesamte Ressourcengruppe.

2. Kopieren Sie das JSON-Objekt, damit Sie einen Datensatz Ihres Client-Geheimnisses haben.

3. Stellen Sie Ihre Dienstanmeldeinformationen für die Azure-Anmeldung als Teil des GitHub-Aktionsworkflows bereit.

   Sie können die Werte direkt im Workflow bereitstellen oder als GitHub geheimen Schlüssel speichern, auf die in Ihrem Workflow verwiesen wird. Das Speichern der Werte als GitHub geheimen Schlüssel ist die sicherere Option.

   1. Öffnen Sie das GitHub Repository für Ihre App.

   2. Gehen Sie zu Einstellungen>Sicherheit>Geheimnisse und Variablen>Aktionen.

   3. Wählen Sie "Neuer Repositoryschlüssel " aus, und erstellen Sie für jede der folgenden Einstellungen einen geheimen Schlüssel. Verwenden Sie die Werte aus Ihrer JSON-Ausgabe.

      Einstellung	Wert	Beispiel
      AZURE_APP_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD	<client-secret>	ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

Erstellen Sie einen GitHub Actions Workflow

Nachdem Sie über einen Dienstprinzipal verfügen, der auf Ihre App Service-Apps zugreifen kann, bearbeiten Sie die Standardworkflows für Ihre Apps. Diese Workflows werden automatisch generiert, wenn Sie die kontinuierliche Bereitstellung konfigurieren.

Die Authentifizierung muss über Ihren Dienstprinzipal anstelle des Veröffentlichungsprofils erfolgen. Beispielworkflows finden Sie auf der Registerkarte Service principal unter Fügen Sie die Workflow-Datei zu Ihrem GitHub-Repository hinzu. Der folgende Beispielworkflow kann für die Node.js Beispiel-App verwendet werden.

1. Öffnen Sie das GitHub Repository für Ihre App.

2. Wechseln Sie zum Verzeichnis <repo-name>/.github/workflows/. Die automatisch generierten Workflows sollten angezeigt werden.

3. Wählen Sie für jede Workflowdatei "Bearbeiten" (Bleistift) aus.

4. Ersetzen Sie den Inhalt der Workflowdatei durch den folgenden Inhalt. Der Code geht davon aus, dass Sie bereits die GitHub-Geheimnisse für Ihre Zugangsdaten erstellt haben.

   Konfigurieren Sie im env Abschnitt die folgenden Einstellungen:

   • AZURE_WEBAPP_NAME: Ersetzen Sie den <web-app-name> Platzhalter durch den Namen Ihrer Web-App.
   • NODE_VERSION: Geben Sie die zu verwendende Knotenversion an. Für das Node.js Beispiel lautet der Wert '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATH: Geben Sie den Pfad zu Ihrem Web App-Projekt an. Der Standardwert ist das Stammverzeichnis des Repositorys, '.'.
   • AZURE_WEBAPP_SLOT_NAME: Geben Sie den Namen des Anwendungsslots an. Der allgemeine Name lautet stage.

   
    name: Build and deploy Node.js app to Azure Web App
   
    on:
      push:
        branches:
          - main
      workflow_dispatch:
   
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
      NODE_VERSION: '24.x'                # Node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
      AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name
   
    jobs:
      build:
        runs-on: ubuntu-latest
   
        steps:
          - uses: actions/checkout@v4
   
          - name: Set up Node.js version
            uses: actions/setup-node@v4
            with:
              node-version: ${{ env.NODE_VERSION }}
   
          - name: npm install, build
            run: |
              npm install
              npm run build --if-present
   
          - name: Upload artifact for deployment job
            uses: actions/upload-artifact@v4
            with:
              name: node-app
              path: .
   
      deploy:
        runs-on: ubuntu-latest
        needs: build
        environment:
          name: 'stage'
          url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
   
        steps:
          - name: Download artifact from build job
            uses: actions/download-artifact@v4
            with:
              name: node-app
   
          - uses: azure/login@v2
            with:
              creds: |
                {
                  "clientId": "${{ secrets.AZURE_APP_ID }}",
                  "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                  "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                  "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
                }
   
          - name: 'Deploy to Azure Web App'
            id: deploy-to-webapp
            uses: azure/webapps-deploy@v3
            with:
              app-name: ${{ env.AZURE_WEBAPP_NAME }}
              slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
              package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
          - name: logout
            run: |
              az logout
   

5. Speichern und übernehmen Sie die Workflowdateiänderungen direkt in den Hauptzweig Ihres Repositorys.

   Der Commit löst die GitHub Aktion aus, um erneut ausgeführt zu werden und den Code bereitzustellen. Dieses Mal wird der Dienstprinzipal zur Authentifizierung verwendet.

Testen von App-Updates mithilfe des Routings von Steckplätzen

Das Datenverkehrsrouting mit Slots ermöglicht es Ihnen, einen vordefinierten Teil Ihres Benutzerdatenverkehrs an jeden Slot zu leiten. Anfänglich wird der Datenverkehr zu 100 % an den Produktionsstandort geleitet. Sie können jedoch 10% Ihres Traffics zu Ihrem Staging-Slot senden. Dieser Ansatz zum Routing von Slot-Datenverkehr sendet automatisch 10% von Benutzern, die versuchen, auf den Staging-Slot zuzugreifen. Der Ansatz erfordert keine Änderungen an Ihrer Azure Front Door Instanz. Weitere Informationen zu Slot-Swaps und Stagingumgebungen in App Service finden Sie unter Set up staging environments in Azure App Service.

Verschieben von Code vom Staging-Slot zum Produktionsslot

Nachdem Sie Tests und Validierungen in Ihren Staging-Slots abgeschlossen haben, können Sie einen Slottausch von Ihrem Staging-Slot auf Ihre Produktionsumgebung durchführen. Sie schließen den Tausch für alle Instanzen Ihrer App in den jeweiligen Regionen ab. Während eines Slotaustauschs stellt die App Service-Plattform sicher, dass es beim Zielslot zu keinen Ausfallzeiten kommt.

1. Führen Sie den Tausch für Ihre primäre Web-App aus:

   az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production
   

2. Führen Sie den Austausch Ihrer Standby-Web-App aus:

   az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production
   

3. Wechseln Sie nach ein paar Minuten zu Ihrem Azure Front Door Endpoint im Azure Portal und überprüfen Sie, ob der Slottausch erfolgreich war.

An diesem Punkt laufen Ihre Apps, und alle Änderungen, die Sie an Ihrem Anwendungsquellcode vornehmen, lösen automatisch ein Update für beide Ihrer Staging-Slots aus. Sie können den Slotaustauschvorgang dann wiederholen, wenn Sie bereit sind, diesen Code in die Produktion zu verschieben.

Vermeiden von Unterbrechungen und Kontinuitätsproblemen mithilfe von Bereitstellungen mit mehreren Regionen

Sie können potenzielle Unterbrechungen oder Probleme mit Kontinuität über Regionen hinweg vermeiden, indem Sie vorübergehend eine Website entfernen, die den Steckplatztausch von Ihrer Azure Front Door Ursprungsgruppe durchläuft. Mit dieser Aktion können Kunden daran gehindert werden, verschiedene Versionen Ihrer App gleichzeitig anzuzeigen. Es ist auch hilfreich, wenn Sie erhebliche Änderungen an Ihren Apps vornehmen. Die temporäre Entfernung bewirkt, dass der gesamte Datenverkehr an den anderen Ursprung umgeleitet wird.

1. Wechseln Sie im Azure-Portal zu Ihrer Azure Front DoorInstanz.

2. Wählen Sieim linken Menü die> aus.

3. Wählen Sie in der Liste der Ursprungsgruppen die Ursprungsgruppe aus, die den Platz enthält, den Sie vorübergehend entfernen möchten.

4. Suchen Sie im Bereich 'Ursprungsgruppe aktualisieren' nach dem zu entfernenden Slot in der Liste 'Origin-Hostname'.

5. Weitere Aktionen auswählen (...) >Löschen sie, und wählen Sie dann "Aktualisieren" aus.

   

   Es kann mehrere Minuten dauern, bis die Änderung angewendet wird.

6. Wenn Sie bereit sind, den Datenverkehr zum gelöschten Slot zuzulassen, kehren Sie zum Bereich "Origin-Gruppe aktualisieren" zurück.

7. Wählen Sie oben + Ursprung hinzufügen aus, um den Ursprungsslot wieder zur Ursprungsgruppe hinzuzufügen.

   

Erstellen zusätzlicher Ursprungsgruppen und Ändern von Routenzuordnungen

Wenn Sie Ursprünge nicht löschen und erneut hinzufügen möchten, können Sie zusätzliche Ursprungsgruppen für Ihre "Azure Front Door"-Instanz erstellen. Anschließend können Sie die Route der Ursprungsgruppe zuordnen, die auf den beabsichtigten Ursprung verweist.

Sie können z. B. zwei zusätzliche Ursprungsgruppen erstellen, eine für Ihre primäre (aktive) Region und eine für Ihren Standbybereich (passiv). Ordnen Sie die Route Ihrer Backup-Region zu, wenn Ihre primäre Region eine Änderung durchläuft. Wenn Ihre Standbyregion eine Änderung erfährt, verknüpfen Sie die Route mit Ihrer primären Region. Wenn alle Änderungen abgeschlossen sind, können Sie die Route wieder Ihrer ursprünglichen Ursprungsgruppe zuordnen, die beide Regionen enthält. Diese Methode funktioniert, weil eine Route jeweils nur einer Ursprungsgruppe zugeordnet werden kann.

Erwägen Sie eine Konfiguration mit drei Ursprungsgruppen:

• Die Main-Origin Gruppe enthält sowohl die primären als auch die Standby-Web-Apps in ihren jeweiligen Regionen.
• Die Primary-Origin Gruppe enthält nur die primäre Web-App in der aktiven Region.
• Die Standby-Origin Gruppe enthält nur die Standby-Web-App in der passiven Region.

Angenommen, die primäre Web-App unterliegt einer Änderung. Bevor die Änderungen beginnen, wird die Routenzuordnung für die Main-Origin Gruppe in die Secondary-Origin Gruppe geändert. Diese Aktion stellt sicher, dass alle Datenverkehrsrouten an die Standby-Web-App in ihrer jeweiligen Region geleitet werden, während sich die primäre Web-App in ihrer jeweiligen Region ändert.

Führen Sie die folgenden Schritte aus, um die Routenzuordnung für eine Ursprungsgruppe zu ändern:

1. Wechseln Sie im Azure-Portal zu Ihrer Azure Front DoorInstanz.

2. Wählen Sieim linken Menü die> aus.

3. Suchen Sie in der Liste der Ursprungsgruppen nach einer Ursprungsgruppe, die den Indikator "Nicht zugeordnet " in der Spalte "Routen " anzeigt.

4. Weitere Aktionen auswählen (...) >Endpunkt und Route zuordnen.

   

5. Wählen Sie im Bereich " Routen zuordnen " eine oder mehrere Routen aus, die der Ursprungsgruppe zugeordnet werden sollen, und wählen Sie dann " Zuordnen" aus.

   

Einschränken des Zugriffs auf die Website für erweiterte Tools

Mit Azure-App Dienst wird die SCM/Advanced Tools-Website verwendet, um Ihre Apps zu verwalten und Anwendungsquellcode bereitzustellen. Erwägen Sie, die SCM/Erweiterte Tools-Website zu sperren, da diese Website höchstwahrscheinlich nicht über Front Door erreicht werden muss. Sie können beispielsweise Zugriffseinschränkungen einrichten, die es nur Ihnen erlauben, Ihre Tests durchzuführen und Continuous Deployment über das Tool Ihrer Wahl zu aktivieren. Wenn Sie Bereitstellungsslots verwenden, können Sie insbesondere für Produktionsslots fast den gesamten Zugriff auf die SCM-Website verweigern, da Ihre Tests und Validierungen mit Ihren Stagingslots durchgeführt werden.

Verwandte Inhalte

• Implementieren Sie eine hochverfügbare, mehrregionale Web-App
• Überprüfen der Basisarchitektur für eine hochgradig verfügbare zonenredundante Web-App