Zelfstudie: Een maximaal beschikbare app voor meerdere regio's maken in Azure App Service

Hoge beschikbaarheid en fouttolerantie zijn belangrijke onderdelen van een goed ontworpen oplossing. Een robuuste configuratie omvat een noodplan voor onverwachte storingen, om downtime te verminderen en systemen automatisch te laten werken.

Wanneer u een app in de cloud implementeert, kiest u een regio in die cloud voor de basis van de app-infrastructuur. Als u een app alleen in één regio implementeert en die regio niet meer beschikbaar is, is de app ook niet meer beschikbaar. Het ontbreken van beschikbaarheid kan onaanvaardbaar zijn volgens de voorwaarden van de Service Level Agreement (SLA) van de app. Implementeer de app en de bijbehorende services in meerdere regio's in de cloud om beschikbaarheid te garanderen.

In deze zelfstudie wordt beschreven hoe u een maximaal beschikbare web-app voor meerdere regio's implementeert. Met de procedure wordt een eenvoudig scenario geïmplementeerd dat bestaat uit een web-app en Azure Front Door. U kunt de concepten uitbreiden ter ondersteuning van andere infrastructuurpatronen. Als uw app bijvoorbeeld verbinding maakt met een Azure databaseaanbieding of opslagaccount, raadpleegt u Actieve geo-replicatie voor SQL-databases en Azure Storage redundantie. Voor een referentiearchitectuur voor een meer gedetailleerd scenario, zie het Reliable web-app-patroon voor .NET.

In deze handleiding leert u:

Vereisten

Als u geen Azure account hebt, maakt u een free-account voordat u begint.

Voltooi deze zelfstudie:

• Gebruik de Bash-omgeving in Azure Cloud Shell. Zie Get gestart met Azure Cloud Shell voor meer informatie.

  

• Als u CLI-referentieopdrachten liever lokaal uitvoert, installeer de Azure CLI. Als u op Windows of macOS werkt, kunt u overwegen Azure CLI uit te voeren in een Docker-container. Zie De Azure CLI uitvoeren in een Docker-container voor meer informatie.

  • Als u een lokale installatie gebruikt, meldt u zich aan bij de Azure CLI met behulp van de opdracht az. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Zie Authenticate to Azure using Azure CLI voor andere aanmeldingsopties.

  • Wanneer u hierom wordt gevraagd, installeert u de Azure CLI-extensie bij het eerste gebruik. Zie Uitbreidingen gebruiken en beheren met de Azure CLI voor meer informatie over extensies.

  • Voer az version uit om de geïnstalleerde versie en afhankelijke bibliotheken te vinden. Voer az upgrade uit om te upgraden naar de nieuwste versie.

De scenarioarchitectuur controleren

In het volgende architectuurdiagram ziet u de infrastructuur die u in deze zelfstudie maakt. Het bestaat uit twee identieke App Service-apps in afzonderlijke regio's. De eerste web-app bevindt zich in de actieve regio. Het is de primaire app die verantwoordelijk is voor het verwerken van binnenkomend verkeer. De tweede app bevindt zich in de stand-byregio en wacht op de beschikbaarheid van de primaire app. Azure Front Door probeert verkeer naar de primaire web-app te routeren. Wanneer de primaire regio niet beschikbaar is, routeert het verkeer naar het stand-byweb. In het diagram vertegenwoordigt de stippellijn verkeersroutering op basis van de regiostatus. Toegangsbeperkingen zijn zo geconfigureerd dat directe toegang tot de apps vanaf internet wordt geblokkeerd.

Azure biedt verschillende opties voor taakverdeling en verkeersroutering. Azure Front Door is geselecteerd voor deze zelfstudie omdat het gaat om internetgerichte web-apps die worden gehost op Azure App Service geïmplementeerd in meerdere regio's. Als uw configuratie verschilt van het voorbeeld in deze zelfstudie, zie Een load balancing oplossing voor uw scenario kiezen.

Het scenario in deze zelfstudie biedt het volgende gedrag:

• Identieke App Service-apps worden geïmplementeerd in twee afzonderlijke regio's.
• Openbaar verkeer dat rechtstreeks naar de web-apps wordt verzonden, wordt geblokkeerd.
• Azure Front Door routeert verkeer naar de actieve app in de primaire regio.
• De stand-by-app in de secundaire regio is beschikbaar voor verkeer, indien nodig.

Een brongroep maken

Voor deze zelfstudie hebt u twee exemplaren van een web-app nodig die in verschillende Azure regio's worden uitgevoerd.

1. Bekijk de beschikbare regioparen en selecteer twee gekoppelde regio's voor uw web-apps.

   In deze zelfstudie worden de twee regio's aangeduid als de <primary-region> (eastus) en <standby-region> (westus).

2. Maak een resourcegroep voor alle resources die u in deze zelfstudie configureert. In deze handleiding maakt u de resourcegroep op de <primary-region> locatie.

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --name	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --location	<primary-region>	De regiolocatie voor de resourcegroep. In deze handleiding wordt dezelfde regiolocatie gebruikt voor de resourcegroep en de primaire webapp.	eastus

   Gebruik in een daadwerkelijke implementatie afzonderlijke resourcegroepen voor elke regio/resource. De scheiding maakt isolatie van resources in een noodherstelsituatie mogelijk.

   Zie de opdrachtreferentie az group create voor meer informatie.

Twee App Service-abonnementen maken

Maak twee App Service-abonnementen, één voor elke web-app. Maak elk plan op de regiolocatie waar u verwacht de bijbehorende app te maken.

Voor deze opdracht gebruikt u het regiopaar dat u eerder hebt geselecteerd. Gebruik de actieve regio voor de primaire web-app en de passieve regio voor de stand-by-web-app.

Voer de volgende opdracht uit om het App Service-plan voor de primaire web-app te maken en voer de opdracht opnieuw uit om het plan voor de stand-by-app te maken.

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

Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

Zie de opdrachtreferentie az appservice plan create voor meer informatie.

Twee toepassingen maken

Maak twee App Service-web-apps. Plaats elke app in een bijbehorend App Service-plan en regiolocatie.

1. --runtime De taalversie voor de web-apps identificeren.

   U kunt de volgende opdracht uitvoeren voor de lijst met beschikbare runtimes:

   az webapp list-runtimes
   

   Als u van plan bent de voorbeeld-Node.js-app te gebruiken die in deze zelfstudie wordt beschreven, stelt u de <language-version> waarde in op NODE:24-lts.

2. Maak twee web-apps. Voer de volgende opdracht uit om de primaire web-app te maken en voer de opdracht opnieuw uit om de stand-by-app te maken.

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --name	<web-app-name>	de naam van de web-app. Elke app moet een wereldwijd unieke naam hebben. De geldige tekens zijn a-z, 0-9en -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --name	<app-service-plan>	De naam van het App Service-plan voor de web-app.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	De runtime taalversie voor de web-app.	NODE:24-lts

   Zie de opdrachtreferentie az webapp create voor meer informatie.

3. Identificeer de defaultHostName waarde voor elke web-app. De indeling van de hostnaam is <web-app-name>.azurewebsites.net.

   Scan de uitvoer van de opdracht voor elke web-app en zoek de waarde of voer de volgende opdracht uit voor elke web-app:

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --name	<web-app-name>	de naam van de web-app.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group

   In de Azure portal is de hostnaam voor elke app zichtbaar op de pagina Overview.

   Noteer de hostnaamwaarden voor later gebruik. U gebruikt de hostnamen om de back-endadressen voor Azure Front Door implementatie te definiëren.

4. Controleer of u toegang hebt tot de nieuwe web-apps.

   1. Voer in een browser de hostnaam in voor de primaire web-app, zoals zava-primary-app.azurewebsites.net.

      Wanneer de verbinding is geslaagd, ziet u het volgende bericht:

      

   2. Herhaal de test met de hostnaam voor uw stand-by-web-app.

Azure Front Door configureren

Een implementatie met meerdere regio's kan een actief-actief- of actief-passiefconfiguratie gebruiken. De primaire regio is actief en de stand-byregio is passief.

• Een actief-actief-configuratie distribueert aanvragen over meerdere actieve regio's.
• Met een actief-passieve configuratie worden exemplaren in de stand-byregio (passief) uitgevoerd, maar wordt er geen verkeer verzonden, tenzij de primaire (actieve) regio uitvalt.

Azure Front Door stelt u in staat om beide configuraties in te schakelen. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie over het ontwerpen van apps voor hoge beschikbaarheid en fouttolerantie.

Een profiel maken

Maak een exemplaar van Azure Front Door Premium voor het routeren van verkeer naar uw web-apps.

1. Bekijk de vergelijking van de Azure Front Door-laag en selecteer de laag voor uw implementatie.

   In deze handleiding wordt Azure Front Door Premium (Premium_AzureFrontDoor) gebruikt.

   Als u liever Azure Front Door Standard implementeert, moet u er rekening mee houden dat de Standard-laag geen ondersteuning biedt voor de implementatie van beheerde regels met WAF-beleid.

2. Voer de volgende opdracht uit om het profiel te maken:

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --profile-name	<front-door-profile>	De naam voor het Azure Front Door-profiel. De naam moet uniek zijn binnen de resourcegroep.	zava-profile
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --sku	<front-door-tier>	De tier-SKU van Azure Front Door voor de implementatie.	Premium_AzureFrontDoor (aanbevolen) Standard_AzureFrontDoor

   Zie de opdrachtreferentie az afd profile create voor meer informatie.

Een eindpunt toevoegen

Maak een eindpunt in uw profiel. Nadat u het eerste eindpunt hebt gemaakt, kunt u meerdere eindpunten in uw profiel maken.

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

Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

Zie de opdrachtreferentie az afd endpoint create voor meer informatie.

Een oorspronkelijke groep maken

Wanneer u implementeert in Azure Front Door, hebt u een bron nodig om als eindpunt te dienen voor de backend van uw webapp. Zie Origins en origin-groepen in Azure Front Door voor meer informatie. De oorsprongen worden opgeslagen in een oorspronkelijke groep.

Maak een origin-groep in uw Azure Front Door-profiel om oorsprongen voor uw twee web-apps te bevatten.

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>

Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

Zie de opdrachtverwijzing az afd origin-group create voor meer informatie.

Origins toevoegen aan de oorspronkelijke groep

Voeg een oorsprong toe voor elk van uw web-apps aan uw Azure Front Door origin-groep.

1. Voeg een oorsprong toe voor de primaire web-app. Stel de parameter --priority in op 1, waarmee Azure Front Door wordt geïnformeerd dat deze app de primaire ontvanger voor verkeer is.

   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>
   

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	De hostnaam voor uw primaire web-app. De hostnaam combineert de naam van de web-app, zoals zava-primary-app met de host-id. azurewebsites.net	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	De naam van uw Azure Front Door profiel.	zava-profile
   --origin-group-name	<front-door-origin-group>	De naam van de Azure Front Door origin-groep.	zava-origin-group
   --origin-name	<web-app-origin-name>	De naam van de oorsprong voor de primaire webapp. De naam moet uniek zijn binnen de oorspronkelijke groep.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	De host-header voor het verzenden van aanvragen naar de oorsprong van de primaire webapp. Als u geen waarde opgeeft, bepaalt de hostnaam van de aanvraag deze waarde. Azure CDN oorsprongen, zoals Web Apps, Blob Storage en Cloud Services, moeten deze hostheaderwaarde standaard overeenkomen met de hostnaam van de oorsprong.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	De prioriteit voor deze oorsprong binnen de oorspronkelijke groep. Stel voor de primaire web-app de prioriteit in op 1. Azure Front Door gebruikt de prioriteitswaarden voor taakverdeling tussen oorsprongen en actieve regio's. De waarde moet tussen 1 en 5 zijn.	1
   --weight	<origin-weight>	Het gewicht van de oorsprong binnen de oorspronkelijke groep voor taakverdeling. De waarde moet tussen 1 en 1000 zijn.	1000
   --enabled-state	<origin-state>	Geef aan of deze bron verkeer mag ontvangen.	Enabled
   --http-port	<origin-port>	De poort die wordt gebruikt voor HTTP-aanvragen naar de oorsprong.	80
   --https-port	<origin-secure-port>	De poort die wordt gebruikt voor beveiligde HTTPS-aanvragen naar de oorsprong.	443

   Zie de naslaginformatie over de opdracht az afd origin create voor meer informatie.

2. Voer de opdracht opnieuw uit en voeg een oorsprong toe voor de stand-by-web-app . De opdracht gebruikt dezelfde parameters, maar met de volgende unieke parameterwaarden:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --host-name	<web-app-name>.azurewebsites.net	De hostnaam voor uw stand-by-web-app .	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	De naam van de oorsprong voor de standby-webapp.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	De hostheader die moet worden verzonden voor aanvragen naar de oorsprong van de stand-by-web-app .	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	De prioriteit voor deze oorsprong binnen de oorspronkelijke groep. Stel voor de stand-by-web-app de prioriteit in op 2. Azure Front Door probeert al het verkeer om te leiden naar de primaire oorsprong. Wanneer de primaire oorsprong niet beschikbaar is, routeert het verkeer naar de stand-by-origin.	2

Een routeregel toevoegen

Voeg een routeringsregel toe om het Azure Front Door-eindpunt toe te wijzen aan de oorspronkelijke groep. De route stuurt aanvragen van het eindpunt door naar uw oorspronkelijke groep.

1. Maak een routeregel om het Azure Front Door-eindpunt toe te wijzen aan de oorspronkelijke groep:

   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> 
   

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --profile-name	<front-door-profile>	De naam van uw Azure Front Door profiel.	zava-profile
   --endpoint-name	<front-door-endpoint>	De naam van het eindpunt onder uw Azure Front Door profiel.	zava-endpoint
   --forwarding-protocol	<protocol-type>	Het protocol dat door deze routeregel wordt gebruikt bij het doorsturen van verkeer naar de back-end-apps.	MatchRequest
   --route-name	<route-rule-name>	De naam van de routeregel. Moet uniek zijn binnen het Azure Front Door profiel.	zava-route-rule
   --https-redirect	<secure-redirect>	Hiermee wordt aangegeven of HTTP-verkeer automatisch moet worden omgeleid naar HTTPS-verkeer.	Enabled
   --origin-group-name	<front-door-origin-group>	De naam van de Azure Front Door origin-groep.	zava-origin-group
   --supported-protocols	<protocol-list>	De lijst met ondersteunde protocollen voor deze routeregel. Gebruik een spatie om de protocoltypen te scheiden.	Http Https
   --link-to-default-domain	<domain-link>	Geef aan of deze route is gekoppeld aan het standaardeindpuntdomein.	Enabled

   Zie de opdrachtreferentie az afd route create voor meer informatie.

2. Wacht ongeveer 15 minuten voordat de implementatie is voltooid. Het kan enige tijd duren voordat de wijzigingen wereldwijd zijn doorgevoerd.

Toegang beperken uitsluitend via Azure Front Door

U hebt momenteel rechtstreeks toegang tot uw web-apps door hun hostnamen in te voeren in een browser. Als u toegangsbeperkingen voor uw apps instelt, kunt u ervoor zorgen dat verkeer uw apps alleen bereikt via Azure Front Door.

Azure Front Door functies werken het beste wanneer verkeer alleen via de service stroomt. Het is een best practice om de oorsprong van uw web-app te configureren om verkeer te blokkeren dat niet via Azure Front Door wordt verzonden. Anders kan verkeer de Azure Front Door web application firewall, DDoS-beveiliging en andere beveiligingsfuncties omzeilen.

Verkeer van Azure Front Door naar uw apps is afkomstig van een bekende set IP-bereiken die zijn gedefinieerd in de servicetag AzureFrontDoor.Backend. Met behulp van een regel voor servicetagbeperking kunt u verkeer beperken tot alleen verkeer dat afkomstig is van Azure Front Door.

1. Verkrijg de identificator voor uw Azure Front Door-profiel.

   U hebt de profiel-id nodig om ervoor te zorgen dat verkeer alleen afkomstig is van uw specifieke Azure Front Door exemplaar. Met de toegangsbeperking worden de binnenkomende aanvragen verder gefilterd op basis van de unieke HTTP-header die is verzonden vanuit uw Azure Front Door-profiel.

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --profile-name	<front-door-profile>	De naam van uw Azure Front Door profiel.	zava-profile

   In de uitvoer van de opdracht wordt de profiel-id (alfanumerieke waarde van 32 cijfers) weergegeven:

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

   In de volgende stap gebruikt u de profiel-id voor de <profile-identifier> waarde.

2. Voer de volgende opdracht uit om toegangsbeperkingen in te stellen voor uw primaire web-app en voer de opdracht opnieuw uit om beperkingen in te stellen voor de stand-by-app.

   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>
   

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --name	<web-app-name>	De naam van de web-app waarvoor u toegangsbeperkingen instelt.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Geef de prioriteit van de toegangsbeperkingsregel op voor alle regels die zijn gedefinieerd voor het profiel. Een lagere waarde is gelijk aan een hogere prioriteit.	100
   --service-tag	<tag-name>	Een servicetagnaam die wordt herkend door Azure Front Door. De toegangsbeperkingen zijn van toepassing op het IP-bereik dat wordt aangegeven door de servicetag.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Geef een of meer unieke HTTP-headers op voor extra filtering van binnenkomend verkeer. De toegangsbeperkingen filteren de binnenkomende aanvragen op basis van de unieke HTTP-header die is verzonden vanuit uw Azure Front Door-profiel. De header combineert het Azure Front Door voorvoegsel en de profiel-id voor uw Azure Front Door instantie.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Voor meer informatie, raadpleeg de commandoverwijzing az webapp config access-restriction add.

Toegangsbeperkingen testen

Bevestig dat uw toegangsbeperkingen directe toegang tot uw apps voorkomen.

1. Voer in een browser de hostnaam in voor de primaire web-app, zoals zava-primary-app.azurewebsites.net.

   De verbinding mislukt met het volgende bericht:

   

2. Herhaal de test met de hostnaam voor uw stand-by-web-app, zoals zava-standby-app.azurewebsites.net.

Implementatie van Azure Front Door testen

Wanneer u het Azure Front Door Standard- of Premium-profiel maakt, kan het enige tijd duren voordat de configuratie wereldwijd wordt geïmplementeerd. Nadat de implementatie is voltooid, hebt u toegang tot de front-endhost.

1. Haal de hostnaam van uw Azure Front Door-eindpunt op:

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

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

   Kenmerk	Waarde	Beschrijving	Voorbeeld
   --resource-group	<resource-group>	De resourcegroep die de resources bevat die in deze zelfstudie zijn gemaakt.	zava-resource-group
   --profile-name	<front-door-profile>	De naam van uw Azure Front Door profiel.	zava-profile
   --endpoint-name	<front-door-endpoint>	De naam van het eindpunt onder uw Azure Front Door profiel.	zava-endpoint

   In de uitvoer van de opdracht wordt de hostnaam van het eindpunt weergegeven:

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

   De hostnaam bestaat uit de eindpuntnaam, een unieke alfanumerieke hash, een id en het achtervoegsel Azure Front Door. In de volgende stap gebruikt u de hostnaam van het eindpunt.

   Zie de opdrachtreferentie az afd endpoint show voor meer informatie.

2. Voer in een browser de hostnaam van het eindpunt in, zoals zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   Uw aanvraag wordt automatisch doorgestuurd naar uw primaire app in de actieve regio.

   Wanneer de verbinding is geslaagd, ziet u het volgende bericht:

   

3. Test onmiddellijke globale failover tussen de apps in de gekoppelde regio's.

   1. Voer in een browser de hostnaam van het eindpunt in, zoals zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Stop de primaire app door de opdracht az webapp stop uit te voeren.

      Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

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

   3. Vernieuw de browser.

      Als verkeer correct wordt omgeleid naar de stand-by-app in de andere regio, ziet u dezelfde pagina en hetzelfde bericht.

      Aanbeveling

      Mogelijk moet u de pagina een paar keer vernieuwen om de failover te voltooien.

      U kunt controleren of Azure Front Door wordt omgeleid naar de stand-by-app door de status van de web-apps in de Azure-portal te controleren. Op de pagina Overzicht voor de primaire web-app moet de optie Start beschikbaar zijn (niet grijs). Op de overzichtspagina voor de stand-by-web-app mag de optie Start niet beschikbaar zijn (grijs).

   4. Voer de az webapp stop opdracht opnieuw uit en stop de stand-by-app .

      Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

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

   5. Vernieuw uw browser opnieuw.

      Als de stand-by-app ook stopt, moet alle verkeersroutering stoppen. Deze keer ziet u een foutbericht:

      

   6. Voer de az webapp start opdracht uit en start de stand-by-app opnieuw op.

      Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources:

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

   7. Vernieuw uw browser en u ziet een geslaagde app-verbinding.

Validatie bevestigt dat u nu toegang hebt tot uw apps via Azure Front Door- en failoverfuncties zoals bedoeld.

Bent u klaar met de failover-test, start dan de primaire app opnieuw.

Hulpmiddelen opschonen

In de voorgaande stappen hebt u Azure resources in een resourcegroep gemaakt. Als u deze resources in de toekomst niet meer nodig hebt, verwijdert u de resourcegroep door de volgende opdracht uit te voeren in de Cloud Shell.

Vervang de <placeholder> parameterwaarde door de informatie voor uw eigen resource:

az group delete --name <resource-group>

Het uitvoeren van deze opdracht kan enkele minuten duren.

Implementeren vanuit ARM of Bicep

De resources die u in deze zelfstudie hebt gemaakt, kunnen worden geïmplementeerd met behulp van een Azure Resource Manager sjabloon (ARM-sjabloon) of Bicep sjabloon. U kunt beginnen met het hoogbeschikbare multi-regio webapplicatie Bicep-bestand op GitHub. Met deze sjabloon kunt u een veilige, maximaal beschikbare end-to-end oplossing voor meerdere regio's maken met twee web-apps in verschillende regio's achter Azure Front Door.

Zie Deploy Bicep files with the Azure CLI voor meer informatie over het implementeren van ARM- en Bicep-sjablonen.

Veelgestelde vragen

In deze zelfstudie hebt u een basislijninfrastructuur geïmplementeerd om een web-app met meerdere regio's in te schakelen. App Service biedt functies waarmee u ervoor kunt zorgen dat u toepassingen uitvoert die de aanbevolen beveiligingsprocedures en aanbevelingen volgen.

Deze sectie bevat antwoorden op veelgestelde vragen waarmee u uw apps verder kunt beveiligen en uw resources kunt implementeren en beheren volgens aanbevolen procedures.

Infrastructuur en Azure resources beheren en implementeren

Voor deze zelfstudie hebt u de Azure CLI gebruikt om uw infrastructuurbronnen te implementeren. Overweeg om een mechanisme voor continue implementatie te configureren voor het beheren van uw toepassingsinfrastructuur. Omdat u resources in verschillende regio's implementeert, moet u deze resources onafhankelijk beheren in de regio's. Om ervoor te zorgen dat de resources identiek zijn in elke regio, infrastructuur als code (IaC), zoals een sjabloon ARM of Terraform moet worden gebruikt met implementatiepijplijnen zoals Azure-pipelines of GitHub Actions. Wanneer u deze configuratie op de juiste manier instelt, worden updates voor alle implementatieregio's geactiveerd door wijzigingen in resources. Zie Continue implementatie configureren voor Azure App Service voor meer informatie.

Staging-slots gebruiken voor een veilige uitrol naar productie

Het rechtstreeks implementeren van toepassingscode naar productie-apps en -sites wordt niet aanbevolen. Het is belangrijk dat u een veilige plek hebt om uw apps te testen en wijzigingen te valideren voordat u naar productie pusht. Gebruik een combinatie van staging-slots en slotwisseling om code van de testomgeving naar de productieomgeving te verplaatsen.

In deze zelfstudie hebt u de basisinfrastructuur gemaakt die ondersteuning biedt voor het gebruik van staging-slots. U kunt implementatiesites maken voor elk exemplaar van uw web-app en continue implementatie configureren voor deze faseringssites met GitHub Actions. Net als bij infrastructuurbeheer wordt het configureren van continue implementatie voor uw toepassingsbroncode ook aanbevolen om ervoor te zorgen dat wijzigingen in verschillende regio's gesynchroniseerd blijven. Als u continue implementatie niet configureert, moet u elke app in elke regio handmatig bijwerken telkens wanneer er een codewijziging is.

Voor het gebruik van staging-slots, volg deze procedure:

1. Voor deze procedure hebt u een app nodig die klaar is voor implementatie in uw App Service-app.

   Als u de zelfstudie hebt voltooid, kunt u uw primaire webapp en standby-webapp gebruiken. Je hebt echter een App Service plan nodig dat voldoende implementatie-slots ondersteunt. Zie Azure abonnements- en servicelimieten, quota en beperkingen voor meer informatie.

   Als u geen app hebt, kunt u beginnen met de voorbeeld-app Node.js Hallo wereld. Fork de GitHub opslagplaats zodat u uw eigen kopie hebt om wijzigingen aan te brengen.

2. Configureer de App Service-stackinstellingen voor uw web-apps.

   Stack-instellingen verwijzen naar de taalversie of runtime die voor uw app wordt gebruikt.

   U kunt de instellingen in de Azure-portal configureren of de opdracht az webapp config set gebruiken. Als u het Node.js voorbeeld gebruikt, stelt u de stack-instellingen in op Node 24 LTS.

   1. Ga in de Azure portal naar uw primaire web-app.

   2. Selecteer Instellingenconfiguratie> in het linkermenu.

   3. Configureer op het tabblad Stack-instellingen de volgende instellingen:

      1. Selecteer de Stack-waarde, zoals Node.

      2. Selecteer de versiewaarde , zoals Node 24 LTS.

      3. Klik op Toepassen.

   4. Herhaal het proces om de App Service-stackinstellingen voor uw stand-by-web-app te configureren.

3. Continue implementatie instellen in de Azure-portal. Zie Continue implementatie configureren voor Azure App Service voor gedetailleerde richtlijnen over het configureren van continue implementatie met providers zoals GitHub Actions.

4. Voer de volgende opdracht uit om een staging-slot te maken met de naam stage voor uw primaire webapp.

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

5. Voer de az webapp deployment slot create opdracht opnieuw uit en maak een staging-slot met de naam stage voor de standby-webapp.

6. Configureer continue implementatie met GitHub Actions voor elke staging-site:

   1. Ga in de Azure portal naar uw primaire web-app.

   2. Selecteer Implementatie>Implementatieslots in het linkermenu.

   3. Zoek de stage-sleuf in de lijst en selecteer de sleuf om het detailvenster te openen.

   4. Selecteer implementatiecentrum> in het linkermenu.

   5. Stel op het tabblad Settings de optie Source in op GitHub:

      

   6. Als u voor het eerst vanuit GitHub implementeert, selecteert u Authorize en volgt u de autorisatieprompts. Als u wilt implementeren vanuit de opslagplaats van een andere gebruiker, selecteert u Account wijzigen.

   7. Nadat u uw Azure-account met GitHub hebt geautoriseerd, selecteert u de Organization, Repository en Branch om CI/CD te configureren. Als u een organisatie of opslagplaats niet kunt vinden, moet u mogelijk meer machtigingen inschakelen voor GitHub. Zie Gebruikerstoegang tot de opslagplaatsen van uw organisatie beheren voor meer informatie.

      Als u de Node.js voorbeeld-app gebruikt, gebruikt u de volgende instellingen.

      Instelling	Waarde
      Organisatie	<your-GitHub-organization>
      Opslagplaats	nodejs-docs-hello-world
      Filiaal	voornaamste

   8. Selecteer Opslaan.

Nieuwe commits in de geselecteerde repository en branch worden nu continu geïmplementeerd in uw App Service-app-slot. U kunt de doorvoeringen en implementaties bijhouden op het tabblad Logboeken .

Een standaardwerkstroombestand dat gebruikmaakt van een publicatieprofiel voor verificatie bij App Service, wordt toegevoegd aan uw GitHub-opslagplaats. U kunt dit bestand bekijken door naar de <repo-name>/.github/workflows/ map te gaan.

Basisverificatie uitschakelen in App Service

U kunt de toegang tot de FTP- en SCM-eindpunten beperken tot gebruikers die worden ondersteund door Microsoft Entra ID door basisverificatie uit te schakelen.

Als u een hulpprogramma voor continue implementatie gebruikt om de broncode van uw toepassing te implementeren, zijn voor het uitschakelen van basisverificatie extra stappen nodig om continue implementatie te configureren. U kunt bijvoorbeeld geen publicatieprofiel gebruiken omdat er geen Microsoft Entra referenties worden gebruikt. In plaats daarvan moet u een service-principal of OpenID Connect-referentie gebruiken.

Met de volgende opdrachten schakelt u basisverificatie uit voor de primaire App Service-web-app en staging-site, en de stand-by-web-app en staging-site. Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources.

1. FTP-toegang uitschakelen voor de productiesites en staging-sleuven van uw primaire webapplicatie.

   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. Voer de opdrachten opnieuw uit voor uw stand-by-web-app .

3. Schakel basisverificatietoegang tot de WebDeploy-poort en SCM-site uit voor de productiesites en faseringssites voor uw primaire 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. Voer de opdrachten opnieuw uit voor uw stand-by-web-app .

Zie Basisverificatie uitschakelen in App Service-implementaties voor meer informatie over het uitschakelen van basisverificatie, waaronder het testen en bewaken van aanmeldingen.

Continue implementatie gebruiken wanneer basisverificatie is uitgeschakeld

Als u basisverificatie voor uw App Service-apps wilt toestaan, kunt u een van de beschikbare implementatiemethoden in App Service gebruiken. U kunt bijvoorbeeld het publicatieprofiel gebruiken dat u hebt geconfigureerd in de sectie staging-slots.

Als u basisverificatie voor uw App Service-apps uitschakelt, is voor continue implementatie een service-principal of OpenID Connect vereist voor verificatie. Als u GitHub Actions als codeopslagplaats gebruikt, raadpleegt u de Deploy voor Azure App Service met behulp van GitHub Actions. De zelfstudie bevat stapsgewijze instructies voor het maken van een service-principal of OpenID Connect om te implementeren in App Service met behulp van GitHub Actions. U kunt het proces ook voltooien door de procedure in de volgende sectie te volgen.

Service principal en referentiegegevens maken met GitHub Actions

Continue implementatie configureren met GitHub Actions en een service-principal:

1. Maak de service-principal voor uw primaire webapp en standby webapp:

   Vervang de volgende <placeholder> parameterwaarden door de informatie voor uw eigen resources.

   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>
   

   De uitvoer is een JSON-object met de roltoewijzingsreferenties die toegang bieden tot uw App Service-apps.

   {
     "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/"
   }
   

   De JSON bevat uw clientgeheim, dat op dit moment alleen zichtbaar is.

   Aanbeveling

   Het is een goede gewoonte om minimale toegang te verlenen. In dit voorbeeld is het bereik beperkt tot alleen de apps, niet de hele resourcegroep.

2. Kopieer het JSON-object zodat u een record van uw clientgeheim hebt.

3. Geef uw service-principalreferenties op voor de Azure-aanmeldingsbewerking als onderdeel van uw GitHub Action-werkstroom.

   U kunt de waarden rechtstreeks in de werkstroom opgeven of opslaan als GitHub geheimen waarnaar wordt verwezen in uw werkstroom. Het opslaan van de waarden als GitHub geheimen is de veiligere optie.

   1. Open de GitHub opslagplaats voor uw app.

   2. Ga naar Instellingen>Beveiliging>Geheimen en variabelen>Acties.

   3. Selecteer Nieuw opslagplaatsgeheim en maak een geheim voor elk van de volgende instellingen. Gebruik de waarden uit uw JSON-uitvoer.

      Instelling	Waarde	Voorbeeld
      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

GitHub Actions-werkstroom maken

Nadat u een service-principal hebt die toegang heeft tot uw App Service-apps, bewerkt u de standaardwerkstromen voor uw apps. Deze werkstromen worden automatisch gegenereerd wanneer u continue implementatie configureert.

Verificatie moet worden uitgevoerd met behulp van uw service-principal in plaats van het publicatieprofiel. Zie het tabblad Service-principal in Toevoegen van het werkstroombestand aan uw GitHub-opslagplaats voor voorbeeldwerkstromen. De volgende voorbeeldwerkstroom kan worden gebruikt voor de Node.js voorbeeld-app.

1. Open de GitHub opslagplaats voor uw app.

2. Ga naar de <repo-name>/.github/workflows/-directory. U ziet nu de automatisch gegenereerde werkstromen.

3. Selecteer Bewerken (potlood) voor elk werkstroombestand.

4. Vervang de inhoud van het werkstroombestand door de volgende inhoud. In de code wordt ervan uitgegaan dat u de GitHub geheimen al hebt gemaakt voor uw referentie.

   Configureer in de env sectie de volgende instellingen:

   • AZURE_WEBAPP_NAME: Vervang de <web-app-name> tijdelijke aanduiding door de naam van uw web-app.
   • NODE_VERSION: Geef de te gebruiken knooppuntversie op. Voor het Node.js voorbeeld is '24.x'de waarde .
   • AZURE_WEBAPP_PACKAGE_PATH: Geef het pad naar uw web-app-project op. De standaardwaarde is de hoofdmap van de repository. '.'
   • AZURE_WEBAPP_SLOT_NAME: Geef de naam van het toepassingsslot op. De algemene naam is 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. Sla de wijzigingen in het werkstroombestand rechtstreeks op in de hoofdbranch van uw opslagplaats.

   De doorvoering activeert de GitHub-actie om opnieuw uit te voeren en uw code te implementeren. Deze keer wordt de service-principal gebruikt om te authenticeren.

App-updates testen door gebruik te maken van slot-verkeersroutering

Met verkeersroutering met sleuven kunt u een vooraf gedefinieerd gedeelte van uw gebruikersverkeer naar elke sleuf leiden. In eerste instantie wordt 100% van het verkeer omgeleid naar de productiesite. U kunt echter 10% van uw verkeer verzenden naar uw staging-site. Deze methode voor het routeren van slotverkeer verzendt automatisch 10% van de gebruikers die toegang proberen te krijgen tot de staging-slot. Voor de aanpak zijn geen wijzigingen in uw Azure Front Door exemplaar vereist. Zie Set up staging environments in Azure App Service voor meer informatie over slotwisselingen en faseringsomgevingen in App Service.

Code van staging-site naar productiesite verplaatsen

Nadat u klaar bent met testen en valideren in uw staging-sites, kunt u een sitewisseling uitvoeren van uw staging-site naar uw productiesite. U voltooit de wissel voor alle exemplaren van uw app in elke regio. Tijdens een sitewisseling zorgt het App Service-platform ervoor dat de doelsite geen downtime ondervindt.

1. Voer de wissel uit voor uw primaire web-app:

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

2. Voer de wissel uit voor uw stand-by-web-app :

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

3. Ga na een paar minuten naar uw Azure Front Door-eindpunt in de Azure-portal en controleer of de slotwisseling is geslaagd.

Op dit moment worden uw apps uitgevoerd en leidt elke wijziging die u in de broncode van uw toepassing aanbrengt automatisch tot een update van beide staging-sleuven. U kunt vervolgens het slotwisselproces herhalen wanneer u klaar bent om die code naar productie te brengen.

Onderbrekingen en continuïteitsproblemen voorkomen met behulp van implementaties in meerdere regio's

U kunt potentiële onderbrekingen of problemen met continuïteit tussen regio's voorkomen door tijdelijk een site te verwijderen die de sitewisseling van uw Azure Front Door origin-groep ondergaat. Met deze actie voorkomt u dat klanten tegelijkertijd verschillende versies van uw app zien. Het is ook handig wanneer u belangrijke wijzigingen aanbrengt in uw apps. De tijdelijke verwijdering zorgt ervoor dat al het verkeer wordt omgeleid naar de andere bronserver.

1. Ga in de Azure-portal naar uw Azure Front Door-exemplaar.

2. Selecteer Instellingen>origin-groepen in het linkermenu.

3. Selecteer in de lijst met oorsprongsgroepen de oorsprongsgroep die het slot bevat dat u tijdelijk wilt uitschakelen.

4. Zoek in het deelvenster Origin-groep Bijwerken de slot die u wilt verwijderen in de lijst Oorsprong-hostnamen.

5. Meer acties selecteren (...) >Verwijder en selecteer Vervolgens Bijwerken.

   

   Het kan enkele minuten duren voordat de wijziging is toegepast.

6. Wanneer u klaar bent om verkeer naar de verwijderde site toe te staan, gaat u terug naar het deelvenster Origin-groep Bijwerken .

7. Selecteer bovenaan + Een origin toevoegen om de origin slot opnieuw toe te voegen aan de origin groep.

   

Extra origin-groepen maken en routekoppelingen wijzigen

Als u liever geen origins verwijdert en opnieuw toevoegt, kunt u extra origin-groepen maken voor uw Azure Front Door-instantie. Vervolgens kunt u de route koppelen aan de oorspronkelijke groep die verwijst naar de beoogde oorsprong.

U kunt bijvoorbeeld twee extra origin-groepen maken, één voor uw primaire (actieve) regio en één voor uw stand-byregio (passief). Als uw primaire regio een wijziging ondergaat, koppelt u de route aan uw stand-byregio. Als uw stand-byregio een wijziging ondergaat, koppelt u de route aan uw primaire regio. Wanneer alle wijzigingen zijn voltooid, kunt u de route associëren met de oorspronkelijke origingroep die beide regio's bevat. Deze methode werkt omdat een route slechts kan worden gekoppeld aan één oorspronkelijke groep tegelijk.

Overweeg een configuratie met drie oorsprongsgroepen:

• De Main-Origin groep bevat zowel de primaire als de stand-by-web-apps, elk in hun respectieve regio's.
• De Primary-Origin groep bevat alleen de primaire web-app in de actieve regio.
• De Standby-Origin groep bevat alleen de stand-by-web-app in de passieve regio.

Stel dat de primaire web-app een wijziging ondergaat. Voordat de wijzigingen worden gestart, wordt de routekoppeling voor de Main-Origin groep gewijzigd in de Secondary-Origin groep. Deze actie leidt al het verkeer naar de standby-webapp in de betreffende regio, terwijl de primaire webapp in dezelfde regio een wijziging ondergaat.

Volg deze stappen om de routekoppeling voor een oorspronkelijke groep te wijzigen:

1. Ga in de Azure-portal naar uw Azure Front Door-exemplaar.

2. Selecteer Instellingen>origin-groepen in het linkermenu.

3. Zoek in de lijst met oorsprongsgroepen een oorsprongsgroep met de indicator Niet-gekoppeld in de kolom Routes .

4. Meer acties selecteren (...) >Eindpunt en route koppelen.

   

5. Selecteer in het deelvenster Routes koppelen een of meer routes die u aan de originegroep wilt koppelen en selecteer dan Koppelen.

   

Toegang tot de site met geavanceerde hulpprogramma's beperken

Met Azure-app service wordt de site SCM/geavanceerde hulpprogramma's gebruikt voor het beheren van uw apps en het implementeren van de broncode van de toepassing. Overweeg de site met SCM/geavanceerde hulpprogramma's te vergrendelen, omdat deze site waarschijnlijk niet via Front Door hoeft te worden bereikt. U kunt bijvoorbeeld toegangsbeperkingen instellen waarmee u alleen uw tests kunt uitvoeren en continue implementatie vanuit uw keuzeprogramma kunt inschakelen. Als u implementatieslots gebruikt, kunt u voor productieslots in het bijzonder de toegang tot de SCM-site beperken, omdat uw tests en validatie wordt uitgevoerd met uw staging-slots.

Verwante inhoud

• Een maximaal beschikbare web-app voor meerdere regio's implementeren
• Bekijk de basislijnarchitectuur voor een maximaal beschikbare zone-redundante web-app