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

Artikel
11/25/2024

Hoge beschikbaarheid en fouttolerantie zijn belangrijke onderdelen van een goed ontworpen oplossing. Het is raadzaam om u voor te bereiden op het onverwachte door een noodplan te hebben dat downtime kan verkorten en uw systemen automatisch actief kunnen houden wanneer er iets mislukt.

Wanneer u uw toepassing in de cloud implementeert, kiest u een regio in die cloud waarop uw toepassingsinfrastructuur is gebaseerd. Als uw toepassing is geïmplementeerd in één regio en de regio niet meer beschikbaar is, is uw toepassing ook niet beschikbaar. Dit gebrek aan beschikbaarheid is mogelijk onaanvaardbaar volgens de voorwaarden van de SLA van uw toepassing. Zo ja, dan is het implementeren van uw toepassing en de bijbehorende services in meerdere regio's een goede oplossing.

In deze zelfstudie leert u hoe u een maximaal beschikbare web-app voor meerdere regio's implementeert. Dit scenario wordt eenvoudig gehouden door de toepassingsonderdelen te beperken tot alleen een web-app en Azure Front Door, maar de concepten kunnen worden uitgebreid en toegepast op andere infrastructuurpatronen. Als uw toepassing bijvoorbeeld verbinding maakt met een Azure-databaseaanbieding of opslagaccount, raadpleegt u actieve geo-replicatie voor SQL-databases en redundantieopties voor opslagaccounts. Zie Voor een referentiearchitectuur voor een gedetailleerder scenario de maximaal beschikbare webtoepassing voor meerdere regio's.

In het volgende architectuurdiagram ziet u de infrastructuur die u in deze zelfstudie maakt. Het bestaat uit twee identieke App Services in afzonderlijke regio's, één als de actieve of primaire regio en de andere is de stand-by- of secundaire regio. Azure Front Door wordt gebruikt om verkeer naar de App Services te routeren en toegangsbeperkingen worden geconfigureerd, zodat directe toegang tot de apps vanaf internet wordt geblokkeerd. De stippellijn geeft aan dat verkeer alleen naar de stand-byregio wordt verzonden als de actieve regio uitvalt.

Azure biedt verschillende opties voor taakverdeling en verkeersroutering. Azure Front Door is geselecteerd voor deze use-case omdat het internetgerichte web-apps omvat die worden gehost op Azure-app Service die in meerdere regio's is geïmplementeerd. Zie de beslissingsstructuur voor taakverdeling in Azure om te bepalen wat u moet gebruiken voor uw use-case als deze zelfstudie verschilt.

Architectuurdiagram van een App Service met meerdere regio's.

Met deze architectuur:

Identieke App Service-apps worden geïmplementeerd in twee afzonderlijke regio's.
Openbaar verkeer rechtstreeks naar de App Service-apps wordt geblokkeerd.
Azure Front Door wordt verkeer omgeleid naar de primaire/actieve regio. De secundaire regio heeft een App Service die actief is en zo nodig klaar is om verkeer te verwerken.

Wat u leert:

Maak identieke App Services in afzonderlijke regio's.
Maak Azure Front Door met toegangsbeperkingen die openbare toegang tot App Services blokkeren.

Vereisten

Als u geen Azure-abonnement hebt, kunt u een gratis Azure-account maken voordat u begint.

Vereisten om deze zelfstudie te voltooien:

Gebruik de Bash-omgeving in Azure Cloud Shell. Zie quickstart voor Bash in Azure Cloud Shell voor meer informatie.
Installeer de Azure CLI, indien gewenst, om CLI-referentieopdrachten uit te voeren. Als u in Windows of macOS werkt, kunt u Azure CLI uitvoeren 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 Azure CLI met behulp van de opdracht az login. Volg de stappen die worden weergegeven in de terminal, om het verificatieproces te voltooien. Raadpleeg Aanmelden bij Azure CLI voor aanvullende aanmeldingsopties.
- Installeer de Azure CLI-extensie bij het eerste gebruik, wanneer u hierom wordt gevraagd. Raadpleeg Extensies gebruiken met 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.

Twee instanties van een web-app maken

Voor deze zelfstudie hebt u twee exemplaren nodig van een web-app die in verschillende Azure-regio's wordt uitgevoerd. U gebruikt het regiopaar VS - oost /VS - west als uw twee regio's en maakt twee lege web-apps. Kies indien nodig uw eigen regio's.

Als u het beheer en het opschonen eenvoudiger wilt maken, gebruikt u één resourcegroep voor alle resources in deze zelfstudie. Overweeg om afzonderlijke resourcegroepen te gebruiken voor elke regio/resource om uw resources verder te isoleren in een noodherstelsituatie.

Voer de volgende opdracht uit om uw resourcegroep te maken.

az group create --name myresourcegroup --location eastus

App Service-plannen maken

Voer de volgende opdrachten uit om de App Service-plannen te maken. Vervang de tijdelijke aanduidingen voor <app-service-plan-east-us> en <app-service-plan-west-us> door twee unieke namen, waar u eenvoudig de regio kunt identificeren waarin ze zich bevinden.

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

Web-apps maken

Zodra de App Service-plannen zijn gemaakt, voert u de volgende opdrachten uit om de web-apps te maken. Vervang de tijdelijke aanduidingen voor <web-app-east-us> en <web-app-west-us> door twee globaal unieke namen (geldige tekens zijn a-z, 0-9en -) en let erop dat u rekening moet gehouden met de --plan parameter, zodat u één app in elk plan plaatst (en daarom in elke regio). Vervang de <runtime> parameter door de taalversie van uw app. Uitvoeren az webapp list-runtimes voor de lijst met beschikbare runtimes. Als u van plan bent de voorbeeld-Node.js-app in deze zelfstudie in de volgende secties te gebruiken, gebruikt NODE:18-lts u deze als runtime.

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>

Noteer de standaardhostnaam van elke web-app, zodat u de back-endadressen kunt definiëren wanneer u de Front Door in de volgende stap implementeert. Gebruik hierbij de notatie <web-app-name>.azurewebsites.net. Deze hostnamen zijn te vinden door de volgende opdracht uit te voeren of door te navigeren naar de pagina Overzicht van de app in Azure Portal.

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

Een Azure Front Door maken

Een implementatie met meerdere regio's kan een actief-actief- of actief-passiefconfiguratie gebruiken. Een actief-actief-configuratie distribueert aanvragen over meerdere actieve regio's. Met een actief-passieve configuratie worden exemplaren in de secundaire regio uitgevoerd, maar wordt er geen verkeer verzonden, tenzij de primaire regio uitvalt. Azure Front Door heeft een ingebouwde functie waarmee u deze configuraties kunt inschakelen. Zie Azure-toepassingen ontwerpen voor tolerantie en beschikbaarheid voor meer informatie over het ontwerpen van apps voor hoge beschikbaarheid en fouttolerantie.

Een Azure Front Door-profiel maken

U maakt nu een Azure Front Door Premium om verkeer naar uw apps te routeren.

Voer deze opdracht az afd profile create uit om een Azure Front Door-profiel te maken.

Notitie

Als u Azure Front Door Standard wilt implementeren in plaats van Premium, vervangt u de waarde van de --sku parameter door Standard_AzureFrontDoor. U kunt beheerde regels niet implementeren met WAF-beleid als u de Standard-laag kiest. Zie de vergelijking van de Azure Front Door-laag voor een gedetailleerde vergelijking van de prijscategorieën.

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

Parameter	Weergegeven als	Beschrijving
`profile-name`	`myfrontdoorprofile`	Naam voor het Azure Front Door-profiel, dat uniek is binnen de resourcegroep.
`resource-group`	`myresourcegroup`	De resourcegroep die de resources uit deze zelfstudie bevat.
`sku`	`Premium_AzureFrontDoor`	De prijscategorie van het Azure Front Door-profiel.

Een eindpunt toevoegen

Voer az afd endpoint create deze opdracht uit om een eindpunt in uw profiel te maken. U kunt meerdere eindpunten in uw profiel maken nadat u klaar bent met het maken van de ervaring.

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

Parameter	Weergegeven als	Beschrijving
`endpoint-name`	`myendpoint`	De naam van het eindpunt onder het profiel, dat wereldwijd uniek is.
`enabled-state`	`Enabled`	Of u dit eindpunt wilt inschakelen.

Een oorspronkelijke groep maken

Voer az afd origin-group create deze opdracht uit om een origin-groep te maken die uw twee web-apps bevat.

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	Weergegeven als	Beschrijving
`origin-group-name`	`myorigingroup`	Naam van de oorspronkelijke groep.
`probe-request-type`	`GET`	Het type statustestaanvraag dat wordt gedaan.
`probe-protocol`	`Http`	Protocol dat moet worden gebruikt voor statustest.
`probe-interval-in-seconds`	`60`	Het aantal seconden tussen statustests.
`probe-path`	`/`	Het pad ten opzichte van de oorsprong die wordt gebruikt om de status van de oorsprong te bepalen.
`sample-size`	`4`	Het aantal steekproeven dat moet worden overwogen voor taakverdelingsbeslissingen.
`successful-samples-required`	`3`	Het aantal steekproeven binnen de steekproefperiode die moet slagen.
`additional-latency-in-milliseconds`	`50`	De extra latentie in milliseconden voor tests die in de laagste latentiebucket vallen.

Een oorsprong toevoegen aan de groep

Voer az afd origin create deze opdracht uit om een origin toe te voegen aan uw oorspronkelijke groep. Vervang voor de --host-name parameter de tijdelijke aanduiding voor <web-app-east-us> de naam van uw app in die regio. U ziet dat de --priority parameter is ingesteld op 1, wat aangeeft dat al het verkeer naar uw primaire app wordt verzonden.

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	Weergegeven als	Beschrijving
`host-name`	`<web-app-east-us>.azurewebsites.net`	De hostnaam van de primaire web-app.
`origin-name`	`primaryapp`	Naam van de oorsprong.
`origin-host-header`	`<web-app-east-us>.azurewebsites.net`	De hostheader die moet worden verzonden voor aanvragen naar deze oorsprong. Als u dit leeg laat, bepaalt de hostnaam van de aanvraag deze waarde. Azure CDN-origins, zoals Web Apps, Blob Storage en Cloud Services, vereisen dat deze hostheaderwaarde standaard overeenkomt met de hostnaam van de oorsprong.
`priority`	`1`	Stel deze parameter in op 1 om al het verkeer naar de primaire web-app te leiden.
`weight`	`1000`	Gewicht van de oorsprong in de opgegeven oorsprongsgroep voor taakverdeling. Moet tussen 1 en 1000 zijn.
`enabled-state`	`Enabled`	Of u deze oorsprong wilt inschakelen.
`http-port`	`80`	De poort die wordt gebruikt voor HTTP-aanvragen naar de oorsprong.
`https-port`	`443`	De poort die wordt gebruikt voor HTTPS-aanvragen naar de oorsprong.

Herhaal deze stap om uw tweede oorsprong toe te voegen. Let op de --priority parameter. Voor deze oorsprong is het ingesteld op 2. Met deze prioriteitsinstelling moet Azure Front Door al het verkeer omleiden naar de primaire oorsprong, tenzij de primaire locatie uitvalt. Als u de prioriteit voor deze oorsprong 1instelt op, behandelt Azure Front Door zowel oorsprongen als actief als verkeer naar beide regio's. Zorg ervoor dat u beide exemplaren van de tijdelijke aanduiding vervangt <web-app-west-us> door de naam van die web-app.

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

Een route toevoegen

Voer uit az afd route create om uw eindpunt toe te wijzen aan de oorspronkelijke groep. Met deze route worden aanvragen van het eindpunt doorgestuurd naar uw oorspronkelijke groep.

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	Weergegeven als	Beschrijving
`endpoint-name`	`myendpoint`	Naam van het eindpunt.
forwarding-protocol	MatchRequest	Protocol dat door deze regel wordt gebruikt bij het doorsturen van verkeer naar back-ends.
`route-name`	`route`	Naam van de route.
https-redirect	`Enabled`	Of http-verkeer automatisch moet worden omgeleid naar HTTPS-verkeer.
`supported-protocols`	`Http Https`	Lijst met ondersteunde protocollen voor deze route.
`link-to-default-domain`	`Enabled`	Of deze route is gekoppeld aan het standaardeindpuntdomein.

Wacht ongeveer 15 minuten voordat deze stap is voltooid, omdat het enige tijd duurt voordat deze wijziging wereldwijd wordt doorgegeven. Na deze periode is uw Azure Front Door volledig functioneel.

Toegang tot web-apps beperken tot het Azure Front Door-exemplaar

Op dit moment hebt u nog steeds rechtstreeks toegang tot uw apps met behulp van hun URL's. Om ervoor te zorgen dat verkeer alleen uw apps kan bereiken via Azure Front Door, stelt u toegangsbeperkingen in voor elk van uw apps. De functies van Front Door werken het beste wanneer verkeer alleen door Front Door stroomt. U moet uw origins configureren om verkeer te blokkeren dat nog niet via Front Door wordt verzonden. Anders kan verkeer de firewall van Front Door voor webtoepassingen, DDoS-beveiliging en andere beveiligingsfuncties omzeilen. Verkeer van Azure Front Door naar uw toepassingen is afkomstig van een bekende set IP-bereiken die zijn gedefinieerd in de AzureFrontDoor.Backend servicetag. Met behulp van een regel voor servicetagbeperking kunt u het verkeer beperken tot alleen afkomstig van Azure Front Door.

Voordat u de toegangsbeperkingen voor App Service instelt, moet u rekening houden met de Front Door-id door de volgende opdracht uit te voeren. Deze id is nodig om ervoor te zorgen dat verkeer alleen afkomstig is van uw specifieke Front Door-exemplaar. De toegangsbeperking filtert de binnenkomende aanvragen verder op basis van de unieke HTTP-header die uw Azure Front Door verzendt.

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

Voer de volgende opdrachten uit om de toegangsbeperkingen voor uw web-apps in te stellen. Vervang de tijdelijke aanduiding door <front-door-id> het resultaat van de vorige opdracht. Vervang de tijdelijke aanduidingen voor de app-namen.

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>

De Front Door testen

Wanneer u het Azure Front Door Standard-/Premium-profiel maakt, duurt het enkele minuten voordat de configuratie wereldwijd is geïmplementeerd. Zodra dit is voltooid, hebt u toegang tot de front-endhost die u hebt gemaakt.

Voer deze opdracht uit az afd endpoint show om de hostnaam van het Front Door-eindpunt op te halen.

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

Ga in een browser naar de hostnaam van het eindpunt die de vorige opdracht heeft geretourneerd: <myendpoint>-<hash>.z01.azurefd.net. Uw aanvraag wordt automatisch doorgestuurd naar de primaire app in VS - oost.

Ga als volgende te werk om een directe globale failover te testen:

Open een browser en ga naar de hostnaam van het eindpunt: <myendpoint>-<hash>.z01.azurefd.net.

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

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

Vernieuw de browser. U ziet dezelfde informatiepagina omdat verkeer nu wordt omgeleid naar de actieve app in VS - west.

Tip

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

Stop nu de secundaire app.

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

Vernieuw de browser. Als het goed is, ziet u nu een foutbericht.
Start een van de Web Apps opnieuw door az webapp start uit te voeren. Vernieuw uw browser en u ziet de app opnieuw.
```
az webapp start --name <web-app-east-us> --resource-group myresourcegroup
```

U hebt nu gevalideerd dat u toegang hebt tot uw apps via Azure Front Door en dat failover werkt zoals bedoeld. Start uw andere app opnieuw als u klaar bent met failovertests.

Als u uw toegangsbeperkingen wilt testen en ervoor wilt zorgen dat uw apps alleen kunnen worden bereikt via Azure Front Door, opent u een browser en navigeert u naar de URL's van uw app. Voer de volgende opdrachten uit om de URL's te vinden:

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"

Er wordt een foutpagina weergegeven die aangeeft dat de apps niet toegankelijk zijn.

Resources opschonen

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

az group delete --name myresourcegroup

Het uitvoeren van deze opdracht kan enkele minuten duren.

Implementeren vanuit ARM/Bicep

De resources die u in deze zelfstudie hebt gemaakt, kunnen worden geïmplementeerd met behulp van een ARM/Bicep-sjabloon. Met de bicep-sjabloon voor een maximaal beschikbare web-app voor meerdere regio's kunt u een veilige, maximaal beschikbare end-to-end-oplossing maken met twee web-apps in verschillende regio's achter Azure Front Door.

Zie Resources implementeren met Bicep en Azure CLI voor meer informatie over het implementeren van ARM-/Bicep-sjablonen.

Veelgestelde vragen

In deze zelfstudie tot nu toe hebt u de 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 volgens aanbevolen beveiligingsprocedures en aanbevelingen.

Deze sectie bevat veelgestelde vragen waarmee u uw apps verder kunt beveiligen en uw resources kunt implementeren en beheren met behulp van best practices.

Wat is de aanbevolen methode voor het beheren en implementeren van toepassingsinfrastructuur en Azure-resources?

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, moet de infrastructuur als code (IaC), zoals Azure Resource Manager-sjablonen of Terraform , worden gebruikt met implementatiepijplijnen zoals Azure Pipelines of GitHub Actions. Op deze manier, indien geconfigureerd, worden updates geactiveerd voor alle regio's waarnaar u bent geïmplementeerd. Zie Continue implementatie naar Azure-app Service voor meer informatie.

Hoe kan ik staging-sites gebruiken om een veilige implementatie naar productie te oefenen?

Het rechtstreeks implementeren van uw toepassingscode naar productie-apps/-sites wordt niet aanbevolen. Dit komt doordat u een veilige plek wilt hebben om uw apps te testen en wijzigingen te valideren die u aanbrengt voordat u naar productie pusht. Gebruik een combinatie van staging-sites en sitewisselingen om code van uw testomgeving naar productie te verplaatsen.

U hebt al de basislijninfrastructuur voor dit scenario gemaakt. Nu maakt u implementatiesites voor elk exemplaar van uw app en configureert u continue implementatie naar 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 synchroon zijn. Als u continue implementatie niet configureert, moet u elke app in elke regio handmatig bijwerken telkens wanneer er een codewijziging is.

Voor de resterende stappen in deze zelfstudie moet u een app hebben die klaar is voor implementatie in uw App Services. Als u een voorbeeld-app nodig hebt, kunt u de Node.js Hallo wereld voorbeeld-app gebruiken. Fork die opslagplaats zodat u uw eigen kopie hebt.

Zorg ervoor dat u de App Service-stackinstellingen voor uw apps instelt. Stack-instellingen verwijzen naar de taal of runtime die wordt gebruikt voor uw app. Deze instelling kan worden geconfigureerd met behulp van de Azure CLI met de az webapp config set opdracht of in de portal met de volgende stappen. Als u het Node.js voorbeeld gebruikt, stelt u de stackinstellingen in op Node 18 LTS.

Ga naar uw app en selecteer Configuratie in de inhoudsopgave aan de linkerkant.
Selecteer het tabblad Algemene instellingen.
Kies onder Stack-instellingen de juiste waarde voor uw app.
Selecteer Opslaan en vervolgens Doorgaan om de update te bevestigen.
Herhaal deze stappen voor uw andere apps.

Voer de volgende opdrachten uit om faseringssites met de naam 'fase' te maken voor elk van uw apps. Vervang de tijdelijke aanduidingen voor <web-app-east-us> en <web-app-west-us> door uw app-namen.

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>

Als u continue implementatie wilt instellen, moet u Azure Portal gebruiken. Zie Continue implementatie voor Azure-app Service voor gedetailleerde richtlijnen over het configureren van continue implementatie met providers zoals GitHub Actions.

Als u continue implementatie wilt configureren met GitHub Actions, voert u de volgende stappen uit voor elk van uw staging-sites.

Ga in Azure Portal naar de beheerpagina voor een van uw App Service-app-sites.
Selecteer Implementatiecentrum in het linkerdeelvenster. Selecteer vervolgens Instellingen.
Selecteer 'GitHub' in het vak Bron in de CI/CD-opties:
Als u voor het eerst vanuit GitHub implementeert, selecteert u Autoriseren en volgt u de autorisatieprompts. Als u wilt implementeren vanuit de opslagplaats van een andere gebruiker, selecteert u Account wijzigen.
Nadat u uw Azure-account hebt geautoriseerd met GitHub, selecteert u de organisatie, opslagplaats en vertakking om CI/CD voor te configureren. Als u een organisatie of opslagplaats niet kunt vinden, moet u mogelijk meer machtigingen inschakelen op GitHub. Zie Toegang tot de opslagplaatsen van uw organisatie beheren voor meer informatie.
1. Als u de Node.js voorbeeld-app gebruikt, gebruikt u de volgende instellingen.
  
  Instelling Weergegeven als
  
  Organisatie <your-GitHub-organization>
  
  Opslagplaats nodejs-docs-hello-world
  
  Vertakking main
Selecteer Opslaan.

Nieuwe doorvoeringen in de geselecteerde opslagplaats en vertakking worden nu continu geïmplementeerd in uw App Service-app-site. U kunt de doorvoeringen en implementaties bijhouden op het tabblad Logboeken .

Instelling	Weergegeven als
Organisatie	`<your-GitHub-organization>`
Opslagplaats	nodejs-docs-hello-world
Vertakking	main

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.

Hoe kan ik basisverificatie uitschakelen in App Service?

Overweeg basisverificatie uit te schakelen, waardoor de toegang tot de FTP- en SCM-eindpunten wordt beperkt tot gebruikers die worden ondersteund door Microsoft Entra-id. Als u een hulpprogramma voor continue implementatie gebruikt om de broncode van uw toepassing te implementeren, zijn voor het uitschakelen van basisverificatie extra stappen vereist voor het configureren van continue implementatie. 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 gebruiken.

Als u basisverificatie voor uw App Service wilt uitschakelen, voert u de volgende opdrachten uit voor elke app en site door de tijdelijke aanduidingen voor <web-app-east-us> en <web-app-west-us> door uw app-namen te vervangen. Met de eerste set opdrachten wordt FTP-toegang voor de productiesites en faseringssites uitgeschakeld. Met de tweede set opdrachten wordt basisverificatietoegang tot de WebDeploy-poort en SCM-site voor de productiesites en staging-sites uitgeschakeld.

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

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

Hoe kan ik mijn code implementeren met behulp van continue implementatie als ik basisverificatie heb uitgeschakeld?

Als u ervoor kiest om basisverificatie toe te staan voor uw App Service-apps, kunt u een van de beschikbare implementatiemethoden in App Service gebruiken, inclusief het publicatieprofiel dat is geconfigureerd in de sectie staging-sites .

Als u basisverificatie voor uw App Services uitschakelt, is voor continue implementatie een service-principal of OpenID Connect vereist voor verificatie. Als u GitHub Actions als uw codeopslagplaats gebruikt, raadpleegt u de stapsgewijze zelfstudie voor het gebruik van een service-principal of OpenID Connect voor implementatie in App Service met behulp van GitHub Actions of voert u de stappen in de volgende sectie uit.

De service-principal maken en referenties configureren met GitHub Actions

Gebruik de volgende stappen om continue implementatie te configureren met GitHub Actions en een service-principal.

Voer de volgende opdracht uit om de service-principal te maken. Vervang de tijdelijke aanduidingen door uw <subscription-id> en app-namen. De uitvoer is een JSON-object met de roltoewijzingsreferenties die toegang bieden tot uw App Service-apps. Kopieer dit JSON-object voor de volgende stap. Het bevat uw clientgeheim, dat op dit moment alleen zichtbaar is. Het is altijd een goede gewoonte om minimale toegang te verlenen. Het bereik in dit voorbeeld is beperkt tot alleen de apps, niet de hele resourcegroep.
```
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
```
U moet de referenties van uw service-principal opgeven voor de Azure-/aanmeldingsactie als onderdeel van de GitHub Action-werkstroom die u gebruikt. Deze waarden kunnen rechtstreeks in de werkstroom worden opgegeven of kunnen worden opgeslagen in GitHub-geheimen en waarnaar wordt verwezen in uw werkstroom. Het opslaan van de waarden als GitHub-geheimen is de veiligere optie.
1. Open uw GitHub-opslagplaats en ga naar Beveiligingsgeheimen>>en variabelenacties voor instellingen>
2. Selecteer Nieuw opslagplaatsgeheim en maak een geheim voor elk van de volgende waarden. De waarden vindt u in de json-uitvoer die u eerder hebt gekopieerd.
  
  Naam Weergegeven als
  
  AZURE_APP_ID <application/client-id>
  
  AZURE_PASSWORD <client-secret>
  
  AZURE_TENANT_ID <tenant-id>
  
  AZURE_SUBSCRIPTION_ID <subscription-id>

Naam	Weergegeven als
AZURE_APP_ID	`<application/client-id>`
AZURE_PASSWORD	`<client-secret>`
AZURE_TENANT_ID	`<tenant-id>`
AZURE_SUBSCRIPTION_ID	`<subscription-id>`

De GitHub Actions-werkstroom maken

Nu u een service-principal hebt die toegang heeft tot uw App Service-apps, bewerkt u de standaardwerkstromen die voor uw apps zijn gemaakt toen u continue implementatie hebt geconfigureerd. Verificatie moet worden uitgevoerd met behulp van uw service-principal in plaats van het publicatieprofiel. Zie het tabblad Service-principal in Het werkstroombestand toevoegen aan uw GitHub-opslagplaats voor voorbeeldwerkstromen. De volgende voorbeeldwerkstroom kan worden gebruikt voor de Node.js voorbeeld-app die is opgegeven.

Open de GitHub-opslagplaats van uw app en ga naar de <repo-name>/.github/workflows/ map. U ziet nu de automatisch gegenereerde werkstromen.

Selecteer voor elk werkstroombestand de knop Potlood in de rechterbovenhoek om het bestand te bewerken. Vervang de inhoud door de volgende tekst. Hierbij wordt ervan uitgegaan dat u de GitHub-geheimen eerder hebt gemaakt voor uw referentie. Werk de tijdelijke aanduiding voor <web-app-name> onder de sectie env bij en voer deze vervolgens rechtstreeks door naar de hoofdvertakking. Deze doorvoering activeert de GitHub-actie om opnieuw uit te voeren en uw code te implementeren, deze keer met behulp van de service-principal om te verifiëren.


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

Hoe kan ik met siteverkeersroutering updates testen die ik aan mijn apps aanbrengt?

Met verkeersroutering met sites kunt u een vooraf gedefinieerd gedeelte van uw gebruikersverkeer naar elke site leiden. In eerste instantie wordt 100% van het verkeer omgeleid naar de productiesite. U hebt echter de mogelijkheid om 10% van uw verkeer naar uw staging-site te verzenden. Als u siteverkeerroutering op deze manier configureert, worden 10% van hen automatisch doorgestuurd naar de staging-site zonder wijzigingen in uw Front Door-exemplaar wanneer gebruikers toegang proberen te krijgen tot uw app. Zie Faseringsomgevingen instellen in Azure-app Service voor meer informatie over sitewisselingen en faseringsomgevingen in App Service.

Hoe kan ik mijn code van mijn staging-site naar mijn productiesite verplaatsen?

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

Voer de volgende opdracht uit voor elke app om de wissel uit te voeren. Vervang de tijdelijke aanduiding voor <web-app-name>.

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

Na enkele minuten kunt u naar het eindpunt van uw Front Door navigeren om te controleren of de wisseling van de site is geslaagd.

Op dit moment zijn uw apps actief en worden wijzigingen die u aanbrengt in de broncode van uw toepassing automatisch een update naar beide staging-sites geactiveerd. U kunt vervolgens het proces voor het wisselen van sites herhalen wanneer u klaar bent om die code naar productie te verplaatsen.

Hoe kan ik Azure Front Door nog meer gebruiken in mijn implementaties in meerdere regio's?

Als u zich zorgen maakt over mogelijke onderbrekingen of problemen met continuïteit in verschillende regio's, zoals bij sommige klanten die één versie van uw app zien terwijl anderen een andere versie zien, of als u belangrijke wijzigingen aanbrengt in uw apps, kunt u de site die de site ondergaat die de site overgaat, tijdelijk verwijderen uit de oorspronkelijke groep van uw Front Door. Al het verkeer wordt vervolgens omgeleid naar de andere oorsprong. Navigeer naar het deelvenster Origin-groep Bijwerken en Verwijder de oorsprong die de wijziging ondergaat. Zodra u al uw wijzigingen hebt aangebracht en er weer klaar voor bent om verkeer daar te verwerken, kunt u teruggaan naar hetzelfde deelvenster en + Een oorsprong toevoegen om de oorsprong te lezen.

Schermopname die laat zien hoe u een Azure Front Door-oorsprong verwijdert.

Als u liever geen origins wilt verwijderen en vervolgens wilt lezen, kunt u extra origin-groepen maken voor uw Front Door-exemplaar. Vervolgens kunt u de route koppelen aan de oorspronkelijke groep die verwijst naar de beoogde oorsprong. U kunt bijvoorbeeld twee nieuwe oorspronkelijke groepen maken, één voor uw primaire regio en één voor uw secundaire regio. Wanneer uw primaire regio een wijziging ondergaat, koppelt u de route aan uw secundaire regio en vice versa wanneer uw secundaire regio een wijziging ondergaat. Wanneer alle wijzigingen zijn voltooid, kunt u de route koppelen aan de oorspronkelijke oorspronkelijke oorspronkelijke groep die beide regio's bevat. Deze methode werkt omdat een route slechts kan worden gekoppeld aan één oorspronkelijke groep tegelijk.

Als u wilt laten zien hoe u met meerdere origins werkt, zijn er in de volgende schermopname drie oorsprongsgroepen. 'MyOriginGroup' bestaat uit beide web-apps en de andere twee oorspronkelijke groepen bestaan uit de web-app in hun respectieve regio. In het voorbeeld ondergaat de app in de primaire regio een wijziging. Voordat deze wijziging werd gestart, werd de route gekoppeld aan 'MySecondaryRegion' zodat al het verkeer tijdens de wijzigingsperiode naar de app in de secundaire regio zou worden verzonden. U kunt de route bijwerken door Niet-gekoppeld te selecteren, zodat het deelvenster Routes koppelen wordt weergegeven.

Schermopname van het koppelen van routes aan Azure Front Door.

Hoe kan ik de 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 implementatiesites gebruikt, kunt u voor productiesites met name de toegang tot de SCM-site weigeren, omdat uw tests en validatie wordt uitgevoerd met uw staging-sites.

Volgende stappen

Een maximaal beschikbare web-app voor meerdere regio's implementeren

Maximaal beschikbare zone-redundante webtoepassing

Delen via