Condividi tramite

Esercitazione: Creare un'app multi-area a disponibilità elevata in Servizio app di Azure

La disponibilità elevata e la tolleranza di errore sono componenti chiave di una soluzione ben progettata. Una configurazione affidabile include un piano di emergenza per gli errori imprevisti, per ridurre i tempi di inattività e mantenere i sistemi in esecuzione automaticamente.

Quando si distribuisce un'app nel cloud, si sceglie un'area nel cloud per la base dell'infrastruttura dell'app. Se si distribuisce un'app solo in una singola area e tale area non è più disponibile, l'app non è disponibile. La mancanza di disponibilità potrebbe essere inaccettabile in base ai termini del contratto di servizio dell'app. Per garantire la disponibilità, distribuire l'app e i relativi servizi in più aree nel cloud.

Questa esercitazione descrive come distribuire un'applicazione web multi-regione ad alta disponibilità. La procedura implementa uno scenario semplice costituito da un'app Web e Frontdoor di Azure. È possibile espandere i concetti per supportare altri modelli di infrastruttura. Ad esempio, se l'app si connette a un'offerta di database Azure o a un account di archiviazione, vedere Replica geografica attiva per i database SQL e Archiviazione di Azure ridondanza. Per un'architettura di riferimento per uno scenario più dettagliato, vedere il modello di app Web Reliable per .NET.

In questa esercitazione, farai:

  • Creare app di App Service identiche in regioni diverse
  • Creare Frontdoor di Azure con restrizioni di accesso per bloccare l'accesso pubblico al servizio app

Prerequisiti

Se non si ha un account Azure, creare un account free prima di iniziare.

Per completare questa esercitazione:

Esaminare l'architettura dello scenario

Il diagramma dell'architettura seguente illustra l'infrastruttura creata in questa esercitazione. È costituito da due app di App Service identiche in regioni separate. La prima app Web si trova nell'area attiva. È l'app primaria responsabile dell'elaborazione del traffico in ingresso. La seconda app si trova nell'area di standby e attende la disponibilità dell'app primaria. Frontdoor di Azure tenta di instradare il traffico all'app Web primaria. Quando l'area primaria non è disponibile, il traffico viene reindirizzato al sito web di riserva. Nel diagramma la linea tratteggiata rappresenta il routing del traffico in base allo stato dell'area. Le restrizioni di accesso sono configurate in modo da bloccare l'accesso diretto alle app da Internet.

Diagramma che mostra l'architettura di un servizio app in più aree.

Azure offre diverse opzioni per il bilanciamento del carico e il routing del traffico. Frontdoor di Azure è selezionato per questa esercitazione perché include app Web con connessione Internet ospitate in Servizio app di Azure distribuite in più aree. Se la configurazione è diversa dall'esempio in questa esercitazione, vedere Scegliere una soluzione di bilanciamento del carico per lo scenario in uso.

Lo scenario in questa esercitazione offre il comportamento seguente:

  • Le app del servizio app identiche vengono distribuite in due aree separate.
  • Il traffico pubblico inviato direttamente alle app Web viene bloccato.
  • Frontdoor di Azure instrada il traffico all'applicazione attiva nell'area primaria.
  • L'app standby nell'area secondaria è disponibile per gestire il traffico, in base alle esigenze.

Creare un gruppo di risorse

Per questa esercitazione sono necessarie due istanze di un'app Web in esecuzione in aree Azure diverse.

  1. Esaminare le coppie di aree disponibili e selezionare due aree abbinate per le app Web.

    In questa esercitazione le due aree sono denominate <primary-region> (eastus) e <standby-region> (westus).

  2. Creare un gruppo di risorse per tutte le risorse configurate in questa esercitazione. Questa esercitazione crea il gruppo di risorse nella <primary-region> posizione.

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --name <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --location <primary-region> Posizione della regione per il gruppo di risorse. Questa esercitazione usa la stessa posizione geografica per il gruppo di risorse e per l'app web primaria. eastus

    In un'implementazione effettiva usare gruppi di risorse separati per ogni area/risorsa. La separazione consente l'isolamento delle risorse in una situazione di ripristino di emergenza.

    Per altre informazioni, vedere il riferimento al comando az group create .

Creare due piani di servizio app

Creare due piani di servizio app, uno per ogni app Web. Creare ogni piano nella località dell'area in cui si prevede di creare l'app corrispondente.

Per questo comando si usa la coppia di aree selezionata in precedenza. Usare l'area attiva per l'app Web primaria e l'area passiva per l'app Web di standby.

Eseguire il comando seguente per creare il piano di servizio app per l'app Web primaria ed eseguire di nuovo il comando per creare il piano per l'app standby.

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

Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

Parametro Valore Descrizione Esempio
--name <app-service-plan> Nome del piano di servizio per app per l'applicazione web. Ogni istanza del piano deve avere un nome univoco. zava-primary-plan
zava-standby-plan
--resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
--location <region> Posizione geografica per l'app Web. - App Web primaria, area attiva eastus
- App Web in standby, area passiva westus

Per altre informazioni, vedere il riferimento al comando az appservice plan create .

Creare due applicazioni

Creare due app Web di App Service. Inserire ogni app in un piano di App Service corrispondente e nella corrispondente località regionale.

  1. Identificare la versione della --runtime lingua per le app Web.

    È possibile eseguire il comando seguente per l'elenco dei runtime disponibili:

    az webapp list-runtimes

    Se prevedi di utilizzare l'app di esempio Node.js descritta in questo tutorial, imposta il valore <language-version> su NODE:24-lts.

  2. Creare due applicazioni web. Eseguire il comando seguente per creare l'app Web primaria ed eseguire di nuovo il comando per creare l'app standby.

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --name <web-app-name> il nome dell'app Web. Ogni app deve avere un nome univoco globale. I caratteri validi sono a-z, 0-9e -. zava-primary-app
    zava-standby-app
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --name <app-service-plan> Nome del piano di servizio per app per l'applicazione web. zava-primary-plan
    zava-standby-plan
    --runtime <language-version> Versione del linguaggio di runtime per l'app Web. NODE:24-lts

    Per altre informazioni, vedere il riferimento al comando az webapp create .

  3. Identificare il defaultHostName valore per ogni app Web. Il formato del nome host è <web-app-name>.azurewebsites.net.

    Analizzare l'output del comando per ogni app Web e individuare il valore oppure eseguire il comando seguente per ogni app Web:

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --name <web-app-name> il nome dell'app Web. zava-primary-app
    zava-standby-app
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group

    Nella Azure portal il nome host per ogni app è visibile nella pagina Overview.

    Registrare i valori del nome host per un secondo momento. Usare i nomi host per definire gli indirizzi back-end per la distribuzione di Frontdoor di Azure.

  4. Verificare di poter accedere alle nuove app Web.

    1. In un browser immettere il nome host per l'app Web primaria, ad esempio zava-primary-app.azurewebsites.net.

      Quando la connessione ha esito positivo, viene visualizzato il messaggio seguente:

      Screenshot del messaggio del browser per una connessione riuscita a un'app di App Service usando il nome dell'host.

    2. Ripetere il test con l'hostname per l'app Web di standby.

Configurare Frontdoor di Azure

Una distribuzione in più aree può usare una configurazione attiva-attiva o attiva-passiva . L'area primaria è attiva e l'area di standby è passiva.

  • Una configurazione attiva-attiva distribuisce le richieste tra più aree attive.
  • Una configurazione attiva-passiva mantiene le istanze in esecuzione nell'area standby (passiva), ma non invia il traffico a meno che l'area primaria (attiva) non riesca.

Frontdoor di Azure consente di abilitare entrambe le configurazioni. Per altre informazioni sulla progettazione di app per la disponibilità elevata e la tolleranza di errore, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Creare un profilo

Creare un'istanza di Frontdoor di Azure Premium per instradare il traffico alle app Web.

  1. Esaminare il confronto tra livelli Frontdoor di Azure e selezionare il livello per la distribuzione.

    Questa esercitazione usa Frontdoor di Azure Premium (Premium_AzureFrontDoor).

    Se si preferisce distribuire Frontdoor di Azure Standard, tenere presente che il livello Standard non supporta la distribuzione di regole gestite con criteri WAF.

  2. Eseguire il comando seguente per creare il profilo:

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. Il nome deve essere univoco all'interno del gruppo di risorse. zava-profile
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --sku <front-door-tier> SKU del livello di Frontdoor di Azure per la distribuzione. Premium_AzureFrontDoor (scelta consigliata)
    Standard_AzureFrontDoor

    Per altre informazioni, vedere il riferimento al comando az afd profile create .

Aggiungere un endpoint

Creare un endpoint nel profilo. Dopo aver creato il primo endpoint, è possibile creare più endpoint nel profilo.

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

Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

Parametro Valore Descrizione Esempio
--resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
--endpoint-name <front-door-endpoint> Nome dell'endpoint nel profilo di Frontdoor di Azure. Il nome deve essere univoco a livello globale. zava-endpoint
--profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile

Per altre informazioni, vedere il riferimento al comando az afd endpoint create .

Creare un gruppo di origine

Quando si esegue la distribuzione in Frontdoor di Azure, è necessaria un'origine da usare come endpoint per il back-end dell'app Web. Per altre informazioni, vedere Origini e gruppi di origine in Frontdoor di Azure. Le origini vengono archiviate in un gruppo di origine.

Creare un gruppo di origine nel profilo Frontdoor di Azure per contenere origini per le due app Web.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

Parametro Valore Descrizione Esempio
--resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
--origin-group-name <front-door-origin-group> Nome del gruppo di origine Frontdoor di Azure. Il nome deve essere univoco a livello globale. zava-origin-group
--profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile
--probe-request-type <probe-request> Tipo di richiesta per il probe di integrità. GET
--probe-protocol <probe-protocol> Il protocollo per usare il probe di integrità. Http
--probe-interval-in-seconds <probe-interval> Il numero di secondi tra probe di integrità. 60
--probe-path <probe-path> Percorso relativo all'origine usato per determinare l'integrità dell'origine. / (barra rovesciata)
--sample-size <sample-size> Il numero di campioni da considerare per le decisioni di bilanciamento del carico. 4
--successful-samples-required <required-samples> Numero di campioni nel periodo di campionamento che devono avere esito positivo. 3
--additional-latency-in-milliseconds <extra-latency> La latenza aggiuntiva in millisecondi affinché i probe vadano in un contenitore di latenza più basso. 50

Per altre informazioni, vedere il riferimento al comando az afd origin-group create .

Aggiungere origini al gruppo di origine

Aggiungere un'origine per ogni app Web al gruppo di origine Frontdoor di Azure.

  1. Aggiungere un'origine per l'app Web principale. Impostare il parametro --priority su 1, che informa Frontdoor di Azure che questa app è il ricevitore principale per il traffico.

    az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
   --origin-group-name <front-door-origin-group> \
   --origin-name <web-app-origin-name> \
   --origin-host-header <web-app-name>.azurewebsites.net \
   --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
   --http-port <origin-port> --https-port <origin-secure-port>

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --host-name <web-app-name>.azurewebsites.net Nome host per la tua applicazione web principale. Il nome host combina il nome dell'app Web, ad esempio zava-primary-app con l'identificatore host , azurewebsites.net. zava-primary-app.azurewebsites.net
    --profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile
    --origin-group-name <front-door-origin-group> Nome del gruppo di origine Frontdoor di Azure. zava-origin-group
    --origin-name <web-app-origin-name> Nome dell'origine dell'applicazione Web primaria. Il nome deve essere univoco all'interno del gruppo di origine. primary-origin
    --origin-host-header <web-app-name>.azurewebsites.net Intestazione host da inviare per le richieste verso l'origine dell'app Web primaria. Se non si specifica un valore, il nome host della richiesta determina questo valore. Le origini di Rete CDN di Azure, ad esempio App Web, gestione rete virtuale di Azure e Servizi Cloud, richiedono che questo valore di intestazione host corrisponda al nome host di origine per impostazione predefinita. zava-primary-app.azurewebsites.net
    --priority <origin-priority> Priorità per questa origine all'interno del gruppo di origine. Per l'app Web primaria, impostare la priorità a 1. Frontdoor di Azure usa i valori di priorità per il bilanciamento del carico tra origini e aree attive. Il valore deve essere compreso tra 1 e 5. 1
    --weight <origin-weight> Il peso dell'origine nel gruppo di origine specificato per il bilanciamento del carico. Il valore deve essere compreso tra 1 e 1000. 1000
    --enabled-state <origin-state> Indicare se abilitare questa origine per ricevere traffico. Enabled
    --http-port <origin-port> Porta usata per le richieste HTTP all'origine. 80
    --https-port <origin-secure-port> Porta usata per le richieste HTTPS sicure all'origine. 443

    Per altre informazioni, vedere il riferimento al comando az afd origin create .

  2. Eseguire di nuovo il comando e aggiungere un'origine per l'app Web standby . Il comando usa gli stessi parametri, ma con i valori di parametro univoci seguenti:

    Parametro Valore Descrizione Esempio
    --host-name <web-app-name>.azurewebsites.net Il nome host per l'app Web standby. zava-standby-app.azurewebsites.net
    --origin-name <web-app-origin-name> Nome dell'origine per l'app Web standby. standby-origin
    --origin-host-header <web-app-name>.azurewebsites.net Intestazione host da inviare per le richieste verso l'origine dell'app Web standby. zava-standby-app.azurewebsites.net
    --priority <origin-priority> Priorità per questa origine all'interno del gruppo di origine. Per l'app Web standby , impostare la priorità su 2. Frontdoor di Azure tenta di indirizzare tutto il traffico all'origine primaria. Quando l'origine primaria non è disponibile, il traffico viene instradato all'origine di standby. 2

Aggiungere una regola di route

Aggiungere una regola di routing per eseguire il mapping dell'endpoint di Frontdoor di Azure al gruppo di origine. La route inoltra le richieste dall'endpoint al gruppo di origine.

  1. Creare una regola del percorso per associare l'endpoint Frontdoor di Azure al gruppo di origine:

    az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
   --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
   --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link>

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile
    --endpoint-name <front-door-endpoint> Nome dell'endpoint nel profilo Frontdoor di Azure. zava-endpoint
    --forwarding-protocol <protocol-type> Protocollo utilizzato da questa regola di instradamento durante l'inoltro del traffico alle applicazioni backend. MatchRequest
    --route-name <route-rule-name> Nome della regola di route. Deve essere univoco all'interno del profilo di Frontdoor di Azure. zava-route-rule
    --https-redirect <secure-redirect> Indica se reindirizzare automaticamente il traffico HTTP al traffico HTTPS. Enabled
    --origin-group-name <front-door-origin-group> Nome del gruppo di origine Frontdoor di Azure. zava-origin-group
    --supported-protocols <protocol-list> Elenco dei protocolli supportati per questa regola di route. Usare uno spazio per separare i tipi di protocollo. Http Https
    --link-to-default-domain <domain-link> Indicare se questa route è collegata al dominio endpoint predefinito. Enabled

    Per altre informazioni, vedere il riferimento al comando az afd route create .

  2. Attendere circa 15 minuti per il completamento della distribuzione. La propagazione globale delle modifiche può richiedere del tempo.

Limitare l'accesso solo tramite Frontdoor di Azure

È attualmente possibile accedere alle app Web direttamente immettendo i relativi nomi host in un browser. Se si impostano restrizioni di accesso per le app, è possibile assicurarsi che il traffico raggiunga le app solo tramite Frontdoor di Azure.

Frontdoor di Azure funzionalità funzionano meglio quando il traffico passa solo attraverso il servizio. È consigliabile configurare le origini dell'app Web per bloccare il traffico che non viene inviato tramite Frontdoor di Azure. In caso contrario, il traffico potrebbe ignorare la Frontdoor di Azure web application firewall, la protezione DDoS e altre funzionalità di sicurezza.

Il traffico da Frontdoor di Azure alle app proviene da un set noto di intervalli IP definiti nel tag del servizio AzureFrontDoor.Backend. Usando una regola di restrizione dei tag di servizio, è possibile stricare il traffico solo da Frontdoor di Azure.

  1. Ottenere l'identificatore per il profilo di Frontdoor di Azure.

    È necessario l'ID del profilo per assicurarsi che il traffico provenga solo dall'istanza di Frontdoor di Azure specifica. La restrizione di accesso filtra ulteriormente le richieste in ingresso in base all'intestazione HTTP univoca inviata dal profilo di Frontdoor di Azure.

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile

    L'output del comando visualizza l'ID profilo (valore alfanumerico a 32 cifre):

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

    Nel passaggio successivo si usa l'ID del profilo per il valore <profile-identifier>.

  2. Eseguire il comando seguente per impostare le restrizioni di accesso nell'app Web primaria ed eseguire di nuovo il comando per impostare restrizioni sull'app standby.

    az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
   --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --name <web-app-name> Nome dell'app Web per cui si stanno impostando le restrizioni di accesso. zava-primary-app
    zava-standby-app
    --priority <access-priority> Specificare la priorità della regola di restrizione di accesso in tutte le regole definite per il profilo. Un valore inferiore equivale a una priorità più alta. 100
    --service-tag <tag-name> Nome del tag del servizio riconosciuto da Frontdoor di Azure. Le restrizioni di accesso si applicano all'intervallo IP indicato dal tag del servizio. AzureFrontDoor.Backend
    --http-header x-azure-fdid=<profile-identifier> Specificare una o più intestazioni HTTP univoche per un filtro aggiuntivo del traffico in ingresso. Le restrizioni di accesso filtrano le richieste in ingresso in base all'intestazione HTTP univoca inviata dal profilo di Frontdoor di Azure. L'intestazione combina il prefisso di Frontdoor di Azure e l'identificatore del profilo dell'istanza Frontdoor di Azure. x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

    Per altre informazioni, vedere il riferimento al comando az webapp config access-restriction add.

Testare le restrizioni di accesso

Verificare che le restrizioni di accesso impediscano l'accesso diretto alle app.

  1. In un browser immettere il nome host per l'app Web primaria, ad esempio zava-primary-app.azurewebsites.net.

    La connessione dovrebbe fallire con il seguente messaggio:

    Screenshot del messaggio visualizzato nel browser quando la connessione diretta a un'app di App Service è vietata.

  2. Ripeti il test con il nome host della tua applicazione web di standby, come zava-standby-app.azurewebsites.net.

Test della distribuzione di Frontdoor di Azure

Quando si crea il profilo Frontdoor di Azure Standard o Premium, la distribuzione globale della configurazione può richiedere del tempo. Al termine della distribuzione, è possibile accedere all'host front-end.

  1. Ottenere il nome host dell'endpoint Frontdoor di Azure:

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

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

    Parametro Valore Descrizione Esempio
    --resource-group <resource-group> Gruppo di risorse che contiene le risorse create in questa esercitazione. zava-resource-group
    --profile-name <front-door-profile> Nome del profilo di Frontdoor di Azure. zava-profile
    --endpoint-name <front-door-endpoint> Nome dell'endpoint nel profilo Frontdoor di Azure. zava-endpoint

    L'output del comando visualizza il nome host dell'endpoint:

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

    Il nome host è costituito dal nome dell'endpoint, da un hash alfanumerico univoco, da un identificatore e dal suffisso Frontdoor di Azure. Nel passaggio successivo si usa il nome host dell'endpoint.

    Per altre informazioni, vedere il riferimento al comando az afd endpoint show .

  2. In un browser immettere il nome host dell'endpoint, ad esempio zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

    La tua richiesta dovrebbe essere instradata automaticamente alla tua app primaria nella regione attiva.

    Quando la connessione ha esito positivo, viene visualizzato il messaggio seguente:

    Screenshot del messaggio del browser per una connessione corretta a un'app di App Service utilizzando il nome host dell'endpoint.

  3. Testare il failover globale istantaneo tra le app nelle aree abbinate.

    1. In un browser immettere il nome host dell'endpoint, ad esempio zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

    2. Arrestare l'app primaria eseguendo il comando az webapp stop .

      Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

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

    3. Aggiornare il browser.

      Se il traffico viene reindirizzato correttamente all'app standby nell'altra regione, dovresti vedere la stessa pagina e lo stesso messaggio.

      Suggerimento

      Potrebbe essere necessario aggiornare la pagina alcune volte per il completamento del failover.

      È possibile verificare che Frontdoor di Azure stia reindirizzando all'app di standby controllando lo stato delle app Web nel portale di Azure. Nella pagina Panoramica per l'applicazione web principale, l'opzione Start deve essere disponibile (non disattivata). Nella pagina Panoramica per l'app Web standby l'opzione Start non deve essere disponibile (in grigio).

    4. Esegui nuovamente il comando az webapp stop e ferma la tua app standby.

      Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

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

    5. Aggiornare di nuovo il browser.

      Se anche l'app di standby si arresta, tutto il routing del traffico dovrebbe essere interrotto. Questa volta verrà visualizzato un messaggio di errore:

      Screenshot del messaggio visualizzato nel browser quando entrambe le app Web vengono arrestate e nessuna connessione è possibile.

    6. Eseguire il comando e riavviare l'app az webapp startstandby .

      Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse:

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

    7. Aggiornare il browser e verrà visualizzata una connessione dell'app riuscita.

La convalida conferma che ora puoi accedere alle tue app tramite Frontdoor di Azure e le funzioni di failover funzionano come previsto.

Se hai finito con il test di failover, riavvia l'app primaria.

Pulire le risorse

Negli step precedenti, hai creato risorse di Azure in un gruppo di risorse. Se non si prevede che queste risorse siano necessarie in futuro, eliminare il gruppo di risorse eseguendo il comando seguente nel Cloud Shell.

Sostituire il valore del <placeholder> parametro con le informazioni per la propria risorsa:

az group delete --name <resource-group>

L'esecuzione del comando può impiegare alcuni minuti.

Eseguire la distribuzione da ARM o Bicep

Le risorse create in questa esercitazione possono essere distribuite usando un modello di Azure Resource Manager (modello arm) o Bicep. È possibile iniziare con il file Bicep dell'app Web multiregione altamente disponibile su GitHub. Questo modello consente di creare una soluzione end-to-end sicura e a disponibilità elevata con due applicazioni web in regioni diverse gestite da Frontdoor di Azure.

Per informazioni su come distribuire modelli ARM e Bicep, vedere Distribuire file Bicep con l'interfaccia della riga di comando di Azure.

Domande frequenti

In questa esercitazione, hai distribuito un'infrastruttura di base per abilitare un'applicazione Web multi-regione. Il servizio app offre funzionalità che consentono di assicurarsi di eseguire applicazioni che seguono le procedure consigliate e le raccomandazioni per la sicurezza.

Questa sezione contiene le risposte alle domande frequenti che consentono di proteggere ulteriormente le app e distribuire e gestire le risorse in base alle procedure consigliate.

Gestire e distribuire l'infrastruttura e le risorse Azure

Per questa esercitazione è stato usato il 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, l'infrastruttura come codice (IaC), ad esempio un modello ARM o Terraform deve essere usato con pipeline di distribuzione come Azure Pipelines o GitHub Actions. Quando si configura questa configurazione in modo appropriato, qualsiasi modifica alle risorse attiva gli aggiornamenti in tutte le aree di distribuzione. Per altre informazioni, vedere Configurare la distribuzione continua in Servizio app di Azure.

Utilizzare gli slot di staging per una distribuzione sicura nell'ambiente di produzione

La distribuzione del codice dell'applicazione direttamente in app e slot di produzione non è consigliata. È importante avere un posto sicuro per testare le app e convalidare le modifiche prima di eseguire il 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.

In questa esercitazione è stata creata l'infrastruttura di base che supporta l'uso degli slot di staging. È possibile creare slot di distribuzione per ogni istanza dell'app Web e configurare la distribuzione continua in questi slot di staging con GitHub Actions. Come per la gestione dell'infrastruttura, è consigliabile anche configurare la distribuzione continua per il codice sorgente dell'applicazione per garantire che le modifiche tra le aree rimangano 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 usare gli slot di staging, seguire questa procedura:

  1. Per questa procedura, è necessaria un'app pronta per la distribuzione su App Service.

    Se hai completato il tutorial, puoi utilizzare la tua web app principale e quella di riserva. Tuttavia, è necessario un piano di servizio app che supporti slot di distribuzione sufficienti. Per ulteriori informazioni, vedere limiti delle sottoscrizioni e dei servizi di Azure, quote e vincoli.

    Se non hai un'app, puoi iniziare con l'app di esempio Node.js Hello World. Fai un fork del repository GitHub per avere una tua copia su cui apportare modifiche.

  2. Configurare le impostazioni dello stack del servizio app per le app Web.

    Le impostazioni dello stack fanno riferimento alla versione del linguaggio o al runtime usato per l'app.

    È possibile configurare le impostazioni nel portale di Azure o usare il comando az webapp config set. Se si usa l'esempio di Node.js, impostare le impostazioni dello stack su Node 24 LTS.

    1. Nel portale Azure, vai alla tua app Web principale.

    2. Nel menu a sinistra selezionare Configurazione impostazioni>.

    3. Nella scheda Impostazioni stack configurare le impostazioni seguenti:

      1. Selezionare il valore Stack , ad esempio Node.

      2. Selezionare il valore Versione , ad esempio Node 24 LTS.

      3. Seleziona Applica.

    4. Ripetere il processo per configurare le impostazioni dello stack dell'App Service per l'applicazione web standby.

  3. Configurare la distribuzione continua nel portale di Azure. Per indicazioni dettagliate su come configurare la distribuzione continua con provider come GitHub Actions, vedere Configurare la distribuzione continua in Servizio app di Azure.

  4. Eseguire il comando seguente per creare uno slot di staging denominato stage per la tua app Web principale.

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

  5. Eseguire di nuovo il comando az webapp deployment slot create e creare uno slot di staging denominato stage per l'app web standby.

  6. Configurare la distribuzione continua con GitHub Actions per ogni slot di staging:

    1. Nel portale Azure, vai alla tua app Web principale.

    2. Nel menu a sinistra selezionare Slot di distribuzione>.

    3. Trova lo slot stage nell'elenco e selezionalo per aprire il riquadro dei dettagli.

    4. Nel menu a sinistra selezionare Centro distribuzione>.

    5. Nella scheda Settings impostare l'opzione Source su GitHub:

      Screenshot che illustra come scegliere l'origine di distribuzione per lo slot di gestione temporanea dell'app web nel portale di Azure.

    6. Se si esegue la distribuzione da GitHub per la prima volta, selezionare Authorize e seguire le istruzioni di autorizzazione. Per eseguire la distribuzione da un repository utente diverso, selezionare Cambia account.

    7. Dopo aver autorizzato l'account Azure con GitHub, selezionare Organization, Repository e Branch per configurare CI/CD per. Se non è possibile trovare un'organizzazione o un repository, potrebbe essere necessario abilitare altre autorizzazioni per GitHub. Per altre informazioni, vedere Gestire l'accesso utente ai repository dell'organizzazione.

      Se si usa l'app di esempio Node.js, usare le impostazioni seguenti.

      Impostazione Valore
      Organizzazione <your-GitHub-organization>
      Repository nodejs-docs-hello-world
      Ramo principale

    8. Selezionare Salva.

I nuovi commit nel repository e nel ramo selezionati vengono distribuiti in modo continuo nello slot delle app di 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 nel servizio app viene aggiunto al repository GitHub. È possibile visualizzare questo file passando alla directory <repo-name>/.github/workflows/.

Disabilitare l'autenticazione di base nel servizio app

È possibile limitare l'accesso agli endpoint FTP e SCM agli utenti autenticati tramite Microsoft Entra ID disabilitando l'autenticazione di base.

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 Microsoft Entra. È invece necessario usare un'entità di servizio o una credenziale OpenID Connect.

I seguenti comandi disabilitano l'autenticazione di base per l'applicazione Web primaria e lo slot di staging di App Service, nonché per l'applicazione Web di riserva e lo slot di staging. Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse.

  1. Disabilitare l'accesso FTP ai siti di produzione e agli slot di staging per la tua applicazione web principale

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

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

  2. Eseguire di nuovo i comandi per l'app Web standby .

  3. Disattivare l'accesso tramite autenticazione di base alla porta WebDeploy e al sito SCM per i siti di produzione e gli slot di staging dell'app Web primaria:

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

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

  4. Eseguire di nuovo i comandi per l'app Web standby .

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 del servizio app.

Usare la distribuzione continua quando l'autenticazione di base è disabilitata

Se si sceglie di consentire l'autenticazione di base nelle app del servizio app, è possibile usare uno dei metodi di distribuzione disponibili nel servizio app. Ad esempio, è possibile usare il profilo di pubblicazione configurato nella sezione slot di staging.

Se si disabilita l'autenticazione di base per le app Servizi app, la distribuzione continua richiede un'entità servizio o OpenID Connect per l'autenticazione. Se si usa GitHub Actions come repository di codice, consultare Distribuire su Servizio app di Azure usando GitHub Actions. L'esercitazione fornisce istruzioni dettagliate per creare un'entità di servizio principale o OpenID Connect per distribuire a Servizio app utilizzando le GitHub Actions. È anche possibile completare il processo seguendo la procedura descritta nella sezione successiva.

Creare un service principal e credenziali utilizzando GitHub Actions

Configurare la distribuzione continua con GitHub Actions e un'entità servizio:

  1. Creare il servizio principale per l'applicazione web primaria e l'applicazione web di standby:

    Sostituire i valori dei parametri seguenti <placeholder> con le informazioni per le proprie risorse.

    az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
   /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>

    L'output è un oggetto JSON con le credenziali di assegnazione di ruolo che forniscono l'accesso alle app di Servizio app.

    {
  "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
  "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
  "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

    Il JSON include il segreto del cliente, che è visibile solo ora.

    Suggerimento

    È consigliabile concedere l'accesso minimo. In questo esempio l'ambito è limitato solo alle app, non all'intero gruppo di risorse.

  2. Copiare l'oggetto JSON in modo da avere un record del segreto client.

  3. Fornire le credenziali dell'entità servizio per l'operazione di accesso di Azure come parte del workflow di GitHub Action.

    È possibile specificare i valori direttamente nel flusso di lavoro o archiviarli come GitHub segreti a cui viene fatto riferimento nel flusso di lavoro. Il salvataggio dei valori come GitHub segreti è l'opzione più sicura.

    1. Aprire il repository GitHub per l'app.

    2. Passare a Impostazioni> Segreti disicurezza>e variabili>Azioni.

    3. Selezionare Nuovo segreto del repository e creare un segreto per ognuna delle impostazioni seguenti. Usa i valori dell'output JSON.

      Impostazione Valore Esempio
      AZURE_APP_ID <application/client-id> 00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD <client-secret> ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID <tenant-id> aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID <subscription-id> cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

Creare un flusso di lavoro di GitHub Actions

Dopo aver creato un'entità servizio che possa accedere alle app di App Service, modifica i flussi di lavoro predefiniti per le tue app. Questi flussi di lavoro vengono generati automaticamente quando si configura 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 Service principal in Aggiungi il file del flusso di lavoro al repository GitHub. Il flusso di lavoro di esempio seguente può essere usato per l'app di esempioNode.js.

  1. Aprire il repository GitHub per l'app.

  2. Passare alla directory <repo-name>/.github/workflows/. Verranno visualizzati i flussi di lavoro generati automaticamente.

  3. Per ogni file del flusso di lavoro, selezionare Modifica (matita).

  4. Sostituire il contenuto del file del flusso di lavoro con il contenuto seguente. Il codice presuppone che siano già stati creati i segreti GitHub per le credenziali.

    Nella sezione env, configurare le impostazioni seguenti:

    • AZURE_WEBAPP_NAME: sostituire il <web-app-name> segnaposto con il nome dell'app Web.
    • NODE_VERSION: specificare la versione del nodo da usare. Per l'esempio di Node.js, il valore è '24.x'.
    • AZURE_WEBAPP_PACKAGE_PATH: Specifica il percorso del progetto della web app. Il valore predefinito è la radice del repository, '.'.
    • AZURE_WEBAPP_SLOT_NAME: specificare il nome dello slot dell'applicazione. Il nome comune è stage.
    
 name: Build and deploy Node.js app to Azure Web App

 on:
   push:
     branches:
       - main
   workflow_dispatch:

 env:
   AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
   NODE_VERSION: '24.x'                # Node version to use
   AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
   AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name

 jobs:
   build:
     runs-on: ubuntu-latest

     steps:
       - uses: actions/checkout@v4

       - name: Set up Node.js version
         uses: actions/setup-node@v4
         with:
           node-version: ${{ env.NODE_VERSION }}

       - name: npm install, build
         run: |
           npm install
           npm run build --if-present

       - name: Upload artifact for deployment job
         uses: actions/upload-artifact@v4
         with:
           name: node-app
           path: .

   deploy:
     runs-on: ubuntu-latest
     needs: build
     environment:
       name: 'stage'
       url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}

     steps:
       - name: Download artifact from build job
         uses: actions/download-artifact@v4
         with:
           name: node-app

       - uses: azure/login@v2
         with:
           creds: |
             {
               "clientId": "${{ secrets.AZURE_APP_ID }}",
               "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
               "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
               "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
             }

       - name: 'Deploy to Azure Web App'
         id: deploy-to-webapp
         uses: azure/webapps-deploy@v3
         with:
           app-name: ${{ env.AZURE_WEBAPP_NAME }}
           slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
           package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

       - name: logout
         run: |
           az logout

  5. Salva ed effettua il commit delle modifiche al file del flusso di lavoro direttamente nel ramo principale del tuo repository.

    Il commit attiva l'azione GitHub per una nuova esecuzione e la distribuzione del codice. Questa volta, il servizio principale viene utilizzato per l'autenticazione.

Testare gli aggiornamenti delle app usando il routing degli slot di traffico

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 inviare il 10% del traffico alla slot di staging. Questo approccio al routing del traffico slot invia automaticamente il 10 percento degli utenti che tentano di accedere allo slot di staging. L'approccio non richiede modifiche all'istanza di Frontdoor di Azure. Per altre informazioni sugli scambi di slot e sugli ambienti di gestione temporanea in Servizio app, vedere Configurare gli ambienti di staging in Servizio app di Azure.

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. Completare lo scambio per tutte le istanze della tua app in ogni area. Durante uno scambio di slot, la piattaforma Servizio app garantisce che lo slot di destinazione non subisca tempi di inattività.

  1. Eseguire lo scambio per l'app Web primaria:

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

  2. Eseguire lo scambio per l'app Web di standby:

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

  3. Dopo alcuni minuti, passare all'endpoint Frontdoor di Azure nel portale di Azure e verificare il completamento dello scambio di slot.

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.

Evitare interruzioni e problemi di continuità usando distribuzioni in più aree

È possibile evitare potenziali interruzioni o problemi di continuità tra aree rimuovendo temporaneamente un sito che sta eseguendo lo scambio di slot dal gruppo di origine Frontdoor di Azure. Questa azione aiuta a impedire che i clienti vedano contemporaneamente versioni diverse della tua app. È utile anche quando si apportano modifiche significative alle app. La rimozione temporanea causa il reindirizzamento di tutto il traffico all'altra origine.

  1. Nel portale di Azure, vai all'istanza di Frontdoor di Azure.

  2. Nel menu a sinistra selezionare Impostazioni>Gruppi di origine.

  3. Nell'elenco dei gruppi di origine selezionare il gruppo di origine che contiene lo slot da rimuovere temporaneamente.

  4. Nel riquadro Aggiorna gruppo di origine individuare lo slot da rimuovere nell'elenco Nome host origine .

  5. Selezionare Altre azioni (...) >Elimina e quindi seleziona Aggiorna.

    Schermata che mostra come rimuovere temporaneamente uno slot di origine di Frontdoor di Azure.

    L'applicazione della modifica può richiedere alcuni minuti.

  6. Quando sei pronto a consentire il traffico verso lo slot che è stato rimosso, torna al riquadro Aggiorna gruppo di origine.

  7. Nella parte superiore, selezionare + Aggiungi un'origine per riaggiungere lo slot origine al gruppo di origine.

    Screenshot che illustra come riaggiungere uno slot di origine di Frontdoor di Azure.

Creare gruppi di origine aggiuntivi e modificare le associazioni di route

Se si preferisce non eliminare e quindi leggere le origini, è possibile creare gruppi di origine aggiuntivi per l'istanza di Frontdoor di Azure. È quindi possibile associare la route al gruppo di origine che punta all'origine desiderata.

Ad esempio, è possibile creare due gruppi di origine aggiuntivi, uno per l'area primaria (attiva) e una per l'area di standby (passiva). Se la tua regione primaria è in fase di cambiamento, associa il percorso alla regione di standby. Se la regione di standby è in fase di modifica, associa il percorso alla regione primaria. 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.

Si consideri una configurazione con tre gruppi di origine:

  • Il gruppo Main-Origin contiene sia le app Web primarie che di standby, ognuna delle rispettive aree.
  • Il Primary-Origin gruppo contiene solo l'app Web primaria nell'area attiva.
  • Il Standby-Origin gruppo contiene solo l'app Web standby nell'area passiva.

Si supponga che l'app Web primaria sia in fase di modifica. Prima dell'avvio delle modifiche, l'associazione di instradamento per il gruppo Main-Origin viene modificata per il gruppo Secondary-Origin. Questa azione garantisce che tutte le rotte di traffico siano indirizzate all'app web di standby nella rispettiva area geografica, mentre l'app web primaria nella sua area geografica è in fase di modifica.

Seguire questa procedura per modificare l'associazione di route per un gruppo di origine:

  1. Nel portale di Azure, vai all'istanza di Frontdoor di Azure.

  2. Nel menu a sinistra selezionare Impostazioni>Gruppi di origine.

  3. Nell'elenco dei gruppi di origine individuare un gruppo di origine che mostra l'indicatore Non a cui è stato associato nella colonna Route .

  4. Selezionare Altre azioni (...) >Associare endpoint e route.

    Screenshot che mostra come selezionare l'opzione

  5. Nel riquadro Associa route selezionare una o più route da associare al gruppo di origine e quindi selezionare Associa.

    Screenshot che mostra come selezionare le route da associare a un gruppo di origine.

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 SCM/Strumenti 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.

Contenuti correlati

  • Last updated on