Configurare gli ambienti di gestione temporanea in Servizio app di Azure

Quando si distribuisce l'app Web, l'app Web in Linux, il back-end per dispositivi mobili o l'app per le API in app Azure Servizio, è possibile usare uno slot di distribuzione separato anziché lo slot di produzione predefinito quando si esegue nel livello di piano Standard, Premium o Isolato servizio app. Gli slot di distribuzione sono app live con i rispettivi nomi host. Il contenuto dell'app e gli elementi di configurazione possono essere scambiati tra due slot di distribuzione, incluso lo slot di produzione.

La distribuzione dell'applicazione in uno slot non di produzione offre i vantaggi seguenti:

• È possibile convalidare le modifiche dell'app in uno slot di distribuzione di gestione temporanea prima di scambiarlo con lo slot di produzione.
• La distribuzione preliminare di un'app in uno slot e la successiva implementazione in un ambiente di produzione garantiscono che tutte le istanze dello slot vengano effettivamente eseguite prima di passare alla fase di produzione. Ciò consente di evitare i tempi di inattività al momento della distribuzione dell'app. Il reindirizzamento del traffico è lineare e nessuna richiesta viene eliminata in seguito alle operazioni di scambio. È possibile automatizzare l'intero flusso di lavoro configurando lo scambio automatico quando non è necessaria la convalida preliminare dello scambio.
• Dopo uno scambio, lo slot con l'app gestita temporaneamente include l'app di produzione precedente. Se le modifiche applicate nello slot di produzione non risultano corrette, è possibile ripetere immediatamente lo scambio dei due slot per recuperare l'ultimo sito con i dati corretti.

Ogni piano del servizio app supporta un numero diverso di slot di distribuzione. Non sono previsti costi aggiuntivi per l'uso degli slot di distribuzione. Per scoprire il numero di slot supportati dal livello dell'app, vedi limiti servizio app.

Per ridimensionare l'app passando a un livello diverso, assicurarsi che il livello di destinazione supporti il numero di slot già usato dall'app. Se ad esempio l'app ha più di cinque slot, non è possibile passare a un piano inferiore scegliendo Standard, perché il livello Standard supporta solo cinque slot di distribuzione.

Questo video illustra come configurare gli ambienti di gestione temporanea in app Azure Servizio.

I passaggi del video sono descritti anche nelle sezioni seguenti.

Prerequisiti

Per informazioni sulle autorizzazioni necessarie per eseguire l'operazione slot desiderata, vedere Operazioni del provider di risorse ( ad esempio cercare slot).

Aggiungi uno slot

Per poter abilitare più slot di distribuzione, l'app deve essere in esecuzione con il piano Standard, Premium o Isolato.

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

Il nuovo slot di distribuzione non ha contenuto, anche se si clonano le impostazioni da un altro slot. Ad esempio, è possibile pubblicare in questo slot con Git. È possibile distribuire lo slot da un ramo diverso del repository o da un repository diverso. Ottenere il profilo di pubblicazione da app Azure Servizio può fornire informazioni necessarie per la distribuzione nello slot. Il profilo può essere importato da Visual Studio per distribuire il contenuto nello slot.

L'URL dello slot ha il formato http://sitename-slotname.azurewebsites.net. Per mantenere la lunghezza dell'URL entro i limiti DNS necessari, il nome del sito verrà troncato a 40 caratteri e il nome del sito combinato e il nome dello slot devono essere inferiori a 59 caratteri.

Cosa accade durante uno scambio

Passaggi dell'operazione di scambio

Quando si scambiano due slot (in genere da uno slot di staging come origine nello slot di produzione come destinazione), servizio app esegue le operazioni seguenti per assicurarsi che lo slot di destinazione non verifichi tempi di inattività:

1. Applicare le impostazioni seguenti dallo slot di destinazione (ad esempio, lo slot di produzione) a tutte le istanze dello slot di origine:

   • Impostazioni e stringa di connessione dell'app specifiche dello slot, se applicabile.
   • Impostazioni di distribuzione continua, se abilitate.
   • servizio app impostazioni di autenticazione, se abilitate.

   Uno di questi casi attiva tutte le istanze nello slot di origine per il riavvio. Durante lo scambio con l'anteprima, questo contrassegna la fine della prima fase. L'operazione di scambio viene sospesa ed è possibile verificare che lo slot di origine funzioni correttamente con le impostazioni dello slot di destinazione.

2. Attendere il completamento del riavvio di ogni istanza nello slot di origine. Se un'istanza non viene riavviata, l'operazione di scambio ripristina tutte le modifiche apportate allo slot di origine e arresta l'operazione.

3. Se la cache locale è abilitata, attivare l'inizializzazione della cache locale effettuando una richiesta HTTP alla radice dell'applicazione ("/") in ogni istanza dello slot di origine. Attendere che ogni istanza restituisca una risposta HTTP. L'inizializzazione della cache locale causa un altro riavvio in ogni istanza.

4. Se lo scambio automatico è abilitato con riscaldamento personalizzato, attivare l'avvio dell'applicazione effettuando una richiesta HTTP alla radice dell'applicazione ("/") in ogni istanza dello slot di origine.

   Se applicationInitialization non viene specificato, attivare una richiesta HTTP alla radice dell'applicazione dello slot di origine in ogni istanza.

   Se un'istanza restituisce una risposta HTTP, viene considerata come riscaldata.

5. Se il riscaldamento di tutte le istanze nello slot di origine viene eseguito correttamente, eseguire lo scambio dei due slot scambiando le rispettive regole di gestione. Dopo questo passaggio, lo slot di destinazione (ad esempio, lo slot di produzione) ha l'app precedentemente riscaldata nello slot di origine.

6. Ora che lo slot di origine ha l'app di pre-scambio che in precedenza era nello slot di destinazione, eseguire la stessa operazione applicando tutte le impostazioni e riavviando le istanze.

In qualsiasi momento dell'operazione di scambio, tutto il processo di inizializzazione delle app scambiate avviene nello slot di origine. Lo slot di destinazione rimane online mentre lo slot di origine viene preparato e riscaldato, indipendentemente dalla posizione in cui lo scambio ha esito positivo o negativo. Per scambiare uno slot di staging con lo slot di produzione, assicurarsi che lo slot di produzione sia sempre quello di destinazione. In questo modo, l'operazione di scambio non influisce sull'app di produzione.

Impostazioni incluse nello scambio

Quando si clona la configurazione da un altro slot di distribuzione, la configurazione clonata è modificabile. Alcuni elementi della configurazione seguono il contenuto nello scambio (non specifici dello slot), mentre altri elementi della configurazione restano nello stesso slot dopo uno scambio (specifici dello slot). Negli elenchi seguenti sono riportate le impostazioni che vengono modificate durante lo scambio degli slot.

Impostazioni che vengono scambiate:

• Impostazioni generali, quali la versione del framework, 32/64 bit, i socket Web
• Impostazioni dell'app (possono essere configurate per essere associate a uno slot)
• Stringhe di connessione (possono essere configurate per essere associate a uno slot)
• Mapping del gestore
• Certificati pubblici
• Contenuto dei processi Web
• Connessioni ibride *
• Endpoint servizio *
• Rete di distribuzione di contenuti di Azure *
• Mapping dei percorsi

Le funzionalità contrassegnate con un asterisco (*) sono pianificate per l'annullamento dello scambio.

Impostazioni che non vengono scambiate:

• Endpoint di pubblicazione
• Nomi di dominio personalizzati
• Certificati non pubblici e impostazioni TLS/SSL
• Impostazioni di ridimensionamento
• Utilità di pianificazione processi Web
• Restrizioni IP
• Funzionamento continuo
• Impostazioni di diagnostica
• Condivisione di risorse tra le origini (CORS)
• Integrazione della rete virtuale
• Identità gestite e impostazioni correlate
• Impostazioni che terminano con il suffisso _EXTENSION_VERSION
• Impostazioni creato da Connessione or del servizio

Per configurare un'impostazione dell'app o stringa di connessione per mantenere uno slot specifico (non scambiato), passare alla pagina Configurazione per tale slot. Aggiungere o modificare un'impostazione e quindi selezionare l'impostazione dello slot di distribuzione. Selezionando questa casella di controllo si indica al servizio app che l'impostazione non è scambiabile.

Scambiare due slot

È possibile scambiare gli slot di distribuzione nella pagina Slot di distribuzione dell'app e nella pagina Panoramica. Per informazioni tecniche sullo scambio di slot, vedere Cosa accade durante lo scambio.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

In caso di problemi, vedere Risolvere i problemi relativi agli scambi.

Scambio con anteprima (scambio in più fasi)

Prima di passare all'ambiente di produzione come slot di destinazione, verificare che l'app venga eseguita con le impostazioni scambiate. Anche lo slot di origine viene riscaldato prima del completamento dello scambio, operazione consigliabile per le applicazioni cruciali.

Quando si esegue uno scambio con anteprima, servizio app esegue la stessa operazione di scambio, ma viene sospesa dopo il primo passaggio. Questo consente di verificare il risultato nello slot di staging prima di completare lo scambio.

Se si annulla lo scambio, il servizio app riapplica gli elementi di configurazione allo slot di origine.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

In caso di problemi, vedere Risolvere i problemi relativi agli scambi.

Eseguire il rollback di uno scambio

Se si verificano errori nello slot di destinazione (ad esempio, lo slot di produzione) dopo uno scambio di slot, ripristinare gli slot allo stato precedente scambiandoli immediatamente.

Configurare lo scambio automatico

Lo scambio automatico semplifica gli scenari di Azure DevOps nei quali si vuole distribuire l'app in modo continuativo senza avvio a freddo e senza tempi di inattività per i clienti dell'app. Quando lo scambio automatico viene abilitato da uno slot nell'ambiente di produzione, ogni volta che si esegue il push delle modifiche al codice in tale slot, servizio app scambia automaticamente l'app in produzione dopo che viene riscaldata nello slot di origine.

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

In caso di problemi, vedere Risolvere i problemi relativi agli scambi.

Specificare il riscaldamento personalizzato

Alcune app potrebbero richiedere azioni preliminari personalizzate prima dello scambio. L'elemento di configurazione applicationInitialization in web.config consente di specificare le azioni di inizializzazione personalizzate. L'operazione di scambio attende il completamento del riscaldamento personalizzato prima dello scambio con lo slot di destinazione. Di seguito è riportato un frammento di web.config di esempio.

<system.webServer>
    <applicationInitialization>
        <add initializationPage="/" hostName="[app hostname]" />
        <add initializationPage="/Home/About" hostName="[app hostname]" />
    </applicationInitialization>
</system.webServer>

Per altre informazioni sulla personalizzazione dell'elemento applicationInitialization, vedere Errori di scambio di slot di distribuzione più comuni e come risolverli.

È anche possibile personalizzare il comportamento di riscaldamento con una o entrambe le impostazioni dell'app seguenti:

• WEBSITE_SWAP_WARMUP_PING_PATH: percorso di ping su HTTP per il riscaldamento del sito. Aggiungere questa impostazione dell'app specificando un percorso personalizzato che inizi con una barra come valore. Un esempio è /statuscheck. Il valore predefinito è /.
• WEBSITE_SWAP_WARMUP_PING_STATUSES: codici di risposta HTTP validi per l'operazione di preparazione. Aggiungere questa impostazione dell'app con un elenco di codici HTTP separati da virgole. Un esempio è 200,202. Se il codice di stato restituito non è presente nell'elenco, l'operazione preliminare di preparazione e l'operazione di scambio vengono arrestate. Per impostazione predefinita, sono validi tutti i codici di risposta.
• WEBSITE_WARMUP_PATH: percorso relativo nel sito di cui deve essere eseguito il ping ogni volta che il sito viene riavviato (non solo durante gli scambi di slot). I valori di esempio includono /statuscheck o il percorso radice, /.

In caso di problemi, vedere Risolvere i problemi relativi agli scambi.

Monitorare uno scambio

Se il completamento dell'operazione di scambio richiede molto tempo, è possibile ottenere informazioni sull'operazione di scambio nel log attività.

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2023-07-07 | where{$_.OperationName -eq 'Swap Web App Slots'}

Indirizzare automaticamente il traffico di produzione

Per impostazione predefinita, tutte le richieste client all'URL di produzione dell'app (http://<app_name>.azurewebsites.net) vengono indirizzate allo slot di produzione. È possibile instradare una parte del traffico a un altro slot. Questa funzionalità è utile se è necessario il feedback degli utenti su un nuovo aggiornamento, ma non si è ancora pronti per rilasciarlo in produzione.

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

Dopo che un client viene indirizzato automaticamente a uno slot specifico, viene "aggiunto" a tale slot per un'ora o fino a quando i cookie non vengono eliminati. Nel browser client è possibile visualizzare lo slot a cui è associata la sessione esaminando il cookie x-ms-routing-name nelle intestazioni HTTP. Per una richiesta indirizzata allo slot di "staging" il cookie è x-ms-routing-name=staging. Per una richiesta indirizzata allo slot di produzione il cookie è x-ms-routing-name=self.

Indirizzare automaticamente il traffico di produzione

Oltre al routing automatico del traffico, il servizio app può eseguire il routing delle richieste a uno slot specifico. Ciò è utile quando si vuole che gli utenti possano acconsentire esplicitamente o rifiutare esplicitamente l'app beta. Per indirizzare manualmente il traffico di produzione, si usa il parametro di query x-ms-routing-name.

Ad esempio, per consentire agli utenti di rifiutare esplicitamente l'app beta, è possibile inserire nella pagina Web questo collegamento:

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

La stringa x-ms-routing-name=self specifica lo slot di produzione. Dopo che il browser client avrà eseguito l’accesso al collegamento, verrà reindirizzato allo slot di produzione. Ogni richiesta successiva sarà associata al cookie x-ms-routing-name=self, che aggiungerà la sessione allo slot di produzione.

Per consentire agli utenti di acconsentire esplicitamente all'app beta, impostare lo stesso parametro di query sul nome dello slot non di produzione. Ecco un esempio:

<webappname>.azurewebsites.net/?x-ms-routing-name=staging

Per impostazione predefinita, ai nuovi slot viene assegnata una regola di routing di 0%, visualizzata in grigio. Quando si imposta questo valore 0% in modo esplicito su (visualizzato in testo nero), gli utenti possono accedere manualmente allo slot di staging usando il x-ms-routing-name parametro di query. Gli utenti, tuttavia, non verranno indirizzati automaticamente allo slot perché la percentuale di routing è impostata su 0. Si tratta di uno scenario avanzato, in cui è possibile "nascondere" lo slot di staging dal pubblico consentendo ai team interni di testare le modifiche nello slot.

Eliminare uno slot

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

Automatizzare con i modelli di Resource Manager

I modelli di Azure Resource Manager sono file JSON dichiarativi usati per automatizzare la distribuzione e la configurazione delle risorse di Azure. Per scambiare gli slot usando i modelli di Resource Manager, impostare due proprietà nelle risorse Microsoft.Web/sites/slots e Microsoft.Web/sites :

• buildVersion: si tratta di una proprietà stringa che rappresenta la versione corrente dell'app distribuita nello slot. Ad esempio: "v1", "1.0.0.1" o "2019-09-20T11:53:25.2887393-07:00".
• targetBuildVersion: si tratta di una proprietà stringa che specifica quale buildVersion deve essere lo slot. Se l'oggetto targetBuildVersion non è uguale all'oggetto corrente buildVersion, attiva l'operazione di scambio trovando lo slot con l'oggetto specificato buildVersion.

Modello di Resource Manager di esempio

Il modello di Resource Manager seguente scambia due slot aggiornando lo buildVersionstaging slot e impostando nello targetBuildVersion slot di produzione. Si presuppone che sia stato creato uno slot denominato staging.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "my_site_name": {
            "defaultValue": "SwapAPIDemo",
            "type": "String"
        },
        "sites_buildVersion": {
            "defaultValue": "v1",
            "type": "String"
        }
    },
    "resources": [
        {
            "type": "Microsoft.Web/sites/slots",
            "apiVersion": "2018-02-01",
            "name": "[concat(parameters('my_site_name'), '/staging')]",
            "location": "East US",
            "kind": "app",
            "properties": {
                "buildVersion": "[parameters('sites_buildVersion')]"
            }
        },
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('my_site_name')]",
            "location": "East US",
            "kind": "app",
            "dependsOn": [
                "[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
            ],
            "properties": {
                "targetBuildVersion": "[parameters('sites_buildVersion')]"
            }
        }        
    ]
}

Questo modello di Resource Manager è idempotente, ovvero può essere eseguito ripetutamente e produrre lo stesso stato degli slot. Senza alcuna modifica al modello, le esecuzioni successive dello stesso modello non attivano alcun scambio di slot perché gli slot sono già nello stato desiderato.

Risolvere i problemi relativi agli scambi

Se si verifica un errore durante uno scambio di slot, viene registrato in D:\home\LogFiles\eventlog.xml. Viene anche registrato nel log degli errori specifico dell'applicazione.

Ecco alcuni errori comuni di scambio:

• Viene eseguita una richiesta HTTP alla radice dell'applicazione. L'operazione di scambio attende 90 secondi per ogni richiesta HTTP e riprova fino a cinque volte. Se si verifica il timeout di tutti i tentativi, l'operazione di scambio viene arrestata.

• L'inizializzazione della cache locale potrebbe non riuscire quando il contenuto dell'app supera la quota del disco locale specificata per la cache locale. Per altre informazioni, vedere Panoramica della cache locale.

• Durante il riscaldamento personalizzato, le richieste HTTP vengono effettuate internamente (senza passare attraverso l'URL esterno). Possono avere esito negativo con determinate regole di riscrittura URL in Web.config. Ad esempio, le regole per il reindirizzamento dei nomi di dominio o l'applicazione di HTTPS possono impedire che le richieste di riscaldamento raggiungano il codice dell'app. Per risolvere questo problema, modificare le regole di riscrittura aggiungendo le due condizioni seguenti:

  <conditions>
    <add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Senza un riscaldamento personalizzato, le regole di riscrittura URL possono comunque bloccare le richieste HTTP. Per risolvere questo problema, modificare le regole di riscrittura aggiungendo la condizione seguente:

  <conditions>
    <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
    ...
  </conditions>
  

• Dopo gli scambi di slot, l'app potrebbe riscontrare riavvii imprevisti. Ciò è dovuto al fatto che dopo uno scambio, la configurazione dell'associazione nome host non viene sincronizzata, che da sola non causa i riavvii. Tuttavia, alcuni eventi di archiviazione sottostanti, ad esempio i failover del volume di archiviazione, possono rilevare queste discrepanze e forzare il riavvio di tutti i processi di lavoro. Per ridurre al minimo questi tipi di riavvii, impostare l'impostazione dell'app WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 su tutti gli slot. Tuttavia, questa impostazione dell'app non funziona con le app di Windows Communication Foundation (WCF).

Passaggi successivi

Bloccare l'accesso agli slot di non produzione