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 nel servizio app Azure, è possibile usare uno slot di distribuzione separato anziché lo slot di produzione predefinito. Questo approccio è disponibile se si utilizza un piano App Service nei livelli Standard, Premium o Isolato. 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 presenta i seguenti vantaggi:

• È possibile convalidare le modifiche dell'app prima di scambiare lo slot nell'ambiente di produzione.

• È possibile assicurarsi che tutte le istanze dello slot vengano riscaldate prima di scambiarla in produzione. Questo approccio elimina i tempi di inattività quando si distribuisce l'app. Il reindirizzamento del traffico è facile. Nessuna richiesta viene eliminata a causa di operazioni di scambio.

  È possibile automatizzare l'intero flusso di lavoro tramite la configurazione dello scambio automatico quando non è necessaria la convalida preliminare.

• Dopo uno scambio, lo slot con l'app gestita temporaneamente include l'app di produzione precedente. Se le modifiche scambiate nello slot di produzione non sono come previsto, è possibile eseguire lo stesso scambio immediatamente per ottenere l'ultimo sito valido noto.

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

Per ridimensionare l'app a un livello diverso, assicurarsi che il livello di destinazione supporti il numero di slot già usati dall'app. Ad esempio, se l'app ha più di cinque slot, non è possibile passare al livello Standard. Il livello Standard supporta solo cinque slot di distribuzione.

Il video seguente integra i passaggi descritti in questo articolo illustrando come configurare gli ambienti di gestione temporanea nel servizio app di Azure.

Prerequisiti

• Autorizzazioni per eseguire l'operazione slot desiderata. Per informazioni sulle autorizzazioni necessarie, vedere Operazioni del provider di risorse. Cercare lo slot, ad esempio.

Aggiungi uno slot

Per abilitare più slot di distribuzione, l'app deve essere in esecuzione nel livello 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. L'articolo Ottenere un profilo di pubblicazione da Azure App Service può fornire le informazioni necessarie per la distribuzione nello slot. Visual Studio può importare il profilo 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 viene troncato a 40 caratteri. Il nome del sito combinato e il nome dello slot devono essere inferiori a 59 caratteri.

Comprendere cosa accade durante uno scambio

Passaggi dell'operazione di scambio

Quando si scambiano due slot, 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 specifiche dello slot e stringhe di connessione, se applicabile
   • Impostazioni di distribuzione continua , se abilitate
   • Impostazioni di autenticazione del servizio app , se abilitate

   Quando una delle impostazioni viene applicata allo slot di origine, la modifica attiva il riavvio di tutte le istanze nello slot di origine. Durante uno scambio con anteprima, questa azione contrassegna la fine della prima fase. L'operazione di scambio viene sospesa. È 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'inizializzazione dell'applicazione personalizzata 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 tutte le istanze nello slot di origine vengono riscaldate correttamente, scambiare i due slot cambiando le regole di routing. 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 contiene l'app pre-scambio che era precedentemente nello slot di destinazione, esegui la stessa operazione applicando tutte le impostazioni e riavviando le istanze.

In qualsiasi momento dell'operazione di scambio, tutto il lavoro 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 dal fatto che lo scambio abbia esito positivo o negativo. Per scambiare uno slot di staging con lo slot di produzione, assicurarsi che lo slot di produzione sia sempre lo slot di destinazione. In questo modo, l'operazione di scambio non influisce sull'app di produzione.

Passaggi per rendere uno slot non scambiabile

Quando si clona una configurazione da un altro slot di distribuzione, la configurazione clonata è modificabile. Alcuni elementi di configurazione seguono il contenuto durante uno scambio (non sono specifici dello slot). Altri elementi di configurazione rimangono nello stesso slot dopo uno scambio (sono specifici dello slot).

Quando si scambiano gli slot, queste impostazioni vengono scambiate:

• Stack di linguaggio e versione, 32 bit e 64 bit
• Impostazioni dell'app (possono essere configurate per essere associate a uno slot)
• Stringhe di connessione (possono essere configurate per essere associate a uno slot)
• Account di archiviazione montati (possono essere configurati per essere collegati a uno slot)
• Mapping del gestore
• Certificati pubblici
• Contenuto dei processi Web
• Connessioni ibride (attualmente)
• Endpoint di servizio (attualmente)
• Rete per la distribuzione di contenuti di Azure (attualmente)
• Mapping dei percorsi

Quando si scambiano gli slot, queste impostazioni non vengono scambiate:

• Impostazioni generali non menzionate nell'elenco precedente
• 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 create da Service Connector

Per configurare un'impostazione dell'app o una stringa di connessione per mantenere uno slot specifico che non viene scambiato:

1. Passare a Impostazioni>Variabile di ambiente per lo slot.

2. Aggiungere o modificare un'impostazione e quindi selezionare Impostazione slot di distribuzione. La selezione di questa casella di controllo indica al servizio app che l'impostazione non è scambiabile.

3. Selezionare Applica.

Scambiare gli slot di distribuzione

È possibile scambiare gli slot di distribuzione nella pagina Slot di distribuzione e Panoramica dell'app.

Prima di scambiare un'app da uno slot di distribuzione nell'ambiente di produzione, assicurarsi che l'ambiente di produzione sia lo slot di destinazione e che tutte le impostazioni nello slot di origine siano configurate esattamente come si vogliono avere nell'ambiente di produzione.

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 di swap più avanti in questo articolo.

Scambia con anteprima (scambio a 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, il Servizio app di Azure 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 di swap più avanti in questo articolo.

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. Con lo scambio automatico è abilitato da uno slot in produzione ogni volta che si esegue il push delle modifiche di codice in tale slot, il Servizio app scambia automaticamente l'app in produzione dopo il riscaldamento 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 di swap più avanti in questo articolo.

Specificare il riscaldamento personalizzato

Alcune app potrebbero richiedere azioni preliminari personalizzate prima dello scambio. È possibile specificare queste azioni personalizzate usando l'elemento applicationInitialization di configurazione in Web.config. L'operazione di scambio attende il completamento del riscaldamento personalizzato prima dello scambio con lo slot di destinazione. Ecco un frammento di esempio Web.config :

<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 il post di blog Errori di scambio degli slot di distribuzione più comuni e come risolverli.

È anche possibile personalizzare il comportamento di riscaldamento usando 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, le operazioni di riscaldamento e 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, /.

L'elemento <applicationInitialization> di configurazione fa parte di ogni avvio dell'app, mentre le impostazioni dell'app per il comportamento di riscaldamento si applicano solo agli scambi di slot.

In caso di problemi, vedere Risolvere i problemi di swap più avanti in questo articolo.

Monitorare uno scambio

Se l'operazione di scambio richiede molto tempo per il completamento, è 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 2025-01-01 | 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 vengono instradate all'ambiente di produzione. È possibile instradare una parte del traffico a un altro slot. Questa funzionalità è utile se sono necessari commenti e suggerimenti degli utenti per un nuovo aggiornamento, ma non si è pronti per rilasciarlo nell'ambiente di 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='<URL>';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. Una richiesta indirizzata allo slot di staging ha 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. Questa opzione è utile quando vuoi 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 permettere 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, i nuovi slot hanno una regola di routing di 0%, visualizzata in grigio. Quando si imposta questo valore in modo esplicito su 0% (visualizzato in testo nero), gli utenti possono accedere manualmente allo slot di staging usando il parametro di query x-ms-routing-name. Non verranno instradati automaticamente allo slot perché la percentuale di routing è impostata su 0. Questa configurazione è 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 per automatizzare la distribuzione e la configurazione delle risorse di Azure. Per scambiare gli slot utilizzando i modelli di Resource Manager, impostare due proprietà sulle risorse Microsoft.Web/sites/slots e Microsoft.Web/sites.

• buildVersion: 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: proprietà stringa che specifica quale buildVersion valore deve avere lo slot. Se il targetBuildVersion valore non è uguale al valore corrente buildVersion , attiva l'operazione di scambio trovando lo slot con il valore specificato buildVersion .

Esempio di modello di Resource Manager

Il modello di Resource Manager seguente scambia due slot aggiornando il buildVersion valore dello staging slot e impostando il targetBuildVersion valore nello slot di produzione. È necessario disporre di 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. È possibile eseguirlo 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, l'errore viene visualizzato 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 del servizio app di Azure.

• Durante un'operazione di aggiornamento del sito, può verificarsi l'errore seguente: "Non è possibile modificare lo slot perché le impostazioni di configurazione sono state preparate per lo scambio". Questo errore può verificarsi se la prima fase di uno scambio in più fasi termina, ma la seconda fase non si è verificata. Può verificarsi anche se uno scambio non è riuscito. Esistono due modi per risolvere questo problema:

  • Annullare l'operazione di scambio, che ripristina lo stato precedente del sito.
  • Completare l'operazione di scambio, che aggiorna il sito al nuovo stato desiderato.

  Per informazioni su come annullare o completare l'operazione di scambio, vedere Scambiare con anteprima (scambio a più fasi) in precedenza in questo articolo.

• 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. I riavvii si verificano perché dopo uno scambio, la configurazione dell'associazione del nome host non viene sincronizzata. Questa situazione da sola non causa riavvii. Tuttavia, alcuni eventi di archiviazione sottostanti, ad esempio i failover del volume di archiviazione, potrebbero rilevare queste discrepanze e forzare il riavvio di tutti i processi di lavoro.

  Per ridurre al minimo questi tipi di riavvii, impostare l'WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1impostazione dell'app su tutti gli slot. Tuttavia, questa impostazione dell'app non funziona con le app windows Communication Foundation (WCF).

Passaggio successivo