Självstudie: Skapa en app med hög tillgänglighet för flera regioner i Azure App Service

Hög tillgänglighet och feltolerans är viktiga komponenter i en välkonstruerad lösning. En robust konfiguration innehåller en nödplan för oväntade fel, för att minska stilleståndstiden och hålla systemen igång automatiskt.

När du distribuerar en app till molnet väljer du en region i molnet för appinfrastrukturbasen. Om du distribuerar en app endast till en enda region och den regionen blir otillgänglig är appen inte heller tillgänglig. Bristen på tillgänglighet kan vara oacceptabel enligt villkoren i appens serviceavtal (SLA). Distribuera appen och dess tjänster i flera regioner i molnet för att säkerställa tillgänglighet.

I den här självstudien beskrivs hur du distribuerar en webbapp med hög tillgänglighet i flera regioner. Proceduren implementerar ett enkelt scenario som består av en webbapp och Azure Front Door. Du kan utöka begreppen för att stödja andra infrastrukturmönster. Om din app till exempel ansluter till ett Azure databaserbjudande eller lagringskonto kan du läsa Aktiv geo-replikering för SQL-databaser och Azure Storage redundans. En referensarkitektur för ett mer detaljerat scenario finns i webbappsmönstret Reliable för .NET.

I den här handledningen kommer du att:

Förutsättningar

Om du inte har ett Azure konto skapar du ett fritt konto innan du börjar.

För att slutföra den här kursen behöver du:

• Använd Bash-miljön i Azure Cloud Shell. Mer information finns i Hämta igång med Azure Cloud Shell.

  

• Om du föredrar att köra CLI-referenskommandon lokalt install Azure CLI. Om du kör på Windows eller macOS kan du överväga att köra Azure CLI i en Docker-container. Mer information finns i Hur du kör Azure CLI i en Docker-container.

  • Om du använder en lokal installation loggar du in på Azure CLI med hjälp av kommandot az login. Slutför autentiseringsprocessen genom att följa stegen som visas i terminalen. Andra inloggningsalternativ finns i Authenticate to Azure using Azure CLI.

  • När du uppmanas att installera Azure CLI-tillägget vid första användningen. Mer information om tillägg finns i Använda och hantera tillägg med Azure CLI.

  • Kör az version om du vill hitta versionen och de beroende bibliotek som är installerade. Om du vill uppgradera till den senaste versionen kör du az upgrade.

Granska scenarioarkitekturen

Följande arkitekturdiagram visar infrastrukturen som du skapar i den här självstudien. Den består av två identiska App Service-appar i separata regioner. Den första webbappen finns i den aktiva regionen. Det är den primära appen som ansvarar för bearbetning av inkommande trafik. Den andra appen finns i väntelägesregionen och väntar på tillgängligheten för den primära appen. Azure Front Door försöker dirigera trafik till den primära webbappen. När den primära regionen inte är tillgänglig dirigeras trafiken till väntelägeswebben. I diagrammet representerar den streckade linjen trafikroutning baserat på regionstatus. Åtkomstbegränsningar konfigureras så blockera direkt åtkomst till apparna från Internet.

Azure innehåller olika alternativ för belastningsutjämning och trafikroutning. Azure Front Door har valts för den här självstudien eftersom den omfattar internetexponerade webbappar som finns på Azure App Service och distribueras i flera regioner. Om konfigurationen skiljer sig från exemplet i den här självstudien, se Välj en belastningsutjämningslösning för ditt scenario.

Scenariot i den här självstudien innehåller följande beteende:

• Identiska App Service-appar distribueras i två separata regioner.
• Offentlig trafik som skickas direkt till webbapparna blockeras.
• Azure Front Door dirigerar trafik till den aktiva appen i den primära regionen.
• Standby-appen i den sekundära regionen är tillgänglig för att hantera trafik efter behov.

Skapa en resursgrupp

Du behöver två instanser av en webbapp som körs i olika regioner i Azure för den här handledningen.

1. Granska de tillgängliga regionparen och välj två parkopplade regioner för dina webbappar.

   I den här handledningen kallas de två regionerna för <primary-region> (eastus) och <standby-region> (westus).

2. Skapa en resursgrupp för alla resurser som du konfigurerar i den här självstudien. I den här handledningen skapas resursgruppen i <primary-region>-platsen.

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --name	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --location	<primary-region>	Regionplacering för resursgruppen. I den här självstudien används samma regionplats för resursgruppen och den primära webbappen.	eastus

   I en faktisk implementering använder du separata resursgrupper för varje region/resurs. Separationen möjliggör isolering av resurser i en haveriberedskapssituation.

   Mer information finns i kommandoreferensen az group create .

Skapa två App Service-planer

Skapa två App Service-planer, ett för varje webbapp. Skapa varje plan på den regionplats där du förväntar dig att skapa motsvarande app.

För det här kommandot använder du regionparet som du valde tidigare. Använd den aktiva regionen för den primära webbappen och den passiva regionen för väntelägeswebbappen.

Kör följande kommando för att skapa App Service-planen för den primära webbappen och kör kommandot igen för att skapa planen för väntelägesappen.

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

Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

Mer information finns i kommandoreferensen az appservice plan create .

Skapa två program

Skapa två App Service-webbappar. Placera varje app på en motsvarande App Service-plan och regionplats.

1. --runtime Identifiera språkversionen för webbapparna.

   Du kan köra följande kommando för listan över tillgängliga runtime-miljöer:

   az webapp list-runtimes
   

   Om du planerar att använda den exempelappen för Node.js som beskrivs i den här självstudien, ställ in <language-version> värdet till NODE:24-lts.

2. Skapa två webbappar. Kör följande kommando för att skapa den primära webbappen och kör kommandot igen för att skapa väntelägesappen.

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --name	<web-app-name>	Namnet på webbappen. Varje app måste ha ett globalt unikt namn. De giltiga tecknen är a-z, 0-9och -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --name	<app-service-plan>	Namnet på apptjänstplanen för webbappen.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	Exekveringsspråkversionen för webbappen.	NODE:24-lts

   Mer information finns i kommandoreferensen az webapp create .

3. Identifiera värdet defaultHostName för varje webbapp. Värdnamnsformatet är <web-app-name>.azurewebsites.net.

   Sök igenom kommandoutdata för varje webbapp och leta upp värdet, eller kör följande kommando för varje webbapp:

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --name	<web-app-name>	Namnet på webbappen.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group

   På Azure-portalen visas värdnamnet för varje app i webbappen Overview sidan.

   Registrera värden för värdnamn för senare. Du använder värdnamnen för att definiera serverdelsadresserna för Azure Front Door distribution.

4. Bekräfta att du kan komma åt de nya webbapparna.

   1. I en webbläsare anger du värdnamnet för den primära webbappen, till exempel zava-primary-app.azurewebsites.net.

      När anslutningen lyckas visas följande meddelande:

      

   2. Upprepa testet med värdnamnet för din väntelägeswebbapp.

Konfigurera Azure Front Door

En distribution i flera regioner kan använda en aktiv-aktiv eller aktiv-passiv konfiguration. Den primära regionen är aktiv och väntelägesregionen är passiv.

• En aktiv-aktiv konfiguration distribuerar begäranden över flera aktiva regioner.
• En aktiv-passiv konfiguration fortsätter att köra instanser i väntelägesregionen (passiv) men skickar inte trafik dit om inte den primära (aktiva) regionen misslyckas.

Azure Front Door gör det möjligt för dig att aktivera båda konfigurationerna. Mer information om hur du utformar appar för hög tillgänglighet och feltolerans finns i Checklista för designgranskning för tillförlitlighet.

Skapa en profil

Skapa en instans av Azure Front Door Premium för att dirigera trafik till dina webbappar.

1. Granska Azure Front Door nivåjämförelse och välj nivå för din distribution.

   I den här guiden används Azure Front Door Premium (Premium_AzureFrontDoor).

   Om du föredrar att distribuera Azure Front Door Standard bör du tänka på att standardnivån inte stöder distribution av hanterade regler med WAF-princip.

2. Kör följande kommando för att skapa profilen:

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --profile-name	<front-door-profile>	Namnet på profilen "Azure Front Door". Namnet måste vara unikt inom resursgruppen.	zava-profile
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --sku	<front-door-tier>	Nivå-SKU för Azure Front Door för distributionen.	Premium_AzureFrontDoor (rekommenderas) Standard_AzureFrontDoor

   Mer information finns i kommandoreferensen az afd profile create .

Lägg till en slutpunkt

Skapa en slutpunkt i din profil. När du har skapat den första slutpunkten kan du skapa flera slutpunkter i din profil.

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

Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

Mer information finns i kommandoreferensen az afd endpoint create .

Skapa en ursprungsgrupp

När du distribuerar till Azure Front Door behöver du en ursprungsserver som slutpunkt för din webbapps serverdel. Mer information finns i Origins och ursprungsgrupper i Azure Front Door. Ursprunget lagras i en ursprungsgrupp.

Skapa en ursprungsgrupp i din Azure Front Door profil som ska innehålla ursprung för dina två webbappar.

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>

Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

Mer information finns i kommandoreferensen az afd origin-group create .

Lägga till ursprung i ursprungsgruppen

Lägg till ett ursprung för var och en av dina webbappar i din Azure Front Door ursprungsgrupp.

1. Lägg till ett ursprung för den primära webbappen. Ange parametern --priority till 1, vilket informerar Azure Front Door om att den här appen är den primära mottagaren för trafik.

   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>
   

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	Värdnamnet för din primära webbapp. Värdnamnet kombinerar webbappens namn, till exempel zava-primary-app med värdidentifieraren. azurewebsites.net	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	Namnet på din Azure Front Door profil.	zava-profile
   --origin-group-name	<front-door-origin-group>	Namnet på Azure Front Door-ursprungsgruppen.	zava-origin-group
   --origin-name	<web-app-origin-name>	Det ursprungliga namnet för den primära webbappen. Namnet måste vara unikt i ursprungsgruppen.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	Värdhuvudet som ska skickas för begäranden till ursprunget för den primära webbapplikationen. Om du inte anger något värde avgör värdnamnet för begäran det här värdet. Azure CDN ursprung, till exempel Web Apps, Blob Storage och Cloud Services, kräver detta värdhuvudvärde för att matcha ursprungsvärdnamnet som standard.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	Prioriteten för det här ursprunget i ursprungsgruppen. För den primära webbappen anger du prioriteten till 1. Azure Front Door använder prioritetsvärdena för belastningsutjämning mellan ursprung och aktiva regioner. Värdet måste vara mellan 1 och 5.	1
   --weight	<origin-weight>	Ursprungets vikt i ursprungsgruppen för belastningsutjämning. Värdet måste vara mellan 1 och 1 000.	1 000
   --enabled-state	<origin-state>	Ange om det här ursprunget ska kunna ta emot trafik.	Enabled
   --http-port	<origin-port>	Porten som används för HTTP-begäranden till ursprunget.	80
   --https-port	<origin-secure-port>	Porten som används för säkra HTTPS-begäranden till ursprunget.	443

   Mer information finns i kommandoreferensen az afd origin create .

2. Kör kommandot igen och lägg till ett ursprung för väntelägeswebbappen . Kommandot använder samma parametrar, men med följande unika parametervärden:

   Parameter	Värde	beskrivning	Exempel
   --host-name	<web-app-name>.azurewebsites.net	Värdnamnet för din standby-webbapp .	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	Namnet på ursprunget för standby-webbappen.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	Värdrubriken som ska skickas för begäranden till standby-webbappens ursprungsserver.	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	Prioriteten för det här ursprunget i ursprungsgruppen. För väntelägeswebbappen anger du prioriteten till 2. Azure Front Door försöker dirigera all trafik till det primära ursprunget. När det primära ursprunget inte är tillgängligt dirigeras trafiken till standby-ursprunget.	2

Lägga till en routningsregel

Lägg till en routningsregel för att mappa Azure Front Door slutpunkten till ursprungsgruppen. Vägen vidarebefordrar begäranden från slutpunkten till ursprungsgruppen.

1. Skapa en routningsregel för att mappa Azure Front Door slutpunkten till ursprungsgruppen:

   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> 
   

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --profile-name	<front-door-profile>	Namnet på din Azure Front Door profil.	zava-profile
   --endpoint-name	<front-door-endpoint>	Namnet på slutpunkten i din Azure Front Door-profil.	zava-endpoint
   --forwarding-protocol	<protocol-type>	Det protokoll som används av den här routningsregel när trafik vidarebefordras till applikationer på serverdelen.	MatchRequest
   --route-name	<route-rule-name>	Namnet på routningsregeln. Måste vara unikt inom en Azure Front Door-profil.	zava-route-rule
   --https-redirect	<secure-redirect>	Anger om HTTP-trafik ska omdirigeras automatiskt till HTTPS-trafik.	Enabled
   --origin-group-name	<front-door-origin-group>	Namnet på Azure Front Door-ursprungsgruppen.	zava-origin-group
   --supported-protocols	<protocol-list>	Listan över protokoll som stöds för den här routningsregeln. Använd ett blanksteg för att separera protokolltyperna.	Http Https
   --link-to-default-domain	<domain-link>	Ange om den här vägen är länkad till standardslutpunktsdomänen.	Enabled

   Mer information finns i kommandoreferensen az afd route create .

2. Det kan ta cirka 15 minuter innan distributionen slutförs. Det kan ta lite tid innan ändringarna sprids globalt.

Begränsa endast åtkomst via Azure Front Door

Du kan för närvarande komma åt dina webbappar direkt genom att ange deras värdnamn i en webbläsare. Om du anger åtkomstbegränsningar för dina appar kan du se till att trafiken endast når dina appar via Azure Front Door.

Azure Front Door funktioner fungerar bäst när trafiken endast flödar via tjänsten. Det är bästa praxis att konfigurera webbappens ursprung för att blockera trafik som inte skickas via Azure Front Door. Annars kan trafiken kringgå Azure Front Door brandvägg för webbprogram, DDoS-skydd och andra säkerhetsfunktioner.

Trafik från Azure Front Door till dina appar kommer från en välkänd uppsättning IP-intervall som definierats i tjänsttaggen AzureFrontDoor.Backend. Med hjälp av en begränsningsregel för tjänsttaggar kan du begränsa trafik till att endast komma från Azure Front Door.

1. Hämta identifieraren för din Azure Front Door profil.

   Du behöver profil-ID:t för att säkerställa att trafiken endast kommer från din specifika Azure Front Door instans. Åtkomstbegränsningen filtrerar ytterligare inkommande begäranden baserat på det unika HTTP-huvudet som skickas från din Azure Front Door profil.

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --profile-name	<front-door-profile>	Namnet på din Azure Front Door profil.	zava-profile

   Kommandoutdata visar profil-ID (32-siffrigt alfanumeriskt värde):

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

   I nästa steg använder du profil-ID:t för <profile-identifier> värdet.

2. Kör följande kommando för att ange åtkomstbegränsningar för din primära webbapp och kör kommandot igen för att ange begränsningar för väntelägesappen.

   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>
   

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --name	<web-app-name>	Namnet på den webbapp som du anger åtkomstbegränsningar för.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Ange prioriteten för regeln för åtkomstbegränsning för alla regler som definierats för profilen. Ett lägre värde motsvarar en högre prioritet.	100
   --service-tag	<tag-name>	Ett namn på en tjänsttagg som identifieras av Azure Front Door. Åtkomstbegränsningarna gäller för det IP-intervall som anges av tjänsttaggen.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Ange en eller flera unika HTTP-huvuden för extra filtrering av inkommande trafik. Åtkomstbegränsningarna filtrerar inkommande begäranden baserat på det unika HTTP-huvudet som skickas från din Azure Front Door profil. Huvudet kombinerar prefixet Azure Front Door och profilidentifieraren för din Azure Front Door-instans.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Mer information finns i kommandoreferensen för az webapp config access-restriction add.

Testa åtkomstbegränsningar

Bekräfta att dina åtkomstbegränsningar förhindrar direkt åtkomst till dina appar.

1. I en webbläsare anger du värdnamnet för den primära webbappen, till exempel zava-primary-app.azurewebsites.net.

   Anslutningen bör misslyckas med följande meddelande:

   

2. Upprepa testet med värdnamnet för din väntelägeswebbapp, till exempel zava-standby-app.azurewebsites.net.

Testa Azure Front Door driftsättning

När du skapar Azure Front Door Standard- eller Premium-profilen kan det ta lite tid innan konfigurationen distribueras globalt. När driftsättningen är klar kan du komma åt frontend-värden.

1. Hämta värdnamnet för din Azure Front Door slutpunkt:

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

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

   Parameter	Värde	beskrivning	Exempel
   --resource-group	<resource-group>	Den resursgrupp som innehåller de resurser som skapats i den här guiden.	zava-resource-group
   --profile-name	<front-door-profile>	Namnet på din Azure Front Door profil.	zava-profile
   --endpoint-name	<front-door-endpoint>	Namnet på slutpunkten i din Azure Front Door-profil.	zava-endpoint

   Kommandoutdata visar slutpunktens värdnamn:

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

   Värdnamnet består av slutpunktsnamnet, en unik alfanumerisk hash, en identifierare och suffixet Azure Front Door. I nästa steg använder du slutpunktens värdnamn.

   Mer information finns i kommandoreferensen az afd endpoint show .

2. I en webbläsare anger du slutpunktens värdnamn, till exempel zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   Din begäran ska automatiskt dirigeras till din primära app i den aktiva regionen.

   När anslutningen lyckas visas följande meddelande:

   

3. Testa omedelbar global redundans mellan apparna i de kopplade regionerna.

   1. I en webbläsare anger du slutpunktens värdnamn, till exempel zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. Stoppa den primära appen genom att köra kommandot az webapp stop .

      Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

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

   3. Uppdatera webbläsaren.

      Om trafiken omdirigeras korrekt till väntelägesappen i den andra regionen bör du se samma sida och meddelande.

      Tips

      Du kan behöva ladda om sidan några gånger för att redundansväxlingen ska slutföras.

      Du kan bekräfta Azure Front Door omdirigerar till väntelägesappen genom att kontrollera statusen för webbapparna i Azure-portalen. På sidan Översikt för den primära webbappen ska startalternativet vara tillgängligt (inte nedtonat). På sidan Översikt för väntelägeswebbappen bör startalternativet inte vara tillgängligt (nedtonat).

   4. az webapp stop Kör kommandot igen och stoppa din standby-app.

      Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

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

   5. Uppdatera webbläsaren igen.

      Om väntelägesappen också stoppas bör all trafikroutning stoppas. Den här gången bör du se ett felmeddelande:

      

   6. az webapp start Kör kommandot och starta om väntelägesappen.

      Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser:

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

   7. Uppdatera webbläsaren så bör du se en lyckad appanslutning.

Verifieringen bekräftar att du nu kan komma åt dina appar via Azure Front Door- och redundansfunktioner som avsett.

Om du är klar med redundanstestning startar du om din primära app.

Rensa resurser

I föregående steg skapade du Azure resurser i en resursgrupp. Om du inte förväntar dig att behöva dessa resurser i framtiden tar du bort resursgruppen genom att köra följande kommando i Cloud Shell.

<placeholder> Ersätt parametervärdet med informationen för din egen resurs:

az group delete --name <resource-group>

Det kan ta några minuter att köra det här kommandot.

Distribuera från ARM eller Bicep

De resurser som du skapade i den här självstudien kan distribueras med hjälp av en Azure Resource Manager mall (ARM-mall) eller Bicep mall. Du kan börja med mycket tillgänglig Bicep-fil för webbapp för flera regioner på GitHub. Den här mallen hjälper dig att skapa en säker lösning med hög tillgänglighet för flera regioner från slutpunkt till slutpunkt med två webbappar i olika regioner bakom Azure Front Door.

Information om hur du distribuerar ARM- och Bicep-mallar finns i Distribuera Bicep filer med Azure CLI.

Vanliga frågor och svar

I den här handledningen distribuerade du en baslinjeinfrastruktur för att möjliggöra en webbapp för flera regioner. App Service innehåller funktioner som kan hjälpa dig att se till att du kör program som följer rekommenderade säkerhetsmetoder och rekommendationer.

Det här avsnittet innehåller svar på vanliga frågor som kan hjälpa dig att skydda dina appar ytterligare och distribuera och hantera dina resurser enligt bästa praxis.

Hantera och distribuera infrastruktur och Azure resurser

I den här självstudien använde du Azure CLI för att distribuera dina infrastrukturresurser. Överväg att konfigurera en mekanism för kontinuerlig distribution för att hantera programinfrastrukturen. Eftersom du distribuerar resurser i olika regioner måste du självständigt hantera dessa resurser i regionerna. För att säkerställa att resurserna är identiska i varje region, infrastruktur som kod (IaC) som en ARM-mall eller Terraform ska användas med distributionspipelines som Azure Pipelines eller GitHub Actions. När du konfigurerar den här konfigurationen på rätt sätt utlöser alla ändringar av resurser uppdateringar i alla distributionsregioner. Mer information finns i Konfigurera kontinuerlig distribution till Azure App Service.

Använda mellanlagringsplatser för säker distribution till produktion

Det rekommenderas inte att du distribuerar programkod direkt till produktionsappar och fack. Det är viktigt att ha en säker plats där du kan testa dina appar och verifiera ändringar innan du skickar dem till produktion. Använd en kombination av mellanlagringsplatser och fackväxling för att flytta kod från testmiljön till produktion.

I den här handboken skapade du baslinjeinfrastrukturen som stöder användning av mellanplatser. Du kan skapa distributionsplatser för varje instans av webbappen och konfigurera kontinuerlig distribution till dessa mellanlagringsplatser med GitHub Actions. Precis som med infrastrukturhantering rekommenderar vi även att du konfigurerar kontinuerlig distribution för programmets källkod för att säkerställa att ändringar mellan regioner förblir synkroniserade. Om du inte konfigurerar kontinuerlig distribution måste du manuellt uppdatera varje app i varje region varje gång det sker en kodändring.

Följ den här proceduren om du vill använda mellanlagringsplatser:

1. För den här proceduren behöver du en app som är redo att distribueras till din App Service-app.

   Om du har slutfört självstudien kan du använda din primära webbapp och väntelägeswebbapp. Du behöver dock en App Service-plan som stöder tillräckligt många distributionsplatser. Mer information finns i Azure prenumerations- och tjänstgränser, kvoter och begränsningar.

   Om du inte har någon app kan du börja med exempelappen Node.js Hello World. Förka GitHub-förvaret så att du får en egen kopia för att göra ändringar.

2. Konfigurera inställningarna för App Service-stacken för dina webbappar.

   Stackinställningar avser språkversionen eller körtiden som används för din app.

   Du kan konfigurera inställningarna i Azure-portalen eller använda kommandot az webapp config set. Om du använder exemplet Node.js anger du stackinställningarna till Node 24 LTS.

   1. I Azure-portalen går du till din primära webbapp.

   2. I den vänstra menyn väljer du Inställningar>Konfiguration.

   3. På fliken Stack-inställningar konfigurerar du följande inställningar:

      1. Välj stackvärdet , till exempel Nod.

      2. Välj värdet Version , till exempel Nod 24 LTS.

      3. Välj Tillämpa.

   4. Upprepa processen för att konfigurera inställningarna för App Service-stacken för din väntelägeswebbapp .

3. Konfigurera kontinuerlig distribution i Azure-portalen. Detaljerad information om hur du konfigurerar kontinuerlig distribution med leverantörer som GitHub Actions finns i Konfigurera kontinuerlig distribution till Azure App Service.

4. Kör följande kommando för att skapa ett mellanlagringsfack med namnet stage för din primära webbapp.

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

5. az webapp deployment slot create Kör kommandot igen och skapa ett mellanlagringsfack med namnet stage för väntelägeswebbappen.

6. Konfigurera kontinuerlig distribution med GitHub Actions för varje mellanlagringsplats:

   1. I Azure-portalen går du till din primära webbapp.

   2. I den vänstra menyn väljer du Distribution>Distributionsplatser.

   3. Leta upp scenfacket i listan och välj facket för att öppna informationsfönstret.

   4. I den vänstra menyn väljer du Distribuering>Distribueringscenter.

   5. På fliken Settings anger du alternativet Source till GitHub:

      

   6. Om du distribuerar från GitHub för första gången väljer du Authorize och följer auktoriseringsanvisningarna. Om du vill distribuera från en annan användares lagringsplats väljer du Ändra konto.

   7. När du har auktorisera ditt Azure konto med GitHub väljer du Organization, Repository och Branch att konfigurera CI/CD för. Om du inte hittar en organisation eller lagringsplats kan du behöva aktivera fler behörigheter för GitHub. Mer information finns i Hantera användaråtkomst till organisationens lagringsplatser.

      Om du använder Node.js exempelappen använder du följande inställningar.

      Inställning	Värde
      Organisation	<your-GitHub-organization>
      Lagringsplats	nodejs-docs-hello-world
      Filial	huvud

   8. Välj Spara.

Nya incheckningar i den valda lagringsplatsen och grenen distribueras nu kontinuerligt till appfacket för App Service. Du kan spåra incheckningar och distributioner på fliken Loggar .

En standardarbetsflödesfil som använder en publiceringsprofil för att autentisera till App Service läggs till i din GitHub lagringsplats. Du kan visa den här filen genom att gå till <repo-name>/.github/workflows/ katalogen.

Inaktivera grundläggande autentisering i App Service

Du kan begränsa åtkomsten till FTP- och SCM-slutpunkterna till användare som backas upp av Microsoft Entra ID genom att inaktivera grundläggande autentisering.

Om du använder ett verktyg för kontinuerlig distribution för att distribuera programmets källkod kräver inaktivering av grundläggande autentisering extra steg för att konfigurera kontinuerlig distribution. Du kan till exempel inte använda en publiceringsprofil eftersom den inte använder Microsoft Entra autentiseringsuppgifter. I stället måste du använda antingen tjänstens huvudnamn eller OpenID Connect-autentiseringsuppgifter .

Följande kommandon inaktiverar grundläggande autentisering för den primära App Service-webbappen och mellanlagringsplatsen samt standby-webbappen och mellanlagringsplatsen. Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser.

1. Inaktivera FTP-åtkomst för produktionsplatser och mellanlagringsplatser för din primära webbapp:

   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. Kör kommandona igen för din väntelägeswebbapp .

3. Inaktivera grundläggande autentiseringsåtkomst till WebDeploy-porten och SCM-platsen för produktionsplatserna och mellanlagringsplatserna för din primära webbapp:

   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. Kör kommandona igen för din väntelägeswebbapp .

Mer information om hur du inaktiverar grundläggande autentisering, inklusive hur du testar och övervakar inloggningar, finns i Inaktivera grundläggande autentisering i App Service-distributioner.

Använda kontinuerlig distribution när grundläggande autentisering är inaktiverad

Om du väljer att tillåta grundläggande autentisering för dina App Service-appar kan du använda någon av de tillgängliga distributionsmetoderna i App Service. Du kan till exempel använda den publiceringsprofil som du konfigurerade i avsnittet mellanlagringsplatser .

Om du inaktiverar grundläggande autentisering för dina App Service-appar kräver kontinuerlig distribution ett huvudnamn för tjänsten eller OpenID Connect för autentisering. Om du använder GitHub Actions som kodlagringsplats kan du se Distribuera till Azure App Service genom att använda GitHub Actions. Självstudien innehåller steg-för-steg-instruktioner för att skapa en service principal eller använda OpenID Connect för distribution till App Service med GitHub Actions. Du kan också slutföra processen genom att följa proceduren i nästa avsnitt.

Skapa tjänstens huvudnamn och autentiseringsuppgifter med GitHub Actions

Konfigurera kontinuerlig distribution med GitHub Actions och ett huvudnamn för tjänsten:

1. Skapa tjänstens huvudnamn för din primära webbapp och väntelägeswebbapp:

   Ersätt följande <placeholder> parametervärden med informationen för dina egna resurser.

   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>
   

   Utdata är ett JSON-objekt med autentiseringsuppgifterna för rolltilldelning som ger åtkomst till dina App Service-appar.

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

   JSON innehåller din klienthemlighet, som bara visas just nu.

   Tips

   Det är en bra idé att bevilja minsta möjliga åtkomst. I det här exemplet är omfånget begränsat till bara apparna, inte hela resursgruppen.

2. Kopiera JSON-objektet så att du har ett register över din klientsekretess.

3. Ange inloggningsuppgifterna för din tjänstens huvudkonto till Azure sign in-operationen som en del av ditt GitHub Actions-arbetsflöde.

   Du kan ange värdena direkt i arbetsflödet eller lagra dem som GitHub hemligheter som refereras till i arbetsflödet. Att spara värdena som GitHub hemligheter är det säkrare alternativet.

   1. Öppna GitHub lagringsplatsen för din app.

   2. Gå till Inställningar>> och variabler >Åtgärder.

   3. Välj Ny lagringsplatshemlighet och skapa en hemlighet för var och en av följande inställningar. Använd värdena från dina JSON-utdata.

      Inställning	Värde	Exempel
      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

Skapa GitHub Actions arbetsflöde

När du har ett huvudnamn för tjänsten som kan komma åt dina App Service-appar redigerar du standardarbetsflödena för dina appar. Dessa arbetsflöden genereras automatiskt när du konfigurerar kontinuerlig distribution.

Autentiseringen måste utföras med tjänstens huvudnamn i stället för publiceringsprofilen. Exempelarbetsflöden finns på fliken Service principal i Lägg till arbetsflödesfilen till din GitHub lagringsplats. Följande exempelarbetsflöde kan användas för Node.js exempelappen.

1. Öppna GitHub lagringsplatsen för din app.

2. Gå till <repo-name>/.github/workflows/ katalogen. Du bör se de automatiskt genererade arbetsflödena.

3. För varje arbetsflödesfil väljer du Redigera (penna).

4. Ersätt innehållet i arbetsflödesfilen med följande innehåll. Koden förutsätter att du redan har skapat GitHub hemligheter för dina autentiseringsuppgifter.

   I avsnittet env konfigurerar du följande inställningar:

   • AZURE_WEBAPP_NAME: Ersätt <web-app-name> platshållaren med namnet på webbappen.
   • NODE_VERSION: Ange vilken nodversion som ska användas. För det Node.js-exemplet är '24.x' värdet.
   • AZURE_WEBAPP_PACKAGE_PATH: Ange sökvägen till webbappsprojektet. Standardvärdet är lagringsplatsens rot, '.'.
   • AZURE_WEBAPP_SLOT_NAME: Ange namnet på applikationsslotet. Det gemensamma namnet är 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. Spara och committa arbetsflödesfilens ändringar direkt på huvudgrenen i ditt förvar.

   Commiteringen utlöser GitHub-åtgärden att köras igen och distribuera din kod. Den här gången används tjänsthuvudnamn för att autentisera.

Testa appuppdateringar med hjälp av platstrafikroutning

Med trafikroutning med slitsar kan du dirigera en fördefinierad del av trafiken till varje slits. Inledningsvis dirigeras 100 % av trafiken till produktionsplatsen. Du kan dock skicka 10% av trafiken till mellanlagringsplatsen. Den här metoden för routning av slottrafik skickar automatiskt 10 % av användarna som försöker ansluta till staging slot. Metoden kräver inga ändringar i din Azure Front Door-instans. Mer information om platsbyten och mellanlagringsmiljöer i App Service finns i Set up staging environments in Azure App Service.

Flytta kod från mellanlagringsplats till produktionsplats

När du har testat och verifierat i mellanlagringsplatserna kan du utföra ett fackbyte från mellanlagringsplatsen till produktionsplatsen. Du slutför växlingen för alla instanser av din app i varje region. Vid ett platsbyte ser App Service-plattformen till att målplatsen inte upplever driftstopp.

1. Utför växlingen för din primära webbapp:

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

2. Utför växlingen för din väntelägeswebbapp :

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

3. Efter några minuter går du till din Azure Front Door-endpoint i Azure-portalen och verifierar att fackbytet lyckades.

Nu är dina appar igång och alla ändringar du gör i programmets källkod utlöser automatiskt en uppdatering av båda dina mellanlagringsplatser. När du är redo kan du sedan upprepa slotswap-processen för att flytta koden till produktion.

Undvik avbrott och kontinuitetsproblem med hjälp av distributioner i flera regioner

Du kan undvika potentiella störningar eller problem med kontinuitet mellan regioner genom att tillfälligt ta bort en webbplats som genomgår fackbytet från din Azure Front Door ursprungsgrupp. Den här åtgärden hjälper till att förhindra att kunder ser olika versioner av din app samtidigt. Det är också användbart när du gör betydande ändringar i dina appar. Den tillfälliga borttagningen gör att all trafik omdirigeras till det andra ursprunget.

1. I Azure-portalen går du till instansen Azure Front Door.

2. I den vänstra menyn väljer du Inställningar>Ursprungsgrupper.

3. I listan över ursprungsgrupper väljer du den ursprungsgrupp som innehåller det fack som du tillfälligt vill ta bort.

4. I fönstret Uppdatera ursprungsgrupp letar du reda på det fack som du vill ta bort i listan Ursprungsvärdnamn .

5. Välj Fler åtgärder (...) >Ta bort och välj sedan Uppdatera.

   

   Det kan ta flera minuter att tillämpa ändringen.

6. När du är redo att tillåta trafik till den borttagna platsen, går du tillbaka till panelen Uppdatera ursprungsgrupp.

7. Längst upp väljer du + Lägg till ett ursprung för att läsa ursprungsplatsen tillbaka till ursprungsgruppen.

   

Skapa extra ursprungsgrupper och ändra routningsassociationer

Om du inte vill ta bort och läsa ursprung kan du skapa extra ursprungsgrupper för din Azure Front Door-instans. Du kan sedan associera vägen till den ursprungsgrupp som pekar på det avsedda ursprunget.

Du kan till exempel skapa två extra ursprungsgrupper, en för din primära (aktiva) region och en för din väntelägesregion (passiv). Om din primära region genomgår en ändring associerar du vägen med din väntelägesregion. Om din väntelägesregion genomgår en ändring associerar du vägen med din primära region. När alla ändringar är klara kan du associera vägen med den ursprungliga ursprungsgruppen som innehåller båda regionerna. Den här metoden fungerar eftersom en väg bara kan associeras med en ursprungsgrupp i taget.

Överväg en konfiguration med tre ursprungsgrupper:

• Gruppen Main-Origin innehåller både primära och väntelägeswebbappar, var och en i sina respektive regioner.
• Gruppen Primary-Origin innehåller endast den primära webbappen i den aktiva regionen.
• Gruppen Standby-Origin innehåller endast väntelägeswebbappen i den passiva regionen.

Anta att den primära webbappen genomgår en ändring. Innan ändringarna börjar ändras routningsassociationen Main-Origin för gruppen till Secondary-Origin gruppen. Den här åtgärden säkerställer att all trafik dirigeras till standby-webbappen i dess respektive region medan den primära webbappen i dess respektive region är under förändring.

Följ dessa steg för att ändra routningsassociationen för en ursprungsgrupp:

1. I Azure-portalen går du till instansen Azure Front Door.

2. I den vänstra menyn väljer du Inställningar>Ursprungsgrupper.

3. Leta upp en ursprungsgrupp i listan över ursprungsgrupper som visar indikatorn Oassocierad i kolumnen Vägar .

4. Välj Fler åtgärder (...) >Associera slutpunkt och väg.

   

5. I fönstret Associera vägar väljer du en eller flera vägar som ska associeras med ursprungsgruppen och väljer sedan Associera.

   

Begränsa åtkomsten till webbplatsen för avancerade verktyg

Med Azure App tjänst används webbplatsen för SCM/avancerade verktyg för att hantera dina appar och distribuera programkällkoden. Överväg att låsa webbplatsen för SCM/avancerade verktyg eftersom den här webbplatsen troligen inte behöver nås via Front Door. Du kan till exempel konfigurera åtkomstbegränsningar som bara gör att du kan utföra testningen och aktivera kontinuerlig distribution från valfritt verktyg. Om du använder distributionsfack kan du, specifikt för produktionsplatser, neka nästan all åtkomst till SCM-platsen eftersom din testning och validering görs med mellanlagringsplatserna.

Relaterat innehåll

• Distribuera en webbapp med hög tillgänglighet i flera regioner
• Granska baslinjearkitekturen för en zonredundant webbapp med hög tillgänglighet