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

Articolo
03/06/2024

Nota

Sono disponibili due funzionalità di migrazione automatica che consentono di eseguire l'aggiornamento a ambiente del servizio app v3. Per altre informazioni su queste funzionalità e per informazioni sulla scelta dell'opzione di migrazione più adatta, 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 ambiente del servizio app v1 o v2, è possibile eseguire la migrazione dei carichi di lavoro a ambiente del servizio app v3. ambiente del servizio app v3 presenta vantaggi e differenze di funzionalità che forniscono supporto avanzato per i carichi di lavoro e possono ridurre i costi complessivi. È consigliabile usare le funzionalità di migrazione automatica se l'ambiente soddisfa i criteri descritti nell'albero delle decisioni del percorso di migrazione.

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

Prerequisiti

Scenario: è disponibile un'app in esecuzione in ambiente del servizio app v1 o ambiente del servizio app v2 ed è necessario eseguire l'app in 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.

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

Più ambiente 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 il 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 e ridimensionare l'ambiente

ambiente del servizio app v3 usa piani di servizio isolato v2 app Azure prezzi e ridimensionati in modo diverso rispetto ai piani isolati. Esaminare i dettagli sui prezzi per comprendere come si è nuovi ambienti devono essere ridimensionati e ridimensionati per garantire la capacità appropriata. Non c'è differenza nel modo in cui si creano piani di servizio app per ambiente del servizio app v3 rispetto alle versioni precedenti.

Valutare il backup e il 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 ripristinarli in ambiente del servizio app v3. Il backup automatico non supporta il ripristino in versioni di ambiente del servizio app diverse. Per altre informazioni sui backup personalizzati, vedere Backup automatici e backup personalizzati. Screenshot that shows options for configuring custom backups for an App Service app.

È possibile selezionare un backup personalizzato e ripristinarlo in 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 that shows how to use a backup to restore an App Service app in App Service Environment 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 il ripristino per ogni app singolarmente.	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. Fino a 4 GB di tale contenuto possono essere il backup del database. 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 il firewall come destinazione per i backup non è supportato.
È possibile eseguire l'integrazione con Gestione traffico di Azure e app Azure gateway per distribuire il traffico tra ambienti vecchi 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 in ambiente del servizio app v3

La clonazione delle app è un'altra funzionalità che puoi usare per ottenere le tue app di Windows in ambiente del servizio app v3. Le limitazioni per la clonazione delle app sono identiche a quelle per la funzionalità di backup servizio app. Per altre informazioni, vedere Eseguire il backup di un'app nel servizio app 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 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 le app. Il completamento della 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 al piano di servizio app esistente. In Strumenti di sviluppo selezionare Clona app.
Compilare i campi obbligatori usando i dettagli per la nuova risorsa ambiente del servizio app v3:
1. Per Gruppo di risorse selezionare un gruppo di risorse esistente o crearne uno nuovo.
2. In Nome assegnare un nome all'app. Questo nome 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 usare il nome ambiente del servizio app v3.
4. Se si vuole clonare l'origine di distribuzione, selezionare la casella di controllo Clona origine distribuzione .
5. Per Windows Plan è 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 Isolated v2 se si sta creando un nuovo piano di servizio app. ambiente del servizio app v3 usa piani Isolated v2, che hanno più memoria e CPU per ogni dimensione di istanza corrispondente rispetto ai piani isolati. Per altre informazioni, vedere i dettagli sui prezzi di ambiente del servizio app v3.

Screenshot that shows options for cloning an app to App Service Environment v3 by using the portal.

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 app Azure gateway per distribuire il traffico tra ambienti vecchi 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 manualmente le app in 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 il ambiente del servizio app esistente.

È possibile esportare modelli di Azure Resource Manager (modelli ARM) delle app esistenti, dei piani 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. In Automazione selezionare Esporta modello.

Screenshot of the option to export a template on the left pane of the Azure portal.

È 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 of the option for exporting a template for resources from a resource group.

Per ottenere le app in ambiente del servizio app v3, sono necessarie le modifiche iniziali seguenti ai modelli di Resource Manager:

Aggiornare sku i parametri per un piano 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 servizio app piano (serverfarm) in cui verrà distribuita l'app nel piano associato a ambiente del servizio app v3.
Aggiornare il parametro del profilo di ambiente host (hostingEnvironmentProfile) al nuovo ID risorsa ambiente del servizio app v3.

Un'esportazione di modelli di Resource Manager include tutte le proprietà esposte dai provider di risorse per le risorse. Rimuovere tutte le proprietà nonquired, ad esempio le proprietà che puntano al dominio dell'app precedente. Ad esempio, è possibile semplificare la sites risorsa con l'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, è possibile che si verifichino conflitti. Per risolvere questo conflitto ed evitare tempi di inattività, è possibile usare un'identità gestita assegnata dall'utente.

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

Eseguire la migrazione manualmente

La funzionalità di migrazione sul posto automatizza la migrazione a ambiente del servizio app v3 e trasferisce tutte le app al nuovo ambiente. Durante questa migrazione sono presenti circa un'ora di inattività. Se le app non possono avere tempi di inattività, è consigliabile usare la funzionalità di migrazione side-by-side, ovvero un'opzione di migrazione senza tempi di inattività perché 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 in ambiente del servizio app v3.

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

È anche possibile usare servizi come Frontdoor di Azure, Azure rete per la distribuzione di contenuti 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 il vecchio ambiente del servizio app, le app presenti e tutte le risorse di supporto non più necessarie. Si continuano a essere addebitati i costi per le risorse che non vengono eliminate.

Domande frequenti

Ricerca per categorie sapere se è necessario eseguire la migrazione a 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 delle decisioni del percorso di migrazione, è consigliabile usare una delle funzionalità di migrazione automatizzate per un percorso più rapido per ambiente del servizio app v3. La migrazione manuale è consigliata se è 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 che è possibile indirizzare il traffico a 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 verificano tempi 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 per renderle eseguibili in ambiente del servizio app v3?
No. Le app eseguite in ambiente del servizio app v1 e v2 non devono dover apportare modifiche per l'esecuzione in ambiente del servizio app v3. Se si usa SSL IP, è necessario rimuovere le associazioni SSL IP 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 è bloccata?
L'aggiunta della zona non è una funzionalità supportata in 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à del ambiente del servizio app cambieranno?
Esaminare le differenze di funzionalità tra ambiente del servizio app v3 e le versioni precedenti. Per le ambiente del servizio app con bilanciamento del carico interno, mantenere lo stesso indirizzo IP del servizio di bilanciamento del carico interno. Per le ambiente del servizio app con connessione Internet, l'indirizzo IP pubblico e l'indirizzo IP in uscita cambiano.

Per le ambiente del servizio app con connessione Internet, in precedenza era presente un singolo 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 ambiente del servizio app versioni, purché si usi un backup personalizzato per il ripristino. Il backup automatico non supporta il ripristino a versioni ambiente del servizio app diverse.
Cosa accadrà alle risorse ambiente del servizio app v1 e v2 dopo il 31 agosto 2024?
Dopo il 31 agosto 2024, se non è stata eseguita la migrazione a ambiente del servizio app v3, le risorse ambiente del servizio app v1 e v2 e le app distribuite in essi non saranno più disponibili.

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