Eseguire la migrazione all'ambiente del servizio app di Azure v3

Articolo
08/07/2024

Nota

Sono disponibili due funzionalità di migrazione automatica che consentono di eseguire l'aggiornamento all'ambiente del servizio app v3. Per informazioni su queste funzionalità e scegliere la migliore opzione di migrazione, vedere Albero delle decisioni del percorso di migrazione. Si consideri una delle opzioni automatizzate per un percorso più rapido per Ambiente del servizio app v3.

Se attualmente si usa l'ambiente del servizio app v1 o v2, si avrà l’opportunità di eseguire la migrazione dei carichi di lavoro verso l’Ambiente del servizio app v3. L'Ambiente del servizio app v3 presenta differenze in quanto a vantaggi e funzionalità che forniscono supporto avanzato per i carichi di lavoro e possono ridurre i costi complessivi. È consigliabile usare le funzionalità di migrazione automatizzata se l'ambiente soddisfa i criteri descritti nell'albero delle decisioni del percorso di migrazione.

Se l'ambiente del servizio app non è supportato per le funzionalità di migrazione, è necessario usare uno dei metodi manuali per eseguire la migrazione all'Ambiente del servizio app v3.

Prerequisiti

Scenario: si dispone di un'app in esecuzione nell'Ambiente del servizio app v1 o nell'Ambiente del servizio app v2 ed è necessaria l'app da eseguire nell'Ambiente del servizio app v3.

Per qualsiasi metodo di migrazione che non usa le funzionalità di migrazione automatizzata, è necessario creare la risorsa Ambiente del servizio app v3 e una nuova subnet usando il metodo preferito.

Modifiche alla rete tra l'Ambiente del servizio app v1/v2 e l'Ambiente del servizio app v3 comportano nuovi indirizzi IP aggiuntivi (e per ambienti con connessione Internet). È necessario aggiornare qualsiasi infrastruttura che si basa su questi indirizzi IP. Assicurarsi di tenere conto delle modifiche alle dipendenze in ingresso, come ad esempio la porta di Azure Load Balancer.

Più Ambienti del servizio app non possono esistere in una singola subnet. Se è necessario usare la subnet esistente per la nuova risorsa Ambiente del servizio app v3, è necessario eliminare l'Ambiente del servizio app esistente prima di crearne uno nuovo. Per questo scenario, è consigliabile eseguire il backup delle app e quindi ripristinarle nel nuovo ambiente dopo aver creato e configurato l'ambiente. Questo processo causa tempi di inattività dell'applicazione a causa del tempo necessario per:

Eliminare l'ambiente precedente.
Creare la risorsa Ambiente del servizio app v3.
Configurare qualsiasi infrastruttura e risorse connesse per lavorare con il nuovo ambiente.
Distribuire le app nel nuovo ambiente.

Elenco di controllo prima della migrazione delle app

Creare una risorsa Ambiente del servizio app v3.
Aggiornare eventuali dipendenze di rete con gli indirizzi IP associati al nuovo ambiente.
Pianificare il tempo di inattività (se applicabile).
Decidere un processo per la ricreazione delle app nel nuovo ambiente.

Ridimensionare l'ambiente

L'Ambiente del servizio app v3 usa piani di servizio app di Azure isolato v2 a prezzi e dimensioni diverse rispetto ai piani isolati. Esaminare i dettagli dei prezzi per comprendere come ridimensionare il nuovo ambiente per garantire la capacità appropriata. Non esiste alcuna differenza nel modo in cui si creano piani di Servizio app per l'Ambiente del servizio app v3 rispetto alle versioni precedenti.

Calcolare backup e ripristino

È possibile usare la funzionalità di backup e ripristino per mantenere la configurazione dell'app, il contenuto dei file e il database connessi all'app quando si esegue la migrazione al nuovo ambiente.

È necessario configurare backup personalizzati per le app per ripristinarle nell'Ambiente del servizio app v3. Il backup automatico non supporta il ripristino in versioni diverse dell'Ambiente del servizio app. Per altre informazioni sui backup personalizzati, vedere Backup automatici e personalizzati. Screenshot che mostra le opzioni per la configurazione di backup personalizzati per un'app del servizio app.

È possibile selezionare un backup personalizzato e ripristinarlo nel servizio app nella risorsa Ambiente del servizio app v3. È necessario creare il piano di servizio app in cui si eseguirà il ripristino prima di ripristinare l'app. È possibile scegliere di ripristinare il backup nello slot di produzione, uno slot esistente o un nuovo slot creato durante il processo di ripristino.

Screenshot che mostra come usare un backup per ripristinare un'app del servizio app nell'Ambiente del servizio app v3.

Vantaggi	Limiti
Rapido: l'operazione richiede solo da 5 a 10 minuti per ogni app.	Il supporto è limitato a determinati tipi di database.
È possibile ripristinare più app contemporaneamente. (È necessario configurare la ripresa per ogni singola app.)	L'ambiente precedente, il nuovo ambiente e le risorse di supporto, ad esempio app, database, account di archiviazione e contenitori, devono trovarsi nella stessa sottoscrizione.
Per i database MySQL in-app viene automaticamente eseguito un backup senza alcuna configurazione.	È possibile eseguire il backup di un massimo di 10 GB di contenuto del database e dell'app. Il backup del database può contenere fino a 4 GB di tale contenuto. Se la dimensione del backup supera questo limite, verrà visualizzato un messaggio di errore.
È possibile ripristinare l'app in uno snapshot di uno stato precedente.	L'uso di un account di archiviazione abilitato per un firewall come destinazione per i backup non è supportato.
È possibile eseguire l'integrazione con Gestione traffico di Azure e gateway applicazione di Azure per distribuire il traffico tra gli ambienti precedenti e nuovi.	L'uso di un account di archiviazione con endpoint privati per il backup e il ripristino non è supportato.
È possibile creare app Web vuote in cui eseguire il ripristino nel nuovo ambiente prima di iniziare il ripristino, per velocizzare il processo.	Sono supportati solo i backup personalizzati.

Clonare l’app nell'ambiente del servizio app v3

Clonare le app è un'altra funzionalità che è possibile usare per ottenere le app di Windows nell'Ambiente del servizio app v3. Le limitazioni per la clonazione delle app sono identiche a quelle per la funzionalità di backup del servizio app. Per altre informazioni, vedere Eseguire il backup dell’app nel Servizio app di Azure.

Nota

La clonazione delle app è supportata solo per i piani di servizio app in Windows.

È consigliabile usare questa soluzione per gli utenti che usano il servizio app in Windows e non possono eseguire la migrazione usando la funzionalità di migrazione. È necessario configurare la nuova risorsa Ambiente del servizio app v3 prima di clonare tutte le app. La clonazione di un app può richiedere fino a 30 minuti.

Per clonare un'app usando PowerShell, vedere le istruzioni.

Per clonare un'app usando il portale di Azure:

Nel portale di Azure, passare all'istanza esistente del piano Servizio app. In Strumenti di sviluppo, selezionare Clona app.
Compilare i campi obbligatori usando i dettagli per la nuova risorsa Ambiente del servizio app v3:
1. In Gruppo di risorse, selezionare un gruppo di risorse esistente o crearne uno nuovo.
2. Per Nome, indicare il nome dell’app. Può essere uguale all'app precedente, ma l'URL predefinito del sito per il nuovo ambiente sarà diverso. È necessario aggiornare eventuali risorse DNS personalizzate o connesse in modo che puntino al nuovo URL.
3. Per Area, selezionare il nome del proprio Ambiente del servizio app v3.
4. Se si vuole clonare l'origine di distribuzione, selezionare la casella di controllo Clona origine distribuzione.
5. Per Piano di Windows, è possibile usare un piano di Servizio app esistente dal nuovo ambiente se ne è già stato creato uno, oppure è possibile creare un nuovo piano. I piani di servizio app disponibili nella nuova risorsa Ambiente del servizio app v3 vengono visualizzati nell'elenco a discesa.
6. Per SKU e dimensioni, modificare la memoria e la CPU in base alle esigenze usando una delle opzioni Isolate v2, se si sta creando un nuovo piano di servizio app. L'ambiente del servizio app v3 usa piani Isolati v2, che hanno più memoria e CPU per ogni dimensione di istanza corrispondente rispetto ai piani Isolati. Per ulteriori informazioni, vedere la pagina relativa ai dettagli sui prezzi dell’ambiente del servizio app di Azure v3.

Screenshot che mostra le opzioni per la clonazione di un'app nell'Ambiente del servizio app v3 tramite il portale.

Vantaggi	Limiti
È possibile automatizzare la clonazione usando PowerShell.	Supportato solo per i piani di Servizio app in Windows.
È possibile clonare più app contemporaneamente. (La clonazione deve essere configurata per ogni app singolarmente o tramite uno script.)	Il supporto è limitato a determinati tipi di database.
È possibile eseguire l'integrazione con Gestione traffico di Azure e gateway applicazione di Azure per distribuire il traffico tra gli ambienti precedenti e nuovi.	L'ambiente precedente, il nuovo ambiente e le risorse di supporto, ad esempio app, database, account di archiviazione e contenitori, devono trovarsi nella stessa sottoscrizione.

Creare le app manualmente nell’Ambiente del servizio app v3

Se la funzionalità di migrazione non supporta le app o si vuole eseguire una route più manuale, è possibile distribuire le app seguendo lo stesso processo usato per l'ambiente del Servizio app esistente.

È possibile esportare modelli di Azure Resource Manager (modelli ARM) delle app esistenti, dei piani di servizio app e di qualsiasi altra risorsa supportata e distribuirli in o con il nuovo ambiente. Per esportare un modello solo per un'app, passare al piano di Servizio app. Nel menu a sinistra, in Automazione, selezionare Esporta modello.

Screenshot dell'opzione per esportare un modello nel riquadro sinistro del portale di Azure.

È anche possibile esportare modelli per più risorse direttamente dal gruppo di risorse. Passare al gruppo di risorse, selezionare le risorse per cui si vuole un modello e quindi selezionare Esporta modello.

Screenshot dell'opzione per l'esportazione di un modello per le risorse da un gruppo di risorse.

Per ottenere le app nell'Ambiente del servizio app v3, sono necessarie le modifiche iniziali seguenti ai modelli ARM:

Aggiornare i parametri sku per un piano di Servizio app a un piano Isolato v2:

"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-02-01",
"name": "[parameters('serverfarm_name')]",
"location": "East US",
"sku": {
    "name": "I1v2",
    "tier": "IsolatedV2",
    "size": "I1v2",
    "family": "Iv2",
    "capacity": 1
},

Aggiornare il parametro del piano di Servizio app (serverfarm) in cui verrà distribuita l'app nel piano associato all'Ambiente del servizio app v3.
Aggiornare il profilo dell'ambiente di hosting (hostingEnvironmentProfile) al nuovo ID risorsa Ambiente del servizio app v3.

Un'esportazione di modelli di ARM include tutte le proprietà esposte dai provider di risorse per le risorse. Rimuovere tutte le proprietà non necessarie, come ad esempio le proprietà che puntano al dominio dell'app precedente. Ad esempio, è possibile semplificare la risorsa sites all'esempio seguente:

"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"name": "[parameters('site_name')]",
"location": "East US",
"dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]"
],
"properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]",
    "siteConfig": {
        "linuxFxVersion": "NODE|14-lts"
     },
    "hostingEnvironmentProfile": {
        "id": "[parameters('hostingEnvironments_externalid')]"
    }
}

Potrebbero essere necessarie altre modifiche, a seconda della configurazione dell'app. Ad esempio, se si usano identità gestite assegnate dal sistema e gli stessi nomi delle applicazioni per gli ambienti vecchi e nuovi, si potrebbero verificare dei conflitti. Per risolvere questo conflitto ed evitare tempi di inattività, è possibile usare un'identità gestita assegnata dall'utente.

È possibile distribuire i modelli ARM usando il portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell.

Eseguire la migrazione manualmente

La funzionalità di migrazione sul posto automatizza la migrazione all'Ambiente del servizio app v3 e trasferisce tutte le app al nuovo ambiente. Si prevede circa un'ora di tempo di inattività durante questa migrazione. Se le app non possono avere tempi di inattività, è consigliabile usare la funzionalità di migrazione side-by-side, che è un'opzione di migrazione senza tempi di inattività poiché il nuovo ambiente viene creato in una subnet diversa. Se si sceglie anche di non usare la funzionalità di migrazione side-by-side, è possibile usare una delle opzioni manuali per ricreare le app nell'ambiente del servizio app v3.

È possibile distribuire il traffico tra gli ambienti precedenti e nuovi usando il Gateway applicazione. Se si usa un Ambiente del servizio app con bilanciamento del carico interno (ILB), creare un'istanza del gateway applicazione di Azure con un pool back-end aggiuntivo per distribuire il traffico tra gli ambienti. Per informazioni sugli ambienti del servizio app con bilanciamento del carico interno e sugli ambienti del servizio app con connessione Internet, vedere Integrazione del gateway applicazione.

È anche possibile usare servizi come Frontdoor di Azure, Rete per la distribuzione di contenuti di Azure e Gestione traffico di Azure per distribuire il traffico tra ambienti. L'uso di questi servizi consente di testare il nuovo ambiente in modo controllato e consente di passare al nuovo ambiente in base al proprio ritmo.

Dopo aver completato la migrazione e tutti i test con il nuovo ambiente, eliminare l'Ambiente del servizio app precedente, le app presenti e tutte le risorse di supporto non più necessarie. I costi delle risorse che non vengono eliminate continueranno a essere addebitati.

Domande frequenti

Come è possibile sapere se è necessario eseguire la migrazione all'Ambiente del servizio app v3 usando una delle opzioni manuali?
Per informazioni sulla scelta dell'opzione di migrazione più adatta, vedere Albero delle decisioni del percorso di migrazione. Se l’ambiente soddisfa i criteri descritti nell’albero decisionale del percorso di migrazione, è consigliabile utilizzare una delle funzionalità di migrazione automatizzate per un percorso più rapido verso l’Ambiente del servizio app v3. Si consiglia di utilizzare la migrazione manuale nel caso in cui sia necessario spostare lentamente le app nel nuovo ambiente e convalidare l'intero processo.
Durante la migrazione vi sarà un periodo di inattività?
Il tempo di inattività dipende dal processo di migrazione. Se si dispone di un Ambiente del servizio app diverso a cui è possibile indirizzare il traffico durante la migrazione, o se è possibile usare una subnet diversa per creare il nuovo ambiente, non si avranno tempi di inattività. Se è necessario usare la stessa subnet, si verifica un tempo di inattività durante l'eliminazione dell'ambiente precedente, creare la risorsa Ambiente del servizio app v3, creare i nuovi piani di servizio app, ricreare le app e aggiornare tutte le risorse che usano i nuovi indirizzi IP.
È necessario modificare qualcosa sulle app affinché vengano eseguite nell'Ambiente del servizio app v3?
No. Le app eseguite nell'Ambiente del servizio app v1 e v2 non devono dover apportare modifiche per l'esecuzione nell'Ambiente del servizio app v3. Se si usa IP SSL, è necessario rimuovere le associazioni IP SSL prima della migrazione.
Cosa accade se l'ambiente del servizio app presenta un suffisso di dominio personalizzato?
La funzionalità di migrazione supporta questo scenario di migrazione. È possibile eseguire la migrazione usando un metodo manuale se non si vuole usare la funzionalità di migrazione. È possibile configurare il suffisso di dominio personalizzato durante la creazione della risorsa Ambiente del servizio app v3 o in qualsiasi momento successivo.
Cosa accade se la risorsa Ambiente del servizio app v2 viene aggiunta alla zona?
L'aggiunta della zona non è una funzionalità supportata nell'Ambiente del servizio app v3. È possibile scegliere di abilitare la ridondanza della zona durante la creazione della risorsa Ambiente del servizio app v3.
Quali proprietà dell'ambiente del servizio app cambieranno?
Esaminare le differenze di funzionalità tra l'Ambiente del servizio app v3 e le versioni precedenti. Per gli ambienti del servizio app con bilanciamento del carico interno si mantiene lo stesso indirizzo IP con bilanciamento del carico interno. Per gli ambienti del servizio app con connessione Internet, l'indirizzo IP pubblico e l'indirizzo IP in uscita cambiano.

Per gli ambienti del Servizio app con connessione Internet, in precedenza era presente un singolo indirizzo IP per sia in ingresso che in uscita. Per l'ambiente del servizio app v3, sono separati. Per ulteriori informazioni, vedere Rete per l'ambiente del servizio app v3.
Sono supportati il backup e il ripristino per lo spostamento delle app dall'ambiente del servizio app v2 a v3? La funzionalità di backup e ripristino supporta il ripristino delle app tra le versioni dell'Ambiente del servizio app, purché si usi un backup personalizzato per il ripristino. Il backup automatico non supporta il ripristino in versioni diverse dell'Ambiente del servizio app.
Cosa accadrà alle risorse dell'Ambiente del servizio app v1 e v2 dopo il 31 agosto 2024?
Dopo il 31, 2024 agosto 2024, se non si esegue la migrazione all'ambiente del servizio app v3, le risorse dell’Ambiente del servizio app v1 e v2 e le app distribuite al loro interno non saranno più disponibili.

L'ambiente del servizio app v1 e la versione 2 sono ospitati in unità di scala del servizio app eseguite nell’architettura dei Servizi cloud di Azure (versione classica). Poiché questa architettura verrà ritirata il 31 agosto 2024, l'Ambiente del servizio app v1 e v2 non saranno disponibili dopo tale data. Eseguire la migrazione all'Ambiente del servizio app v3 per mantenere le app in esecuzione o salvare o eseguire il backup di risorse o dati che è necessario gestire.