Esercitazione: Creare un'app multi-area a disponibilità elevata nel servizio app Azure
La disponibilità elevata e la tolleranza di errore sono componenti chiave di una soluzione ben progettata. È consigliabile prepararsi per l'imprevisto avendo un piano di emergenza che può ridurre i tempi di inattività e mantenere i sistemi operativi automaticamente quando si verifica un errore.
Quando si distribuisce l'applicazione nel cloud, si sceglie un'area nel cloud in cui si basa l'infrastruttura dell'applicazione. Se l'applicazione viene distribuita in una singola area e l'area non è più disponibile, l'applicazione non sarà disponibile. Questa mancanza di disponibilità potrebbe essere inaccettabile in base ai termini del contratto di servizio dell'applicazione. In tal caso, la distribuzione dell'applicazione e dei relativi servizi in più aree è una buona soluzione.
Questa esercitazione illustra come distribuire un'app Web multi-area a disponibilità elevata. Questo scenario viene mantenuto semplice limitando i componenti dell'applicazione solo a un'app Web e a Frontdoor di Azure, ma i concetti possono essere espansi e applicati ad altri modelli di infrastruttura. Ad esempio, se l'applicazione si connette a un'offerta di database di Azure o a un account di archiviazione, vedere La replica geografica attiva per i database SQL e le opzioni di ridondanza per gli account di archiviazione. Per un'architettura di riferimento per uno scenario più dettagliato, vedere Applicazione Web multi-area a disponibilità elevata.
Il diagramma dell'architettura seguente illustra l'infrastruttura creata in questa esercitazione. È costituito da due servizio app identiche in aree separate, una è l'area attiva o primaria e l'altra è l'area di standby o secondaria. Frontdoor di Azure viene usato per instradare il traffico alle servizio app e le restrizioni di accesso sono configurate in modo che l'accesso diretto alle app da Internet venga bloccato. La linea tratteggiata indica che il traffico viene inviato all'area di standby solo se l'area attiva diventa inattiva.
Azure offre varie opzioni per il bilanciamento del carico e il routing del traffico. Frontdoor di Azure è stato selezionato per questo caso d'uso perché implica app Web con connessione Internet ospitate in app Azure Servizio distribuito in più aree. Per decidere cosa usare per il caso d'uso se è diverso da questa esercitazione, vedere l'albero delle decisioni per il bilanciamento del carico in Azure.
Con questa architettura:
- Le app di servizio app identiche vengono distribuite in due aree separate.
- Il traffico pubblico direttamente verso le app servizio app è bloccato.
- Frontdoor di Azure viene usato per instradare il traffico all'area primaria/attiva. L'area secondaria ha un servizio app in esecuzione e pronto per gestire il traffico, se necessario.
Contenuto dell'esercitazione:
- Creare servizio app identiche in aree separate.
- Creare Frontdoor di Azure con restrizioni di accesso che bloccano l'accesso pubblico alle servizio app.
Prerequisiti
Se non si ha una sottoscrizione di Azure, creare un account Azure gratuito prima di iniziare.
Per completare questa esercitazione:
Usare l'ambiente Bash in Azure Cloud Shell. Per altre informazioni, vedere Avvio rapido per Bash in Azure Cloud Shell.
Se si preferisce eseguire i comandi di riferimento dell'interfaccia della riga di comando in locale, installare l'interfaccia della riga di comando di Azure. Per l'esecuzione in Windows o macOS, è consigliabile eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker. Per altre informazioni, vedere Come eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker.
Se si usa un'installazione locale, accedere all'interfaccia della riga di comando di Azure con il comando az login. Per completare il processo di autenticazione, seguire la procedura visualizzata nel terminale. Per altre opzioni di accesso, vedere Accedere con l'interfaccia della riga di comando di Azure.
Quando richiesto, installare l'estensione dell'interfaccia della riga di comando di Azure al primo uso. Per altre informazioni sulle estensioni, vedere Usare le estensioni con l'interfaccia della riga di comando di Azure.
Eseguire az version per trovare la versione e le librerie dipendenti installate. Per eseguire l'aggiornamento alla versione più recente, eseguire az upgrade.
Creare due istanze di un'app Web
Per questa esercitazione sono necessarie due istanze di un'app Web che vengono eseguite in aree di Azure diverse. Usare la coppia di aree Stati Uniti orientali/Stati Uniti occidentali come due aree e creare due app Web vuote. Se necessario, è possibile scegliere le proprie aree.
Per semplificare la gestione e la pulizia, usare un singolo gruppo di risorse per tutte le risorse in questa esercitazione. Prendere in considerazione l'uso di gruppi di risorse separati per ogni area o risorsa per isolare ulteriormente le risorse in una situazione di ripristino di emergenza.
Eseguire il comando seguente per creare il gruppo di risorse.
az group create --name myresourcegroup --location eastus
Creare piani di servizio app
Eseguire i comandi seguenti per creare i piani di servizio app. Sostituire i segnaposto per <app-service-plan-east-us> e <app-service-plan-west-us> con due nomi univoci in cui è possibile identificare facilmente l'area in cui si trovano.
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
Creare app Web
Dopo aver creato i piani di servizio app, eseguire i comandi seguenti per creare le app Web. Sostituire i segnaposto per <web-app-east-us> e <web-app-west-us> con due nomi univoci globali (i caratteri validi sono a-z, 0-9e -) e assicurarsi di prestare attenzione al --plan parametro in modo da inserire un'app in ogni piano (e quindi in ogni area). Sostituire il <runtime> parametro con la versione della lingua dell'app. Eseguire az webapp list-runtimes per l'elenco dei runtime disponibili. Se si prevede di usare l'app di esempio Node.js fornita in questa esercitazione nelle sezioni seguenti, usare NODE:18-lts come 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>
Prendere nota del nome host predefinito di ogni app Web in modo da poter definire gli indirizzi back-end quando si distribuisce Frontdoor nel passaggio successivo. Deve essere nel formato <web-app-name>.azurewebsites.net. Questi nomi host sono disponibili eseguendo il comando seguente o passando alla pagina Panoramica dell'app nel portale di Azure.
az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"
Creare un servizio Frontdoor di Azure
Una distribuzione in più aree può usare una configurazione attiva-attiva o attiva-passiva. Una configurazione attiva-attiva distribuisce le richieste tra più aree attive. Una configurazione attiva-passiva mantiene le istanze in esecuzione nell'area secondaria, ma non invia il traffico a meno che l'area primaria non riesca. Frontdoor di Azure include una funzionalità predefinita che consente di abilitare queste configurazioni. Per altre informazioni sulla progettazione di app per la disponibilità elevata e la tolleranza di errore, vedere Progettare applicazioni di Azure per la resilienza e la disponibilità.
Creare un profilo frontdoor di Azure
È ora possibile creare un'istanza di Frontdoor di Azure Premium per instradare il traffico alle app.
Eseguire az afd profile create per creare un profilo frontdoor di Azure.
Nota
Se si vuole distribuire Frontdoor di Azure Standard anziché Premium, sostituire il valore del --sku parametro con Standard_AzureFrontDoor. Non è possibile distribuire regole gestite con criteri WAF se si sceglie il livello Standard. Per un confronto dettagliato dei piani tariffari, vedere Confronto tra i livelli di Frontdoor di Azure.
az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
| Parametro | valore | Descrizione |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nome del profilo frontdoor di Azure, univoco all'interno del gruppo di risorse. |
resource-group |
myresourcegroup |
Gruppo di risorse che contiene le risorse di questa esercitazione. |
sku |
Premium_AzureFrontDoor |
Piano tariffario del profilo frontdoor di Azure. |
Aggiungi un endpoint
Eseguire az afd endpoint create per creare un endpoint nel profilo. È possibile creare più endpoint nel profilo dopo aver completato l'esperienza di creazione.
az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parametro | valore | Descrizione |
|---|---|---|
endpoint-name |
myendpoint |
Nome dell'endpoint nel profilo, univoco a livello globale. |
enabled-state |
Enabled |
Indica se abilitare questo endpoint. |
Creare un gruppo di origine
Eseguire az afd origin-group create per creare un gruppo di origine contenente le due app Web.
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
| Parametro | valore | Descrizione |
|---|---|---|
origin-group-name |
myorigingroup |
Nome del gruppo di origine. |
probe-request-type |
GET |
Tipo di richiesta probe di integrità effettuata. |
probe-protocol |
Http |
Protocollo da usare per il probe di integrità. |
probe-interval-in-seconds |
60 |
Il numero di secondi tra probe di integrità. |
probe-path |
/ |
Percorso relativo all'origine utilizzata per determinare l'integrità dell'origine. |
sample-size |
4 |
Il numero di campioni da considerare per le decisioni di bilanciamento del carico. |
successful-samples-required |
3 |
Numero di campioni entro il periodo di campionamento che deve avere esito positivo. |
additional-latency-in-milliseconds |
50 |
La latenza aggiuntiva in millisecondi per i probe rientra nel bucket di latenza più bassa. |
Aggiungere un'origine al gruppo
Eseguire az afd origin create per aggiungere un'origine al gruppo di origine. Per il --host-name parametro sostituire il segnaposto per <web-app-east-us> con il nome dell'app in tale area. Si noti che il --priority parametro è impostato su 1, che indica che tutto il traffico viene inviato all'app primaria.
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
| Parametro | valore | Descrizione |
|---|---|---|
host-name |
<web-app-east-us>.azurewebsites.net |
Nome host dell'app Web primaria. |
origin-name |
primaryapp |
Nome dell'origine. |
origin-host-header |
<web-app-east-us>.azurewebsites.net |
Intestazione host da inviare per le richieste a questa origine. Se si lascia vuoto questo valore, il nome host della richiesta determina questo valore. Rete CDN di Azure origini, ad esempio App Web, Archiviazione BLOB e Servizi cloud richiedono che questo valore dell'intestazione host corrisponda al nome host di origine per impostazione predefinita. |
priority |
1 |
Impostare questo parametro su 1 per indirizzare tutto il traffico all'app Web primaria. |
weight |
1000 |
Peso dell'origine nel gruppo di origine specificato per il bilanciamento del carico. Deve essere compreso tra 1 e 1000. |
enabled-state |
Enabled |
Indica se abilitare l'origine. |
http-port |
80 |
Porta usata per le richieste HTTP all'origine. |
https-port |
443 |
Porta usata per le richieste HTTPS all'origine. |
Ripetere questo passaggio per aggiungere la seconda origine. Prestare attenzione al --priority parametro . Per questa origine, è impostato su 2. Questa impostazione di priorità indica a Frontdoor di Azure di indirizzare tutto il traffico all'origine primaria, a meno che il database primario non si arresti. Se si imposta la priorità per questa origine su 1, Frontdoor di Azure considera entrambe le origini come attive e indirizza il traffico a entrambe le aree. Assicurarsi di sostituire entrambe le istanze del segnaposto per <web-app-west-us> con il nome dell'app Web.
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
Aggiungere una route
Eseguire az afd route create per eseguire il mapping dell'endpoint al gruppo di origine. Questa route inoltra le richieste dall'endpoint al gruppo di origine.
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
| Parametro | valore | Descrizione |
|---|---|---|
endpoint-name |
myendpoint |
Nome dell'endpoint. |
| forwarding-protocol | MatchRequest | Protocollo usato da questa regola per l'inoltro del traffico ai back-end. |
route-name |
route |
Nome della route. |
| https-redirect | Enabled |
Indica se reindirizzare automaticamente il traffico HTTP al traffico HTTPS. |
supported-protocols |
Http Https |
Elenco dei protocolli supportati per questa route. |
link-to-default-domain |
Enabled |
Indica se questa route è collegata al dominio endpoint predefinito. |
Attendere circa 15 minuti per il completamento di questo passaggio perché la propagazione globale di questa modifica richiede tempo. Dopo questo periodo, frontdoor di Azure è completamente funzionante.
Limitare l'accesso alle app Web all'istanza di Frontdoor di Azure
A questo punto, è comunque possibile accedere alle app direttamente usando gli URL. Per garantire che il traffico possa raggiungere solo le app tramite Frontdoor di Azure, è necessario impostare restrizioni di accesso per ognuna delle app. Le funzionalità di Frontdoor funzionano meglio quando il traffico passa solo attraverso Frontdoor. È consigliabile configurare le origini per bloccare il traffico che non viene ancora inviato tramite Frontdoor. In caso contrario, il traffico potrebbe ignorare il web application firewall di Frontdoor, la protezione DDoS e altre funzionalità di sicurezza. Il traffico da Frontdoor di Azure alle applicazioni ha origine da un set noto di intervalli IP definiti nel tag del AzureFrontDoor.Backend servizio. Usando una regola di restrizione dei tag di servizio, è possibile limitare il traffico solo da Frontdoor di Azure.
Prima di configurare le restrizioni di accesso servizio app, prendere nota dell'ID frontdoor eseguendo il comando seguente. Questo ID è necessario per garantire che il traffico provenga solo dall'istanza di Frontdoor specifica. La restrizione di accesso filtra ulteriormente le richieste in ingresso in base all'intestazione HTTP univoca inviata da Frontdoor di Azure.
az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"
Eseguire i comandi seguenti per impostare le restrizioni di accesso nelle app Web. Sostituire il segnaposto per <front-door-id> con il risultato del comando precedente. Sostituire i segnaposto per i nomi dell'app.
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>
Testare l'istanza di Frontdoor
Quando si crea il profilo Frontdoor di Azure Standard/Premium, la distribuzione globale della configurazione richiede alcuni minuti. Al termine, è possibile accedere all'host front-end creato.
Eseguire az afd endpoint show per ottenere il nome host dell'endpoint frontdoor.
az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
In un browser passare al nome host dell'endpoint restituito dal comando precedente: <myendpoint>-<hash>.z01.azurefd.net. La richiesta dovrebbe essere indirizzata automaticamente all'app primaria negli Stati Uniti orientali.
Per testare il failover globale istantaneo:
Aprire un browser e passare al nome host dell'endpoint:
<myendpoint>-<hash>.z01.azurefd.net.Arrestare l'app primaria eseguendo az webapp stop.
az webapp stop --name <web-app-east-us> --resource-group myresourcegroupAggiorna il browser. Dovrebbe essere visualizzata la stessa pagina di informazioni perché il traffico è ora indirizzato all'app in esecuzione negli Stati Uniti occidentali.
Suggerimento
Potrebbe essere necessario aggiornare la pagina alcune volte per il completamento del failover.
Arrestare ora l'app secondaria.
az webapp stop --name <web-app-west-us> --resource-group myresourcegroupAggiorna il browser. Questa volta dovrebbe essere visualizzato un messaggio di errore.
Riavviare una delle App Web eseguendo az webapp start. Aggiornare il browser e dovrebbe essere visualizzata di nuovo l'app.
az webapp start --name <web-app-east-us> --resource-group myresourcegroup
A questo punto è stato convalidato che è possibile accedere alle app tramite Frontdoor di Azure e che il failover funziona come previsto. Riavviare l'altra app se il test di failover è stato completato.
Per testare le restrizioni di accesso e assicurarsi che le app possano essere raggiunte solo tramite Frontdoor di Azure, aprire un browser e passare a ognuno degli URL dell'app. Per trovare gli URL, eseguire i comandi seguenti:
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"
Verrà visualizzata una pagina di errore che indica che le app non sono accessibili.
Pulire le risorse
Nei passaggi precedenti sono state create risorse di Azure in un gruppo di risorse. Se si ritiene che queste risorse non saranno necessarie in futuro, eliminare il gruppo di risorse eseguendo questo comando in Cloud Shell.
az group delete --name myresourcegroup
L'esecuzione del comando può impiegare alcuni minuti.
Eseguire la distribuzione da ARM/Bicep
Le risorse create in questa esercitazione possono essere distribuite usando un modello ARM/Bicep. Il modello Bicep dell'app Web multi-area a disponibilità elevata consente di creare una soluzione end-to-end sicura e a disponibilità elevata con due app Web in aree diverse dietro Frontdoor di Azure.
Per informazioni su come distribuire modelli ARM/Bicep, vedere Come distribuire le risorse con Bicep e l'interfaccia della riga di comando di Azure.
Domande frequenti
In questa esercitazione finora è stata distribuita l'infrastruttura di base per abilitare un'app Web in più aree. servizio app offre funzionalità che consentono di assicurarsi di eseguire applicazioni seguendo le procedure consigliate e le raccomandazioni per la sicurezza.
Questa sezione contiene domande frequenti che consentono di proteggere ulteriormente le app e distribuire e gestire le risorse usando le procedure consigliate.
Qual è il metodo consigliato per la gestione e la distribuzione dell'infrastruttura dell'applicazione e delle risorse di Azure?
Per questa esercitazione è stata usata l'interfaccia della riga di comando di Azure per distribuire le risorse dell'infrastruttura. Valutare la possibilità di configurare un meccanismo di distribuzione continua per gestire l'infrastruttura dell'applicazione. Poiché si distribuiscono risorse in aree diverse, è necessario gestire in modo indipendente tali risorse tra le aree. Per garantire che le risorse siano identiche in ogni area, è necessario usare l'infrastruttura come codice (IaC), ad esempio i modelli di Azure Resource Manager o Terraform , con pipeline di distribuzione come Azure Pipelines o GitHub Actions. In questo modo, se configurata in modo appropriato, qualsiasi modifica alle risorse attiverà gli aggiornamenti in tutte le aree in cui viene distribuita. Per altre informazioni, vedere Distribuzione continua nel servizio app Azure.
Come è possibile usare gli slot di staging per praticare la distribuzione sicura nell'ambiente di produzione?
La distribuzione del codice dell'applicazione direttamente nelle app/slot di produzione non è consigliata. Ciò è dovuto al fatto che si vuole avere un luogo sicuro per testare le app e convalidare le modifiche apportate prima del push nell'ambiente di produzione. Usare una combinazione di slot di staging e scambio di slot per spostare il codice dall'ambiente di test all'ambiente di produzione.
È già stata creata l'infrastruttura di base per questo scenario. A questo scopo, è possibile creare slot di distribuzione per ogni istanza dell'app e configurare la distribuzione continua in questi slot di staging con GitHub Actions. Come per la gestione dell'infrastruttura, è anche consigliabile configurare la distribuzione continua per il codice sorgente dell'applicazione per garantire che le modifiche tra le aree siano sincronizzate. Se non si configura la distribuzione continua, è necessario aggiornare manualmente ogni app in ogni area ogni volta che si verifica una modifica del codice.
Per i passaggi rimanenti di questa esercitazione, è necessario avere un'app pronta per la distribuzione nelle servizio app. Se è necessaria un'app di esempio, è possibile usare l'app di esempio Node.js Hello World. Creare una copia tramite fork del repository in modo che sia disponibile una copia personalizzata.
Assicurarsi di impostare le impostazioni dello stack di servizio app per le app. Le impostazioni dello stack fanno riferimento al linguaggio o al runtime usato per l'app. Questa impostazione può essere configurata usando l'interfaccia della riga di comando di Azure con il az webapp config set comando o nel portale con la procedura seguente. Se si usa l'esempio di Node.js, impostare le impostazioni dello stack su Node 18 LTS.
- Passare all'app e selezionare Configurazione nel sommario a sinistra.
- Seleziona la scheda Impostazioni generali.
- In Impostazioni stack scegliere il valore appropriato per l'app.
- Selezionare Salva e quindi Continua per confermare l'aggiornamento.
- Ripetere questi passaggi per le altre app.
Eseguire i comandi seguenti per creare slot di staging denominati "stage" per ognuna delle app. Sostituire i segnaposto per <web-app-east-us> e <web-app-west-us> con i nomi delle app.
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>
Per configurare la distribuzione continua, è necessario usare il portale di Azure. Per indicazioni dettagliate su come configurare la distribuzione continua con provider come GitHub Actions, vedere Distribuzione continua nel servizio app Azure.
Per configurare la distribuzione continua con GitHub Actions, completare i passaggi seguenti per ognuno degli slot di staging.
Nella portale di Azure passare alla pagina di gestione per uno degli slot dell'app servizio app.
Nel riquadro sinistro selezionare Centro distribuzione. Selezionare quindi Impostazioni.
Nella casella Origine selezionare "GitHub" nelle opzioni CI/CD:
Se si esegue la distribuzione da GitHub per la prima volta, selezionare Autorizza e seguire le istruzioni di autorizzazione. Se si vuole eseguire la distribuzione da un repository utente diverso, selezionare Cambia account.
Dopo aver autorizzato l'account Azure con GitHub, selezionare l'organizzazione, il repository e il ramo per cui configurare CI/CD. Se non è possibile trovare un'organizzazione o un repository, potrebbe essere necessario abilitare altre autorizzazioni in GitHub. Per altre informazioni, vedere Gestione dell'accesso ai repository dell'organizzazione.
Se si usa l'app di esempio Node.js, usare le impostazioni seguenti.
Impostazione Valore Organization <your-GitHub-organization>Repository nodejs-docs-hello-world Filiale main
Seleziona Salva.
I nuovi commit nel repository selezionato e nel ramo vengono ora distribuiti continuamente nello slot dell'app servizio app. È possibile tenere traccia dei commit e delle distribuzioni nella scheda Log .
Un file del flusso di lavoro predefinito che usa un profilo di pubblicazione per l'autenticazione per servizio app viene aggiunto al repository GitHub. È possibile visualizzare questo file passando alla <repo-name>/.github/workflows/ directory .
Ricerca per categorie disabilitare l'autenticazione di base in servizio app?
Valutare la possibilità di disabilitare l'autenticazione di base, che limita l'accesso agli endpoint FTP e SCM agli utenti supportati da Microsoft Entra ID. Se si usa uno strumento di distribuzione continua per distribuire il codice sorgente dell'applicazione, la disabilitazione dell'autenticazione di base richiede passaggi aggiuntivi per configurare la distribuzione continua. Ad esempio, non è possibile usare un profilo di pubblicazione perché non usa le credenziali di Microsoft Entra. È invece necessario usare un'entità servizio o un Connessione OpenID.
Per disabilitare l'autenticazione di base per il servizio app, eseguire i comandi seguenti per ogni app e slot sostituendo i segnaposto per <web-app-east-us> e <web-app-west-us> con i nomi dell'app. Il primo set di comandi disabilita l'accesso FTP per i siti di produzione e gli slot di staging e il secondo set di comandi disabilita l'accesso di autenticazione di base alla porta WebDeploy e al sito SCM per i siti di produzione e gli slot di staging.
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
Per altre informazioni sulla disabilitazione dell'autenticazione di base, tra cui come testare e monitorare gli accessi, vedere Disabilitare l'autenticazione di base nelle distribuzioni di servizio app.
Ricerca per categorie distribuire il codice usando la distribuzione continua se è stata disabilitata l'autenticazione di base?
Se si sceglie di consentire l'autenticazione di base nelle app servizio app, è possibile usare uno dei metodi di distribuzione disponibili in servizio app, incluso l'uso del profilo di pubblicazione configurato nella sezione Slot di staging.
Se si disabilita l'autenticazione di base per i servizio app, la distribuzione continua richiede un'entità servizio o un Connessione OpenID per l'autenticazione. Se si usa GitHub Actions come repository di codice, vedere l'esercitazione dettagliata per l'uso di un'entità servizio o un Connessione OpenID per la distribuzione in servizio app usando GitHub Actions o completare i passaggi descritti nella sezione seguente.
Creare l'entità servizio e configurare le credenziali con GitHub Actions
Per configurare la distribuzione continua con GitHub Actions e un'entità servizio, seguire questa procedura.
Eseguire il comando seguente per creare l'entità servizio. Sostituire i segnaposto con
<subscription-id>i nomi dell'app e . L'output è un oggetto JSON con le credenziali di assegnazione di ruolo che forniscono l'accesso alle app servizio app. Copiare questo oggetto JSON per il passaggio successivo. Include il segreto client, che è visibile solo in questo momento. È sempre consigliabile concedere l'accesso minimo. L'ambito in questo esempio è limitato solo alle app, non all'intero gruppo di risorse.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È necessario fornire le credenziali dell'entità servizio all'azione Azure/login come parte del flusso di lavoro di GitHub Action in uso. Questi valori possono essere forniti direttamente nel flusso di lavoro o possono essere archiviati nei segreti gitHub e a cui si fa riferimento nel flusso di lavoro. Il salvataggio dei valori come segreti GitHub è l'opzione più sicura.
Aprire il repository GitHub e passare a Impostazioni> Sicurezza>segreti e variabili Azioni>
Selezionare Nuovo segreto del repository e creare un segreto per ognuno dei valori seguenti. I valori sono disponibili nell'output JSON copiato in precedenza.
Nome valore AZURE_APP_ID <application/client-id>AZURE_PASSWORD <client-secret>AZURE_TENANT_ID <tenant-id>AZURE_SUBSCRIPTION_ID <subscription-id>
Creare il flusso di lavoro di GitHub Actions
Ora che si dispone di un'entità servizio in grado di accedere alle app servizio app, modificare i flussi di lavoro predefiniti creati per le app quando è stata configurata la distribuzione continua. L'autenticazione deve essere eseguita usando l'entità servizio anziché il profilo di pubblicazione. Per i flussi di lavoro di esempio, vedere la scheda "Entità servizio" in Aggiungere il file del flusso di lavoro al repository GitHub. Il flusso di lavoro di esempio seguente può essere usato per l'app di esempio Node.js fornita.
Aprire il repository GitHub dell'app e passare alla
<repo-name>/.github/workflows/directory . Verranno visualizzati i flussi di lavoro generati automaticamente.Per ogni file del flusso di lavoro, selezionare il pulsante "matita" in alto a destra per modificare il file. Sostituire il contenuto con il testo seguente, che presuppone che i segreti gitHub siano stati creati in precedenza per le credenziali. Aggiornare il segnaposto per
<web-app-name>nella sezione "env" e quindi eseguire il commit direttamente nel ramo main. Questo commit attiva l'esecuzione di GitHub Action e la distribuzione del codice, questa volta usando l'entità servizio per l'autenticazione.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
In che modo il routing del traffico slot consente di testare gli aggiornamenti apportati alle app?
Il routing del traffico con slot consente di indirizzare una parte predefinita del traffico utente a ogni slot. Inizialmente, il 100% del traffico viene indirizzato al sito di produzione. Tuttavia, è possibile, ad esempio, inviare il 10% del traffico allo slot di staging. Se si configura il routing del traffico slot in questo modo, quando gli utenti tentano di accedere all'app, il 10% di essi viene automaticamente instradato allo slot di staging senza modifiche all'istanza di Frontdoor. Per altre informazioni sugli scambi di slot e sugli ambienti di gestione temporanea in servizio app, vedere Configurare gli ambienti di gestione temporanea in app Azure Servizio.
Ricerca per categorie spostare il codice dallo slot di staging allo slot di produzione?
Dopo aver completato i test e la convalida negli slot di staging, è possibile eseguire uno scambio di slot dallo slot di staging al sito di produzione. È necessario eseguire questo scambio per tutte le istanze dell'app in ogni area. Durante uno scambio di slot, la piattaforma servizio app garantisce che lo slot di destinazione non subisca tempi di inattività.
Per eseguire lo scambio, eseguire il comando seguente per ogni app. Sostituire il segnaposto per <web-app-name>.
az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production
Dopo alcuni minuti, è possibile passare all'endpoint di Frontdoor per convalidare lo scambio di slot riuscito.
A questo punto, le app sono in esecuzione e tutte le modifiche apportate al codice sorgente dell'applicazione attivano automaticamente un aggiornamento per entrambi gli slot di staging. È quindi possibile ripetere il processo di scambio degli slot quando si è pronti per spostare il codice nell'ambiente di produzione.
In che altro modo è possibile usare Frontdoor di Azure nelle distribuzioni in più aree?
Se sei preoccupato per potenziali interruzioni o problemi di continuità tra aree, come in alcuni clienti che vedono una versione dell'app mentre altri vedono un'altra versione o se stai apportando modifiche significative alle tue app, puoi rimuovere temporaneamente il sito che sta eseguendo lo scambio di slot dal gruppo di origine di Frontdoor. Tutto il traffico viene quindi indirizzato all'altra origine. Passare al riquadro Aggiorna gruppo di origine ed Eliminare l'origine in fase di modifica. Dopo aver apportato tutte le modifiche e aver eseguito nuovamente il traffico, è possibile tornare allo stesso riquadro e selezionare + Aggiungi un'origine per leggere l'origine.
Se si preferisce non eliminare e quindi leggere le origini, è possibile creare gruppi di origine aggiuntivi per l'istanza di Frontdoor. È quindi possibile associare la route al gruppo di origine che punta all'origine desiderata. Ad esempio, è possibile creare due nuovi gruppi di origine, uno per l'area primaria e uno per l'area secondaria. Quando l'area primaria è in fase di modifica, associare la route all'area secondaria e viceversa quando l'area secondaria è in fase di modifica. Al termine di tutte le modifiche, è possibile associare la route al gruppo di origine originale che contiene entrambe le aree. Questo metodo funziona perché una route può essere associata solo a un gruppo di origine alla volta.
Per illustrare l'uso di più origini, nello screenshot seguente sono presenti tre gruppi di origine. "MyOriginGroup" è costituito da entrambe le app Web e dagli altri due gruppi di origine ognuno è costituito dall'app Web nella rispettiva area. Nell'esempio l'app nell'area primaria è in fase di modifica. Prima dell'avvio della modifica, la route è stata associata a "MySecondaryRegion" in modo che tutto il traffico venga inviato all'app nell'area secondaria durante il periodo di modifica. È possibile aggiornare la route selezionando Unassociated, che visualizza il riquadro Associa route .
Ricerca per categorie limitare l'accesso al sito degli strumenti avanzati?
Con app Azure servizio, il sito SCM/advanced tools viene usato per gestire le app e distribuire il codice sorgente dell'applicazione. Valutare la possibilità di bloccare il sito degli strumenti SCM/avanzati perché questo sito probabilmente non deve essere raggiunto tramite Frontdoor. Ad esempio, è possibile configurare restrizioni di accesso che consentono solo di eseguire i test e abilitare la distribuzione continua dallo strumento preferito. Se si usano slot di distribuzione, per gli slot di produzione in modo specifico, è possibile negare quasi tutto l'accesso al sito di Gestione certificati dal momento che i test e la convalida vengono eseguiti con gli slot di staging.