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

Artikel
10/18/2023

Hög tillgänglighet och feltolerans är viktiga komponenter i en välkonstruerad lösning. Det är bäst att förbereda sig för det oväntade genom att ha en nödplan som kan förkorta stilleståndstiden och hålla systemen igång automatiskt när något misslyckas.

När du distribuerar ditt program till molnet väljer du en region i molnet där programinfrastrukturen är baserad. Om ditt program distribueras till en enda region och regionen blir otillgänglig blir ditt program också otillgängligt. Den här bristen på tillgänglighet kan vara oacceptabel enligt villkoren i programmets serviceavtal. I så fall är det en bra lösning att distribuera ditt program och dess tjänster i flera regioner.

I den här självstudien får du lära dig hur du distribuerar en webbapp med hög tillgänglighet i flera regioner. Det här scenariot hålls enkelt genom att begränsa programkomponenterna till bara en webbapp och Azure Front Door, men begreppen kan utökas och tillämpas på andra infrastrukturmönster. Om ditt program till exempel ansluter till ett Azure-databaserbjudande eller lagringskonto läser du aktiv geo-replikering för SQL-databaser och redundansalternativ för lagringskonton. En referensarkitektur för ett mer detaljerat scenario finns i Webbprogram för flera regioner med hög tillgänglighet.

Följande arkitekturdiagram visar infrastrukturen som du skapar i den här självstudien. Den består av två identiska App Services i separata regioner, varav den ena är den aktiva eller primära regionen, och den andra är vänteläge eller sekundär region. Azure Front Door används för att dirigera trafik till App Services och åtkomstbegränsningar konfigureras så att direkt åtkomst till apparna från Internet blockeras. Den streckade linjen anger att trafiken endast skickas till väntelägesregionen om den aktiva regionen slutar fungera.

Azure tillhandahåller olika alternativ för belastningsutjämning och trafikroutning. Azure Front Door valdes för det här användningsfallet eftersom det omfattar internetuppkopplade webbappar som finns i Azure App Service som distribuerats i flera regioner. Information om vad du ska använda för ditt användningsfall om det skiljer sig från den här självstudien finns i beslutsträdet för belastningsutjämning i Azure.

Arkitekturdiagram över en App Service i flera regioner.

Med den här arkitekturen:

Identiska App Service-appar distribueras i två separata regioner.
Offentlig trafik direkt till App Service-apparna blockeras.
Azure Front Door används för att dirigera trafik till den primära/aktiva regionen. Den sekundära regionen har en App Service som är igång och redo att hantera trafik om det behövs.

Detta får du får lära dig:

Skapa identiska App Services i separata regioner.
Skapa Azure Front Door med åtkomstbegränsningar som blockerar offentlig åtkomst till App Services.

Förutsättningar

Om du inte har en Azure-prenumeration skapar du ett kostnadsfritt Azure-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 Snabbstart för Bash i Azure Cloud Shell.
Om du föredrar att köra CLI-referenskommandon lokalt installerar du Azure CLI. Om du kör i Windows eller macOS kan du köra Azure CLI i en Docker-container. Mer information finns i Så här kör du 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 Logga in med 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 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.

Skapa två instanser av en webbapp

Du behöver två instanser av en webbapp som körs i olika Azure-regioner för den här självstudien. Du använder regionparet USA, östra/USA, västra som två regioner och skapar två tomma webbappar. Välj gärna dina egna regioner om det behövs.

För att göra hanteringen och rensningen enklare använder du en enda resursgrupp för alla resurser i den här självstudien. Överväg att använda separata resursgrupper för varje region/resurs för att ytterligare isolera dina resurser i en haveriberedskapssituation.

Kör följande kommando för att skapa resursgruppen.

az group create --name myresourcegroup --location eastus

Skapa App Service-planer

Kör följande kommandon för att skapa App Service-abonnemangen. Ersätt platshållarna för <app-service-plan-east-us> och <app-service-plan-west-us> med två unika namn där du enkelt kan identifiera den region de befinner sig i.

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

Skapa webbappar

När App Service-planerna har skapats kör du följande kommandon för att skapa webbapparna. Ersätt platshållarna för <web-app-east-us> och <web-app-west-us> med två globalt unika namn (giltiga tecken är a-z, 0-9och -) och var noga med att uppmärksamma parametern --plan så att du placerar en app i varje plan (och därför i varje region). Ersätt parametern <runtime> med språkversionen av din app. Kör az webapp list-runtimes för listan över tillgängliga körningar. Om du planerar att använda exempelappen Node.js som anges i den här självstudien i följande avsnitt använder NODE:18-lts du som körning.

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

Anteckna standardvärdnamnet för varje webbapp så att du kan definiera serverdelsadresserna när du distribuerar Front Door i nästa steg. Versionsformatet ska vara <web-app-name>.azurewebsites.net. Dessa värdnamn kan hittas genom att köra följande kommando eller genom att gå till appens översiktssida i Azure Portal.

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

Skapa en Azure Front Door

En distribution i flera regioner kan använda en aktiv-aktiv eller aktiv-passiv konfiguration. En aktiv-aktiv konfiguration distribuerar begäranden över flera aktiva regioner. En aktiv-passiv konfiguration fortsätter att köra instanser i den sekundära regionen, men skickar inte trafik dit om inte den primära regionen misslyckas. Azure Front Door har en inbyggd funktion som gör att du kan aktivera dessa konfigurationer. Mer information om hur du utformar appar för hög tillgänglighet och feltolerans finns i Skapa Azure-program för återhämtning och tillgänglighet.

Skapa en Azure Front Door-profil

Nu skapar du en Azure Front Door Premium för att dirigera trafik till dina appar.

Kör az afd profile create för att skapa en Azure Front Door-profil.

Kommentar

Om du vill distribuera Azure Front Door Standard i stället för Premium ersätter du värdet för parametern --sku med Standard_AzureFrontDoor. Du kan inte distribuera hanterade regler med WAF-princip om du väljer standardnivån. En detaljerad jämförelse av prisnivåerna finns i Jämförelse av Azure Front Door-nivå.

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor

Parameter	Värde	beskrivning
`profile-name`	`myfrontdoorprofile`	Namn på Azure Front Door-profilen, som är unik i resursgruppen.
`resource-group`	`myresourcegroup`	Resursgruppen som innehåller resurserna från den här självstudien.
`sku`	`Premium_AzureFrontDoor`	Prisnivån för Azure Front Door-profilen.

Lägg till en slutpunkt

Kör az afd endpoint create för att skapa en slutpunkt i din profil. Du kan skapa flera slutpunkter i din profil när du har slutfört skapandeupplevelsen.

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled

Parameter	Värde	beskrivning
`endpoint-name`	`myendpoint`	Namnet på slutpunkten under profilen, som är unik globalt.
`enabled-state`	`Enabled`	Om den här slutpunkten ska aktiveras.

Skapa en ursprungsgrupp

Kör az afd origin-group create för att skapa en ursprungsgrupp som innehåller dina två webbappar.

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50

Parameter	Värde	beskrivning
`origin-group-name`	`myorigingroup`	Namnet på ursprungsgruppen.
`probe-request-type`	`GET`	Den typ av hälsoavsökningsbegäran som görs.
`probe-protocol`	`Http`	Protokoll som ska användas för hälsoavsökning.
`probe-interval-in-seconds`	`60`	Antalet sekunder mellan hälsoavsökningar.
`probe-path`	`/`	Sökvägen i förhållande till ursprunget som används för att fastställa ursprungets hälsotillstånd.
`sample-size`	`4`	Antalet exempel som ska övervägas för beslut om belastningsutjämning.
`successful-samples-required`	`3`	Antalet exempel inom exempelperioden som måste lyckas.
`additional-latency-in-milliseconds`	`50`	Den extra svarstiden i millisekunder för att avsökningar ska hamna i bucketen med lägsta svarstid.

Lägga till ett ursprung i gruppen

Kör az afd origin create för att lägga till ett ursprung i ursprungsgruppen. För parametern --host-name ersätter du platshållaren för <web-app-east-us> med ditt appnamn i den regionen. Observera att parametern --priority är inställd på 1, vilket anger att all trafik skickas till din primära app.

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Parameter	Värde	beskrivning
`host-name`	`<web-app-east-us>.azurewebsites.net`	Värdnamnet för den primära webbappen.
`origin-name`	`primaryapp`	Namnet på ursprunget.
`origin-host-header`	`<web-app-east-us>.azurewebsites.net`	Värdhuvudet som ska skickas för begäranden till det här ursprunget. Om du lämnar detta tomt 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 att värdhuvudvärdet matchar ursprungsvärdnamnet som standard.
`priority`	`1`	Ange den här parametern till 1 för att dirigera all trafik till den primära webbappen.
`weight`	`1000`	Ursprungets vikt i den angivna ursprungsgruppen för belastningsutjämning. Måste vara mellan 1 och 1 000.
`enabled-state`	`Enabled`	Om du vill aktivera det här ursprunget.
`http-port`	`80`	Porten som används för HTTP-begäranden till ursprunget.
`https-port`	`443`	Porten som används för HTTPS-begäranden till ursprunget.

Upprepa det här steget för att lägga till ditt andra ursprung. Var uppmärksam på parametern --priority . För det här ursprunget är det inställt på 2. Den här prioritetsinställningen instruerar Azure Front Door att dirigera all trafik till det primära ursprunget såvida inte den primära inställningen slutar fungera. Om du anger prioriteten för det här ursprunget till 1behandlar Azure Front Door både ursprung som aktiv och direkt trafik till båda regionerna. Se till att ersätta båda instanserna av platshållaren för <web-app-west-us> med namnet på webbappen.

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Lägg till en väg

Kör az afd route create för att mappa slutpunkten till ursprungsgruppen. Den här vägen vidarebefordrar begäranden från slutpunkten till ursprungsgruppen.

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled

Parameter	Värde	beskrivning
`endpoint-name`	`myendpoint`	Namnet på slutpunkten.
forwarding-protocol	MatchRequest	Protokoll som den här regeln använder vid vidarebefordran av trafik till serverdelar.
`route-name`	`route`	Namnet på vägen.
https-redirect	`Enabled`	Om HTTP-trafik ska omdirigeras automatiskt till HTTPS-trafik.
`supported-protocols`	`Http Https`	Lista över protokoll som stöds för den här vägen.
`link-to-default-domain`	`Enabled`	Om den här vägen är länkad till standardslutpunktsdomänen.

Tillåt cirka 15 minuter för det här steget att slutföras eftersom det tar lite tid för den här ändringen att spridas globalt. Efter den här perioden fungerar Azure Front Door fullt ut.

Begränsa åtkomsten till webbappar till Azure Front Door-instansen

Nu kan du fortfarande komma åt dina appar direkt med hjälp av deras URL:er just nu. För att säkerställa att trafiken bara kan nå dina appar via Azure Front Door anger du åtkomstbegränsningar för var och en av dina appar. Front Door-funktionerna fungerar bäst när trafiken endast flödar genom Front Door. Du bör konfigurera ditt ursprung för att blockera trafik som inte skickas via Front Door ännu. Annars kan trafiken kringgå Front Door brandvägg för webbprogram, DDoS-skydd och andra säkerhetsfunktioner. Trafik från Azure Front Door till dina program kommer från en välkänd uppsättning IP-intervall som definierats i AzureFrontDoor.Backend tjänsttaggen. Genom att använda en begränsningsregel för tjänsttaggar kan du begränsa trafik till att endast komma från Azure Front Door.

Innan du konfigurerar åtkomstbegränsningarna för App Service bör du anteckna Front Door-ID :t genom att köra följande kommando. Det här ID:t behövs för att säkerställa att trafiken endast kommer från din specifika Front Door-instans. Åtkomstbegränsningen filtrerar ytterligare inkommande begäranden baserat på det unika HTTP-huvud som Azure Front Door skickar.

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

Kör följande kommandon för att ange åtkomstbegränsningar för dina webbappar. Ersätt platshållaren för <front-door-id> med resultatet från föregående kommando. Ersätt platshållarna för appnamnen.

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

Testa Front Door

När du skapar Azure Front Door Standard/Premium-profilen tar det några minuter innan konfigurationen distribueras globalt. När du är klar kan du komma åt klientdelsvärden som du skapade.

Kör az afd endpoint show för att hämta värdnamnet för Front Door-slutpunkten.

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

I en webbläsare går du till slutpunktens värdnamn som föregående kommando returnerade: <myendpoint>-<hash>.z01.azurefd.net. Din begäran ska automatiskt dirigeras till den primära appen i USA, östra.

Så här testar du omedelbar global redundans:

Öppna en webbläsare och gå till slutpunktens värdnamn: <myendpoint>-<hash>.z01.azurefd.net.

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

az webapp stop --name <web-app-east-us> --resource-group myresourcegroup

Uppdatera webbläsaren. Du bör se samma informationssida eftersom trafiken nu dirigeras till appen som körs i USA, västra.

Dricks

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

Stoppa nu den sekundära appen.

az webapp stop --name <web-app-west-us> --resource-group myresourcegroup

Uppdatera webbläsaren. Den här gången bör du se ett felmeddelande.
Starta om en av Web Apps genom att köra az webapp start. Uppdatera webbläsaren så bör du se appen igen.
```
az webapp start --name <web-app-east-us> --resource-group myresourcegroup
```

Nu har du verifierat att du kan komma åt dina appar via Azure Front Door och att redundans fungerar som avsett. Starta om den andra appen om du är klar med redundanstestning.

Om du vill testa åtkomstbegränsningarna och se till att dina appar bara kan nås via Azure Front Door öppnar du en webbläsare och navigerar till var och en av appens URL:er. Kör följande kommandon för att hitta URL:erna:

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

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

Du bör se en felsida som anger att apparna inte är tillgängliga.

Rensa resurser

I de föregående stegen skapade du Azure-resurser i en resursgrupp. Om du inte tror att du behöver dessa resurser i framtiden tar du bort resursgruppen genom att köra följande kommando i Cloud Shell.

az group delete --name myresourcegroup

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

Distribuera från ARM/Bicep

De resurser som du skapade i den här självstudien kan distribueras med hjälp av en ARM/Bicep-mall. Med webbappen Bicep med hög tillgänglighet för flera regioner kan du skapa en säker lösning med hög tillgänglighet för flera regioner med två webbappar i olika regioner bakom Azure Front Door.

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

Vanliga frågor och svar

I den här självstudien hittills har du distribuerat baslinjeinfrastrukturen för att aktivera en webbapp för flera regioner. App Service innehåller funktioner som kan hjälpa dig att se till att du kör program enligt bästa praxis och rekommendationer för säkerhet.

Det här avsnittet innehåller vanliga frågor som kan hjälpa dig att skydda dina appar ytterligare och distribuera och hantera dina resurser med hjälp av metodtips.

Vilken är den rekommenderade metoden för att hantera och distribuera programinfrastruktur 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 bör infrastruktur som kod (IaC) som Azure Resource Manager-mallar eller Terraform användas med distributionspipelines som Azure Pipelines eller GitHub Actions. På så sätt utlöser alla ändringar av resurser uppdateringar i alla regioner som du distribueras till om de konfigureras på rätt sätt. Mer information finns i Kontinuerlig distribution till Azure App Service.

Hur kan jag använda mellanlagringsplatser för att öva på säker distribution till produktion?

Det rekommenderas inte att du distribuerar programkoden direkt till produktionsappar/fack. Det beror på att du vill ha en säker plats för att testa dina appar och verifiera ändringar som du gör innan du pushar till produktion. Använd en kombination av mellanlagringsplatser och fackväxling för att flytta kod från testmiljön till produktion.

Du har redan skapat baslinjeinfrastrukturen för det här scenariot. Nu skapar du distributionsplatser för varje instans av din app och konfigurerar kontinuerlig distribution till dessa mellanlagringsplatser med GitHub Actions. Precis som med infrastrukturhantering rekommenderar vi även att du konfigurerar kontinuerlig distribution för programkällkoden för att säkerställa att ändringar mellan regioner är synkroniserade. Om du inte konfigurerar kontinuerlig distribution måste du uppdatera varje app manuellt i varje region varje gång det sker en kodändring.

För de återstående stegen i den här självstudien bör du ha en app som är redo att distribueras till dina App Services. Om du behöver en exempelapp kan du använda exempelappen Node.js Hello World. Förgrena lagringsplatsen så att du har en egen kopia.

Se till att ange inställningarna för App Service-stacken för dina appar. Stackinställningar refererar till språket eller körningen som används för din app. Den här inställningen kan konfigureras med hjälp av Azure CLI med az webapp config set kommandot eller i portalen med följande steg. Om du använder exemplet Node.js anger du stackinställningarna till Nod 18 LTS.

Gå till din app och välj Konfiguration i den vänstra innehållsförteckningen.
Välj fliken Allmänt inställningar.
Under Stack-inställningar väljer du lämpligt värde för din app.
Välj Spara och sedan Fortsätt för att bekräfta uppdateringen.
Upprepa de här stegen för dina andra appar.

Kör följande kommandon för att skapa mellanlagringsplatser som kallas "fas" för var och en av dina appar. Ersätt platshållarna för <web-app-east-us> och <web-app-west-us> med dina appnamn.

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

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

Om du vill konfigurera kontinuerlig distribution bör du använda Azure Portal. Detaljerad vägledning om hur du konfigurerar kontinuerlig distribution med leverantörer som GitHub Actions finns i Kontinuerlig distribution till Azure App Service.

Utför följande steg för var och en av dina mellanlagringsplatser för att konfigurera kontinuerlig distribution med GitHub Actions.

I Azure Portal går du till hanteringssidan för en av appplatserna i App Service.
I den vänstra rutan väljer du Distributionscenter. Välj sedan Inställningar.
I rutan Källa väljer du "GitHub" från CI/CD-alternativen:
Om du distribuerar från GitHub för första gången väljer du Auktorisera och följer auktoriseringsanvisningarna. Om du vill distribuera från en annan användares lagringsplats väljer du Ändra konto.
När du har auktoriserat ditt Azure-konto med GitHub väljer du den organisation, lagringsplats och gren som du vill konfigurera CI/CD för. Om du inte hittar en organisation eller lagringsplats kan du behöva aktivera fler behörigheter på GitHub. Mer information finns i Hantera åtkomst till organisationens lagringsplatser.
1. 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-
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 .

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

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

Hur gör jag för att inaktivera grundläggande autentisering i App Service?

Överväg att inaktivera grundläggande autentisering, vilket begränsar åtkomsten till FTP- och SCM-slutpunkterna till användare som backas upp av Microsoft Entra-ID. 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.

Om du vill inaktivera grundläggande autentisering för Din App Service kör du följande kommandon för varje app och fack genom att ersätta platshållarna för <web-app-east-us> och <web-app-west-us> med appnamnen. Den första uppsättningen kommandon inaktiverar FTP-åtkomst för produktionsplatser och mellanlagringsplatser, och den andra uppsättningen kommandon inaktiverar grundläggande autentiseringsåtkomst till WebDeploy-porten och SCM-platsen för produktionsplatserna och mellanlagringsplatserna.

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

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

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

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

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

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

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

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

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.

Hur gör jag för att distribuera min kod med kontinuerlig distribution om jag inaktiverade grundläggande autentisering?

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, inklusive att använda publiceringsprofilen som konfigurerades i avsnittet mellanlagringsplatser .

Om du inaktiverar grundläggande autentisering för dina App Services 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 läsa stegvisa självstudier för att använda tjänstens huvudnamn eller OpenID Connect för att distribuera till App Service med GitHub Actions eller slutföra stegen i följande avsnitt.

Skapa tjänstens huvudnamn och konfigurera autentiseringsuppgifter med GitHub Actions

Använd följande steg för att konfigurera kontinuerlig distribution med GitHub Actions och ett huvudnamn för tjänsten.

Kör följande kommando för att skapa tjänstens huvudnamn. Ersätt platshållarna med dina <subscription-id> och appnamnen. Utdata är ett JSON-objekt med autentiseringsuppgifterna för rolltilldelning som ger åtkomst till dina App Service-appar. Kopiera det här JSON-objektet för nästa steg. Den innehåller din klienthemlighet, som bara visas just nu. Det är alltid en bra idé att bevilja minsta möjliga åtkomst. Omfånget i det här exemplet är begränsat till bara apparna, inte hela resursgruppen.
```
az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth
```
Du måste ange autentiseringsuppgifterna för tjänstens huvudnamn för azure-/inloggningsåtgärden som en del av det GitHub Action-arbetsflöde som du använder. Dessa värden kan antingen anges direkt i arbetsflödet eller lagras i GitHub-hemligheter och refereras till i arbetsflödet. Att spara värdena som GitHub-hemligheter är det säkrare alternativet.
1. Öppna din GitHub-lagringsplats och gå till Inställningar>Säkerhetshemligheter>och variabler Åtgärder>
2. Välj Ny lagringsplatshemlighet och skapa en hemlighet för vart och ett av följande värden. Värdena finns i json-utdata som du kopierade tidigare.
  
  Name Värde
  
  AZURE_APP_ID <application/client-id>
  
  AZURE_PASSWORD <client-secret>
  
  AZURE_TENANT_ID <tenant-id>
  
  AZURE_SUBSCRIPTION_ID <subscription-id>

Name	Värde
AZURE_APP_ID	`<application/client-id>`
AZURE_PASSWORD	`<client-secret>`
AZURE_TENANT_ID	`<tenant-id>`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`

Skapa GitHub Actions-arbetsflödet

Nu när du har ett huvudnamn för tjänsten som kan komma åt dina App Service-appar redigerar du de standardarbetsflöden som skapades för dina appar när du konfigurerade kontinuerlig distribution. Autentiseringen måste utföras med tjänstens huvudnamn i stället för publiceringsprofilen. Exempelarbetsflöden finns på fliken "Tjänstens huvudnamn" i Lägg till arbetsflödesfilen på din GitHub-lagringsplats. Följande exempelarbetsflöde kan användas för den Node.js exempelapp som tillhandahölls.

Öppna din apps GitHub-lagringsplats och gå till <repo-name>/.github/workflows/ katalogen. Du bör se de automatiskt genererade arbetsflödena.

För varje arbetsflödesfil väljer du knappen "penna" längst upp till höger för att redigera filen. Ersätt innehållet med följande text, som förutsätter att du skapade GitHub-hemligheterna tidigare för dina autentiseringsuppgifter. Uppdatera platshållaren för <web-app-name> under avsnittet "env" och checka sedan in direkt till huvudgrenen. Den här incheckningen utlöser GitHub-åtgärden för att köras igen och distribuera din kod, den här gången med tjänstens huvudnamn för att autentisera.


name: Build and deploy Node.js app to Azure Web App

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
  NODE_VERSION: '18.x'                # set this to the node version to use
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
  AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        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@v2
        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@v2
        with:
          name: node-app

      - uses: azure/login@v1
        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@v2
        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

Hur tillåter routning av facktrafik mig att testa uppdateringar som jag gör i mina appar?

Med trafikroutning med platser kan du dirigera en fördefinierad del av användartrafiken till varje fack. Inledningsvis dirigeras 100 % av trafiken till produktionsplatsen. Du har dock möjlighet att till exempel skicka 10 % av trafiken till mellanlagringsplatsen. Om du konfigurerar routning av facktrafik på det här sättet, när användarna försöker komma åt din app, dirigeras 10 % av dem automatiskt till mellanlagringsplatsen utan ändringar i Din Front Door-instans. Mer information om fackbyten och mellanlagringsmiljöer i App Service finns i Konfigurera mellanlagringsmiljöer i Azure App Service.

Hur gör jag för att flytta min kod från mitt mellanlagringsfack till min produktionsplats?

När du är klar med testning och validering i mellanlagringsplatserna kan du utföra ett fackbyte från mellanlagringsplatsen till produktionsplatsen. Du måste göra den här växlingen för alla instanser av din app i varje region. Under ett fackbyte ser App Service-plattformen till att målplatsen inte upplever driftstopp.

Kör följande kommando för varje app för att utföra växlingen. Ersätt platshållaren för <web-app-name>.

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

Efter några minuter kan du navigera till Front Door-slutpunkten för att verifiera att fackbytet lyckades.

I det här läget är dina appar igång och eventuella ändringar som du gör i programmets källkod utlöser automatiskt en uppdatering av båda dina mellanlagringsplatser. Du kan sedan upprepa växlingsprocessen för fack när du är redo att flytta koden till produktion.

Hur kan jag annars använda Azure Front Door i mina distributioner i flera regioner?

Om du är orolig för potentiella störningar eller problem med kontinuitet mellan regioner, som att vissa kunder ser en version av din app medan andra ser en annan version, eller om du gör betydande ändringar i dina appar, kan du tillfälligt ta bort webbplatsen som genomgår fackbytet från din Front Door-ursprungsgrupp. All trafik dirigeras sedan till det andra ursprunget. Gå till fönstret Uppdatera ursprungsgrupp och Ta bort det ursprung som genomgår ändringen. När du har gjort alla dina ändringar och är redo att hantera trafiken där igen kan du återgå till samma fönster och välja + Lägg till ett ursprung för att läsa ursprunget.

Skärmbild som visar hur du tar bort ett Azure Front Door-ursprung.

Om du föredrar att inte ta bort och sedan läsa ursprung kan du skapa extra ursprungsgrupper för din Front Door-instans. Du kan sedan associera vägen till den ursprungsgrupp som pekar på det avsedda ursprunget. Du kan till exempel skapa två nya ursprungsgrupper, en för din primära region och en för den sekundära regionen. När din primära region genomgår en ändring associerar du vägen med den sekundära regionen och vice versa när den sekundära regionen genomgår en ändring. 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.

För att demonstrera arbete med flera ursprung finns det tre ursprungsgrupper i följande skärmbild. "MyOriginGroup" består av både webbappar och de andra två ursprungsgrupperna består av webbappen i respektive region. I exemplet genomgår appen i den primära regionen en ändring. Innan ändringen startades associerades vägen med "MySecondaryRegion" så all trafik skulle skickas till appen i den sekundära regionen under ändringsperioden. Du kan uppdatera vägen genom att välja Ej associerad, vilket öppnar fönstret Associera vägar .

Skärmbild som visar hur du associerar vägar med Azure Front Door.

Hur gör jag för att begränsa åtkomsten till webbplatsen för avancerade verktyg?

Med Azure App Service 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.

Nästa steg

Så här distribuerar du en webbapp med hög tillgänglighet i flera regioner

Zonredundant webbapp med hög tillgänglighet

Dela via