Usare la funzionalità di migrazione side-by-side per eseguire la migrazione di ambiente del servizio app v2 a ambiente del servizio app v3
Nota
La funzionalità di migrazione descritta in questo articolo viene usata per la migrazione automatica side-by-side (subnet diversa) di ambiente del servizio app v2 a ambiente del servizio app v3.
Per informazioni sulla funzionalità di migrazione sul posto, vedere Eseguire la migrazione a ambiente del servizio app v3 usando la funzionalità di migrazione sul posto. Per informazioni sulle opzioni di migrazione manuale, vedere Opzioni di migrazione manuale. Per informazioni sulla scelta dell'opzione di migrazione più adatta, vedere Albero delle decisioni del percorso di migrazione. Per altre informazioni su ambiente del servizio app v3, vedere panoramica di ambiente del servizio app v3.
È possibile eseguire automaticamente la migrazione ambiente del servizio app v2 a ambiente del servizio app v3 usando la funzionalità di migrazione side-by-side. Per altre informazioni sul processo di migrazione e per verificare se il ambiente del servizio app supporta la migrazione in questo momento, vedere la panoramica della funzionalità di migrazione side-by-side.
Importante
È consigliabile usare questa funzionalità per gli ambienti di sviluppo prima di eseguire la migrazione di ambienti di produzione per evitare problemi imprevisti. Fornire commenti e suggerimenti relativi a questo articolo o alla funzionalità usando i pulsanti nella parte inferiore della pagina.
Prerequisiti
Assicurarsi di comprendere come la migrazione a ambiente del servizio app v3 influisce sulle applicazioni. Esaminare il processo di migrazione per comprendere la sequenza temporale del processo e dove e quando è necessario partecipare. Esaminare anche le domande frequenti, che possono rispondere ad alcune domande.
Assicurarsi che non siano presenti blocchi nella rete virtuale, nei gruppi di risorse, nelle risorse o nella sottoscrizione. Blocca le operazioni della piattaforma durante la migrazione.
Assicurarsi che non siano presenti criteri di Azure che bloccano le azioni necessarie per la migrazione, incluse le modifiche alla subnet e le creazioni delle risorse del servizio app Azure. I criteri che bloccano le modifiche e le creazioni delle risorse possono causare il blocco o l'esito negativo della migrazione.
Poiché il ambiente del servizio app v3 si trova in una subnet diversa nella rete virtuale, è necessario assicurarsi di disporre di una subnet disponibile nella rete virtuale che soddisfi i requisiti della subnet per ambiente del servizio app v3. La subnet selezionata deve anche essere in grado di comunicare con la subnet in cui si trova il ambiente del servizio app esistente. Assicurarsi che non vi sia alcun blocco della comunicazione tra le due subnet. Se non si dispone di una subnet disponibile, è necessario crearne una prima della migrazione. La creazione di una nuova subnet potrebbe comportare l'aumento dello spazio degli indirizzi della rete virtuale. Per altre informazioni, vedere Creare una rete virtuale e una subnet.
Poiché il ridimensionamento è bloccato durante la migrazione, è necessario ridimensionare l'ambiente in base alle dimensioni desiderate prima di avviare la migrazione. Se è necessario ridimensionare l'ambiente dopo la migrazione, è possibile farlo al termine della migrazione.
Seguire i passaggi descritti qui in ordine e come scritto, perché si effettuano chiamate API REST di Azure. È consigliabile usare l'interfaccia della riga di comando di Azure per effettuare queste chiamate API. Per informazioni su altri metodi, vedere Informazioni di riferimento sull'API REST di Azure.
Per questa guida, installare l'interfaccia della riga di comando di Azure o usare Azure Cloud Shell e usare una shell Bash.
Nota
È consigliabile usare una shell Bash per eseguire i comandi indicati in questa guida. I comandi potrebbero non essere compatibili con le convenzioni di PowerShell e i caratteri di escape.
Importante
Durante la migrazione, il portale di Azure potrebbe mostrare informazioni errate sul ambiente del servizio app e sulle app. Non passare all'esperienza di migrazione nel portale di Azure perché la funzionalità di migrazione side-by-side non è disponibile. È consigliabile usare l'interfaccia della riga di comando di Azure per controllare lo stato della migrazione. Per eventuali domande sullo stato della migrazione o delle app, contattare il supporto tecnico.
1. Selezionare la subnet per il nuovo ambiente del servizio app v3
Selezionare una subnet nel ambiente del servizio app v3 che soddisfi i requisiti della subnet per ambiente del servizio app v3. Prendere nota del nome della subnet selezionata. Questa subnet deve essere diversa dalla subnet in cui si trova il ambiente del servizio app esistente.
2. Ottenere l'ID ambiente del servizio app
Eseguire i comandi seguenti per ottenere l'ID ambiente del servizio app e archiviarlo come variabile di ambiente. Sostituire i segnaposto per il nome e i gruppi di risorse con i valori per il ambiente del servizio app di cui si vuole eseguire la migrazione. ASE_RGe VNET_RG sono uguali se la rete virtuale e ambiente del servizio app si trovano nello stesso gruppo di risorse.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
3. Verificare che la migrazione sia supportata
Il comando seguente controlla se il ambiente del servizio app è supportato per la migrazione. Se viene visualizzato un errore o se il ambiente del servizio app si trova in uno stato non integro o sospeso, non è possibile eseguire la migrazione in questo momento. Vedere la sezione relativa alla risoluzione dei problemi per le descrizioni dei potenziali messaggi di errore che è possibile ottenere. Se l'ambiente non è supportato per la migrazione tramite la funzionalità di migrazione side-by-side o si vuole eseguire la migrazione a ambiente del servizio app v3 senza usare la funzionalità di migrazione side-by-side, vedere le opzioni di migrazione manuale. Questo comando convalida anche che il ambiente del servizio app sia nella versione di compilazione supportata per la migrazione. Se il ambiente del servizio app non si trova nella versione di build supportata, è necessario avviare l'aggiornamento manualmente. Per altre informazioni sull'aggiornamento della premigration, vedere Verificare che la migrazione sia supportata usando la funzionalità di migrazione side-by-side per il ambiente del servizio app.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
Se non sono presenti errori, la migrazione è supportata ed è possibile continuare con il passaggio successivo.
Se è necessario avviare un aggiornamento per aggiornare il ambiente del servizio app alla versione di compilazione supportata, che potrebbe richiedere 8-12 ore o più a seconda delle dimensioni dell'ambiente, eseguire il comando seguente. Eseguire questo comando solo se si verifica un errore nel passaggio di convalida e viene richiesto di aggiornare il ambiente del servizio app.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Generare indirizzi IP in uscita per il nuovo ambiente del servizio app v3
Creare un file denominato zoneredundancy.json con i dettagli seguenti per la selezione della ridondanza dell'area e della zona.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
È possibile rendere ridondante la nuova zona ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona. La ridondanza della zona può essere configurata impostando la zoneRedundant proprietà su true. La ridondanza della zona è una configurazione facoltativa. Questa configurazione può essere impostata solo durante la creazione del nuovo ambiente del servizio app v3 e non può essere rimossa in un secondo momento.
Eseguire il comando seguente per creare nuovi indirizzi IP in uscita. Il completamento di questo passaggio richiede circa 15 minuti. Non ridimensionare o apportare modifiche al ambiente del servizio app esistente durante questo periodo.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Eseguire il comando seguente per controllare lo stato di questo passaggio:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Se il passaggio è in corso, si ottiene lo stato .Migrating Dopo aver visualizzato lo stato Ready, eseguire il comando seguente per visualizzare i nuovi indirizzi IP in uscita. Se i nuovi indirizzi IP non vengono visualizzati immediatamente, attendere alcuni minuti e riprovare.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Aggiornare le risorse dipendenti con nuovi indirizzi IP in uscita
Usando i nuovi indirizzi IP in uscita, aggiornare tutte le risorse o i componenti di rete per assicurarsi che il nuovo ambiente funzioni come previsto dopo il completamento della migrazione. È responsabilità dell'utente eseguire eventuali aggiornamenti necessari.
6. Delegare la subnet ambiente del servizio app
ambiente del servizio app v3 richiede che la subnet in cui si trova abbia una singola delega di Microsoft.Web/hostingEnvironments. Le versioni precedenti non richiedono questa delega. È necessario verificare che la subnet sia delegata correttamente e aggiornare la delega (se necessario) prima della migrazione. È possibile aggiornare la delega eseguendo il comando seguente o passando alla subnet nel portale di Azure.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Verificare che non ci siano blocchi nella rete virtuale
I blocchi della rete virtuale bloccano le operazioni della piattaforma durante la migrazione. Se la rete virtuale ha blocchi, è necessario rimuoverli prima della migrazione. Se necessario, è possibile aggiungere nuovamente i blocchi al termine della migrazione.
I blocchi possono esistere in tre ambiti: sottoscrizione, gruppo di risorse e risorsa. Quando si applica un blocco in un ambito padre, tutte le risorse in tale ambito ereditano lo stesso blocco. Se sono stati applicati blocchi nella sottoscrizione, nel gruppo di risorse o nell'ambito delle risorse, è necessario rimuoverli prima della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà dei blocchi, vedere Bloccare le risorse per proteggere l'infrastruttura.
Usare il comando seguente per verificare se la rete virtuale ha blocchi:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Eliminare eventuali blocchi esistenti usando il comando seguente:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Per i comandi correlati per verificare se la sottoscrizione o il gruppo di risorse ha blocchi, vedere le informazioni di riferimento sull'interfaccia della riga di comando di Azure per i blocchi.
8. Preparare le configurazioni
Se il ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurarne uno per la nuova risorsa ambiente del servizio app v3 durante il processo di migrazione. La migrazione non riesce se non si configura un suffisso di dominio personalizzato e ne viene attualmente usata una. Per altre informazioni sui suffissi di dominio personalizzati ambiente del servizio app v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Suffisso di dominio personalizzato per le ambiente del servizio app.
Nota
Se si configura un suffisso di dominio personalizzato, quando si aggiungono le autorizzazioni di rete nell'insieme di credenziali delle chiavi di Azure, assicurarsi che l'insieme di credenziali delle chiavi consenta l'accesso dalla nuova subnet di ambiente del servizio app v3. Se si accede all'insieme di credenziali delle chiavi usando un endpoint privato, assicurarsi di aver configurato correttamente l'accesso privato con la nuova subnet.
Per impostare queste configurazioni, inclusa l'identificazione della subnet selezionata in precedenza, creare un altro file denominato parameters.json con i dettagli seguenti in base allo scenario in uso. Assicurarsi di usare la nuova subnet selezionata per il nuovo ambiente del servizio app v3. Non includere le proprietà per un suffisso di dominio personalizzato se questa funzionalità non si applica alla migrazione. Prestare attenzione al valore della zoneRedundant proprietà e impostarlo sullo stesso valore usato nel passaggio di generazione ip in uscita. È necessario usare lo stesso valore per la ridondanza della zona usata nel passaggio di generazione ip in uscita.
Se si esegue la migrazione senza un suffisso di dominio personalizzato, usare questo codice:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Se si usa un'identità gestita assegnata dall'utente per la configurazione del suffisso di dominio personalizzato, usare questo codice:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Se si usa un'identità gestita assegnata dal sistema per la configurazione del suffisso di dominio personalizzato, usare questo codice:
{
"properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
9. Eseguire la migrazione a ambiente del servizio app v3 e controllare lo stato
Dopo aver completato tutti i passaggi precedenti, è possibile avviare la migrazione. Assicurarsi di comprendere le implicazioni della migrazione.
Il completamento di questo passaggio richiede da tre a sei ore. Durante questo periodo di tempo, non è previsto alcun tempo di inattività dell'applicazione. Il ridimensionamento, le distribuzioni e le modifiche alle ambiente del servizio app esistenti vengono bloccate durante questo passaggio.
Eseguire il comando seguente per avviare la migrazione:
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Eseguire il comando seguente per controllare lo stato della migrazione:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Dopo aver ottenuto lo stato MigrationPendingDnsChange, la migrazione viene completata e si dispone di una risorsa ambiente del servizio app v3. Le app sono ora in esecuzione nel nuovo ambiente e nell'ambiente precedente.
Per ottenere i dettagli del nuovo ambiente, eseguire il comando seguente:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Importante
Durante la migrazione e durante il MigrationPendingDnsChange passaggio, il portale di Azure mostra informazioni errate sul ambiente del servizio app e sulle app. Usare l'interfaccia della riga di comando di Azure per controllare lo stato della migrazione. Per eventuali domande sullo stato della migrazione o delle app, contattare il supporto tecnico.
Nota
Se la migrazione include un suffisso di dominio personalizzato, la configurazione del suffisso di dominio personalizzato potrebbe risultare danneggiata al termine della migrazione a causa di un bug noto. Il ambiente del servizio app dovrebbe comunque funzionare come previsto. Lo stato danneggiato dovrebbe risolversi entro 6-8 ore. Se la configurazione è danneggiata dopo 8 ore o se il suffisso di dominio personalizzato non funziona, contattare il supporto tecnico.
10. Ottenere gli indirizzi IP in ingresso per la nuova ambiente del servizio app v3 e aggiornare le risorse dipendenti
In questa fase del processo di migrazione sono disponibili due ambiente del servizio app. Le app sono in esecuzione in entrambi gli ambienti. È necessario aggiornare le risorse dipendenti per usare il nuovo indirizzo IP in ingresso per il nuovo ambiente del servizio app v3. Per le ambiente del servizio app interne con connessione al servizio di bilanciamento del carico interno, è necessario aggiornare le zone DNS private in modo che puntino al nuovo indirizzo IP in ingresso.
È possibile ottenere il nuovo indirizzo IP in ingresso per il nuovo ambiente del servizio app v3 eseguendo il comando seguente che corrisponde al tipo di servizio di bilanciamento del carico ambiente del servizio app. È responsabilità dell'utente eseguire eventuali aggiornamenti necessari.
Per i ambiente del servizio app il bilanciamento del carico interno, ottenere l'indirizzo IP in ingresso privato eseguendo il comando seguente:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
Per le ambiente del servizio app ELB, ottenere l'indirizzo IP in ingresso pubblico eseguendo il comando seguente:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11. Reindirizzare il traffico dei clienti, convalidare il ambiente del servizio app v3 e completare la migrazione
Questo passaggio è l'opportunità di testare e convalidare il nuovo ambiente del servizio app v3. Per impostazione predefinita, il traffico viene inviato al front-end ambiente del servizio app v2. Se si usa un servizio di bilanciamento del carico interno ambiente del servizio app v3, è possibile testare il front-end ambiente del servizio app v3 aggiornando la zona DNS privata con il nuovo indirizzo IP in ingresso. Se si usa un ambiente del servizio app ELB v3, il processo per il test dipende dalla configurazione di rete specifica. Un metodo semplice per testare gli ambienti ELB consiste nell'aggiornare il file host per usare il nuovo indirizzo IP in ingresso ambiente del servizio app v3. Se sono stati assegnati domini personalizzati alle singole app, in alternativa è possibile aggiornare il DNS in modo che punti al nuovo INDIRIZZO IP in ingresso. Il test di questa modifica consente di convalidare completamente il ambiente del servizio app v3 prima di avviare il passaggio finale della migrazione in cui viene eliminato il ambiente del servizio app precedente. Se è possibile accedere alle app senza problemi, significa che si è pronti per completare la migrazione.
Dopo aver verificato che le app funzionino come previsto, è possibile reindirizzare il traffico dei clienti al nuovo ambiente del servizio app v3 eseguendo il comando seguente. Questo comando elimina anche l'ambiente precedente. Per completare questo passaggio sono disponibili 14 giorni. Se questo passaggio non viene completato in 14 giorni, la migrazione viene ripristinata automaticamente a un ambiente del servizio app v2. Se sono necessari più di 14 giorni per completare questo passaggio, contattare il supporto tecnico.
Se si verificano problemi o si decide a questo punto che non si vuole più procedere con la migrazione, contattare il supporto tecnico per ripristinare la migrazione. Non eseguire il comando di modifica DNS se è necessario ripristinare la migrazione. Per altre informazioni, vedere Ripristinare la migrazione.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Eseguire il comando seguente per controllare lo stato di questo passaggio:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Durante questo passaggio viene visualizzato lo stato .CompletingMigration Quando si ottiene uno stato di MigrationCompleted, il passaggio di reindirizzamento del traffico viene eseguito e la migrazione è stata completata.