Rilocare Servizi app di Azure in un'altra area

Questo articolo descrive come spostare le risorse del servizio app in un'area di Azure diversa.

Esistono diversi motivi per cui è possibile spostare le risorse di Azure esistenti da un'area a un'altra. È possibile:

• Sfruttare i vantaggi di una nuova area di Azure.
• Distribuire funzionalità o servizi disponibili solo in aree specifiche.
• Soddisfare i requisiti di governance e criteri interni.
• Allinearsi alle fusioni e alle acquisizioni aziendali
• Soddisfare i requisiti di pianificazione della capacità.

Le risorse del servizio app sono specifiche dell'area e non possono essere spostate tra aree. È necessario creare una copia delle risorse esistenti del servizio app nell'area di destinazione, quindi rilocare il contenuto nella nuova app. Se l'app di origine usa un dominio personalizzato, è possibile eseguirne la migrazione alla nuova app nell'area di destinazione dopo il completamento della rilocazione.

Per semplificare la copia dell'app, è possibile eseguire il backup e ripristino di singole app del servizio app in un piano di servizio app in un'altra area.

Prerequisiti

• Assicurarsi che l'applicazione di Servizio app si trovi nell'area di Azure da cui si vuole eseguire lo spostamento.
• Assicurarsi che l'area di destinazione supporti il servizio app e qualsiasi servizio correlato, le cui risorse si desidera spostare.
• Verificare che esista un'autorizzazione sufficiente per distribuire le risorse del servizio app nella sottoscrizione e nell'area di destinazione.
• Verificare se vengono assegnati criteri di Azure con una restrizione dell'area.
• Prendere in considerazione eventuali costi operativi, poiché i prezzi delle risorse di calcolo possono variare da un'area all'altra. Per stimare i costi possibili, vedere Calcolatore prezzi.

Preparazione

Identificare tutte le risorse del servizio app attualmente in uso. Ad esempio:

• App del servizio app
• Piani del servizio app
• Slot di distribuzione
• Domini personalizzati acquistati in Azure
• Certificati TLS/SSL
• Integrazione di Rete virtuale di Azure
• Connessioni ibride.
• Identità gestite
• Impostazioni backup

Alcune risorse, ad esempio certificati importati o connessioni ibride, contengono l'integrazione con altri servizi di Azure. Per informazioni su come spostare tali risorse tra aree, vedere la documentazione per i rispettivi servizi.

Piano

Questa sezione è un elenco di controllo per la pianificazione nelle aree seguenti:

• Stato, Archiviazione e dipendenze downstream
• Certificati
• Impostazione
• Connettività di rete virtuale/nomi personalizzati/DNS
• Identità
• Endpoint di servizio

Dipendenze di stato, archiviazione e downstream

• Determinare se l'app del servizio app è con stato o senza stato. Anche se è consigliabile che le app del servizio app siano senza stato e che i file nell'unità %HOME%\site siano solo quelli necessari per eseguire l'applicazione distribuita con qualsiasi file temporaneo, è comunque possibile archiviare lo stato dell'applicazione di runtime nell'unità virtuale %HOME%\site. Se l'applicazione scrive lo stato nel percorso di archiviazione condiviso dell'app, assicurarsi di pianificare la modalità di gestione dello stato durante lo spostamento di una risorsa.

  Suggerimento

  È possibile usare Kudu, oltre che per l'accesso al portale, per fornire un'API di accesso ai file (VFS) che può leggere/scrivere file nella directory %HOME%\site. Per altre informazioni, vedere Wiki di Kudu.

• Verificare la memorizzazione nella cache interna e lo stato nel codice dell'applicazione.

• Disabilitare l'impostazione di affinità di sessione. Se possibile, è consigliabile disabilitare l'impostazione di affinità di sessione. La disabilitazione dell'affinità di sessione migliora il bilanciamento del carico per uno scale-out orizzontale. Qualsiasi stato interno può influire sulla pianificazione per il taglio di un carico di lavoro, in particolare se il tempo di inattività è un requisito. Laddove possibile, può essere utile effettuare il refactoring di qualsiasi stato dell'applicazione per rendere l'applicazione senza stato in preparazione allo spostamento.

• Analizzare stringhe di connessione del database. Le stringhe di connessione del database sono disponibili in Impostazioni app. Tuttavia, possono anche essere hardcoded o gestiti nei file di configurazione forniti con l'applicazione. Analizzare e pianificare la migrazione o la replica dei dati come parte della pianificazione di livello superiore per spostare il carico di lavoro. Per le applicazioni critiche frammentate o latenza, l'applicazione nell'area di destinazione non offre prestazioni elevate per tornare alle origini dati nell'area di origine.

• Analizzare la memorizzazione nella cache esterna , ad esempio Redis. Le cache delle applicazioni devono essere distribuite il più vicino possibile all'applicazione. Analizzare il modo in cui vengono popolate le cache, i criteri di scadenza/rimozione e qualsiasi impatto su una cache a freddo può avere sui primi utenti ad accedere al carico di lavoro dopo il cutover.

• Analizzare e pianificare le dipendenze dell'API (o dell'applicazione) la comunicazione tra aree è significativamente meno efficiente se l'app nell'area di destinazione torna alle dipendenze che sono ancora presenti nell'area di origine. È consigliabile spostare tutte le dipendenze downstream come parte della rilocazione del carico di lavoro. Tuttavia, le risorse *locali* sono l'eccezione, in particolare quelle che sono geograficamente più vicine all'area di destinazione (come può essere il caso per gli scenari di ricollocamento).

  Registro Azure Container può essere una dipendenza downstream (runtime) per il servizio app configurato per l'esecuzione su immagini contenitore personalizzate. È più opportuno che Registro Container si trova nella stessa area dell'app stessa. Valutare la possibilità di caricare le immagini necessarie in un nuovo Registro Azure Container nell'area di recupero di destinazione. In caso contrario, è consigliabile usare la funzionalità di replica geografica se si prevede di mantenere le immagini nell'area di origine.

• Analizzare e pianificare i servizi regionali. I dati di Application Insights e Log Analytics sono servizi a livello di area. Prendere in considerazione la creazione di una nuova risorsa di archiviazione di Application Insights e Log Analytics nell'area di destinazione. Per App Insights, una nuova risorsa influisce anche sulla stringa di connessione che deve essere aggiornata come parte della modifica in Configurazione app.

Certificati

Le risorse del certificato del servizio app possono essere spostate in un nuovo gruppo di risorse o in una nuova sottoscrizione, ma non tra aree. I certificati che possono essere esportati possono anche essere importati nell'app o in Key Vault nella nuova area. Questo processo di esportazione e importazione equivale a uno spostamento tra aree.

Esistono diversi tipi di certificati che devono essere presi in considerazione durante la pianificazione della rilocazione del servizio:

Alcuni altri punti da considerare:

• Gli indirizzi assegnati dall'app, in cui la connessione SSL di un'app del servizio app è associata a un indirizzo IP designato per un'app specifica, può essere usata per le chiamate di elenco consentite da reti di terze parti nel servizio app. Ad esempio, un amministratore IT o di rete potrebbe voler bloccare le chiamate in uscita da una rete locale o da una rete virtuale per usare un indirizzo statico noto. Di conseguenza, se la funzionalità Indirizzo assegnato dall'app è in uso, le regole del firewall upstream, ad esempio interne, esterne o terze parti, per i chiamanti nell'app devono essere controllate e informate del nuovo indirizzo. Le regole del firewall possono essere interne, esterne o di terze parti, ad esempio partner o clienti noti.

• Prendere in considerazione qualsiasi appliance virtuale di rete upstream o proxy inverso. La configurazione dell'appliance virtuale di rete potrebbe dover cambiare se si sta riscrivendo l'intestazione host o e/o la terminazione SSL.

Impostazione

• È possibile acquisire uno snapshot delle impostazioni dell'app e delle stringhe di connessione esistenti dal portale di Azure. Espandere Impostazioni>Variabili di ambiente, selezionare Modifica avanzate in Impostazioni app o Stringhe di connessione e salvare l'output JSON che contiene le impostazioni o le connessioni esistenti. È necessario ricreare queste impostazioni nella nuova area, ma è probabile che i valori stessi vengano modificati in seguito alle successive modifiche dei servizi connessi in tale area.

• I riferimenti esistenti a Key Vault non possono essere esportati oltre un limite geografico di Azure. È necessario ricreare tutti i riferimenti necessari nella nuova area.

• La configurazione dell'app potrebbe essere gestita da Configurazione app di Azure o da altre dipendenze database centrali (downstream). Esaminare qualsiasi archivio di Configurazione app o archivi simili per verificare le impostazioni specifiche dell'ambiente e dell'area che potrebbero richiedere modifiche.

• Assicurarsi di controllare qualsiasi configurazione del file del disco, che potrebbe essere sottoposta o meno a override dalle impostazioni dell'applicazione.

Connettività di rete virtuale/nomi personalizzati/DNS

• L'ambiente del servizio app è un servizio tenant singolo inserito nella rete virtuale. La rete dell'ambiente del servizio app è diversa dal servizio app multi-tenant, che richiede uno o entrambi gli "endpoint privati" o "Integrazione rete virtuale a livello di area". Altre opzioni che possono essere in gioco includono l'integrazione della rete virtuale basata su VPN da punto a sito legacy e le connessioni ibride (un servizio di Inoltro di Azure).

  Nota

  La rete ASEv3 è semplificata: il traffico di gestione di Azure e gli ambienti del servizio app di proprietà delle dipendenze downstream non sono visibili alla rete virtuale del cliente, semplificando notevolmente la configurazione necessaria quando il cliente usa un tunnel forzato per tutto il traffico o inviando un subset di traffico in uscita, attraverso un'appliance virtuale di rete/firewall.

  Le connessioni ibride (Inoltro di Azure) sono a livello di area. Se vengono usate connessioni ibride e anche se uno spazio dei nomi di Inoltro di Azure può essere spostato in un'altra area, sarebbe più semplice ridistribuire la connessione ibrida (assicurarsi che la connessione ibrida sia configurata nella nuova area in fase di distribuzione delle risorse di destinazione) e ricollegarla alla gestione connessione ibrida. La posizione di Gestione connessione ibrida deve essere considerata attentamente.

• Seguire la strategia per un'area warm standby. Assicurarsi che le funzionalità di rete e connettività di base, rete hub, controller di dominio, DNS, VPN o Express Route e così via, siano presenti e testate prima della rilocazione delle risorse.

• Convalidare gli ACL e la configurazione di rete upstream o downstream. Si consideri, ad esempio, un servizio downstream esterno che consenta solo il traffico dell'app. Una rilocazione in un nuovo piano di applicazione per un servizio app multi-tenant sarebbe quindi anche una modifica negli indirizzi IP in uscita.

• Nella maggior parte dei casi, è consigliabile assicurarsi che le reti virtuali dell'area di destinazione abbiano uno spazio indirizzi univoco. Uno spazio indirizzi univoco facilita la connettività della rete virtuale, se necessario, ad esempio, per replicare i dati. Pertanto, in questi scenari è necessario modificare in modo implicito:

  • DNS privato
  • Qualsiasi configurazione hardcoded o esterna che fa riferimento alle risorse in base all'indirizzo IP (senza un nome host)
  • ACL di rete, inclusi i gruppi di sicurezza di rete e la configurazione del firewall (considerare l'impatto anche sulle appliance virtuali di rete locali)
  • Qualsiasi regola di gestione, tabelle di route definite dall'utente

  Assicurarsi inoltre di controllare la configurazione, inclusi intervalli IP/tag di servizio specifici dell'area, se si inoltrano le risorse di distribuzione DevOps esistenti.

• Sono necessarie meno modifiche per il DNS privato distribuito dal cliente configurato per l'inoltro ad Azure per i domini di Azure e le Zone private di DNS di Azure. Tuttavia, poiché gli endpoint privati sono basati su un nome di dominio completo della risorsa e questo è spesso anche il nome della risorsa (che può essere diverso nell'area di destinazione), ricordarsi di controllare la configurazione incrociata per assicurarsi che i nomi FQDN a cui si fa riferimento nella configurazione vengano aggiornati di conseguenza.

• Ricreare gli endpoint privati, se usati, nell'area di destinazione. Lo stesso vale per l'integrazione della rete virtuale a livello di area.

• DNS per l'ambiente del servizio app viene in genere gestito tramite la soluzione DNS personalizzata privata dei clienti (è disponibile un override manuale delle impostazioni in base a ogni app). L'ambiente del servizio app offre un servizio di bilanciamento del carico per l'ingresso/uscita, mentre il servizio app filtra le intestazioni host. Di conseguenza, più nomi personalizzati possono essere puntati allo stesso endpoint di ingresso dell'ambiente del servizio app. L'ambiente del servizio app non richiede la convalida del dominio.

  Nota

  L'endpoint Kudu per l'ambiente del servizio app v3 è disponibile solo in {resourcename}.scm.{asename}.appserviceenvironment.net. Per altre informazioni su DNS e rete dell'ambiente del servizio app v3, vedere Rete dell'ambiente del servizio app.

  Per l'ambiente del servizio app, il cliente possiede il routing e quindi le risorse usate per il cutover. Ovunque sia abilitato l'accesso all'ambiente del servizio app esternamente, in genere tramite un'appliance virtuale di rete di livello 7 o un proxy inverso, Gestione traffico o Frontdoor di Azure/Altro servizio di bilanciamento del carico globale L7 può essere usato.

• Per la versione multi-tenant pubblica del servizio, viene effettuato il provisioning di un nome predefinito {resourcename}.azurewebsites.net per gli endpoint del piano dati, insieme a un nome predefinito per l'endpoint Kudu (SCM). Poiché il servizio fornisce un endpoint pubblico per impostazione predefinita, l'associazione deve essere verificata per dimostrare la proprietà del dominio. Tuttavia, una volta che l'associazione è stata eseguita, la verifica di nuovo non è necessaria, né è necessario che i record DNS pubblici puntino all'endpoint del servizio app.

• Se si usa un dominio personalizzato, associarlo preventivamente all'app di destinazione. Verificare e abilitare il dominio nell'app di destinazione.

Identità

• È necessario ricreare tutte le identità gestite assegnate dal sistema insieme all'app nella nuova area di destinazione. In genere, per impostazione predefinita, un'app Microsoft Entra ID creata automaticamente e usata da EasyAuth è il nome della risorsa app.

• Nemmeno le identità gestite assegnate dall'utente possono essere spostate tra aree. Per mantenere le identità gestite assegnate dall'utente nello stesso gruppo di risorse con l'app, è necessario ricrearle nella nuova area. Per altre informazioni, vedere Rilocare le identità gestite per le risorse di Azure in un'altra area.

• Concedere alle identità gestite le stesse autorizzazioni nei servizi rilocati delle identità originali che stanno sostituendo, incluse le appartenenze ai gruppi.

• Pianificare la rilocazione del provider di identità (IDP) nell'area di destinazione. Anche se Microsoft Entra ID è un servizio globale, alcune soluzioni si basano su un IDP locale (o downstream).

• Aggiornare tutte le risorse al servizio app che possono basarsi sulle credenziali FTP Kudu.

Endpoint di servizio

Gli endpoint servizio di rete virtuale per Servizio app di Azure limitano l'accesso a una rete virtuale specifica. Gli endpoint possono inoltre limitare l'accesso a un elenco di intervalli di indirizzi IPv4 (protocollo IP versione 4). L'accesso viene negato a tutti gli utenti che si connettono a Hub eventi dall'esterno di tali origini. Se gli endpoint di servizio sono stati configurati nell'area di origine per la risorsa di Hub eventi, è necessario eseguire la stessa operazione nell'area di destinazione.

Per ricreare correttamente di Servizio app di Azure nell'area di destinazione, è necessario creare prima la rete virtuale e la subnet. Nel caso in cui lo spostamento di queste due risorse venga eseguito con lo strumento Spostamento risorse di Azure, gli endpoint di servizio non verranno configurati automaticamente. Di conseguenza, è necessario configurarli manualmente. L'operazione può essere eseguita tramite il portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell.

Rilocare

Per rilocare le risorse del servizio app, è possibile usare il portale di Azure o l'infrastruttura come codice (IaC).

Rilocare con il portale di Azure

Il maggior vantaggio dell'utilizzo del portale di Azure per rilocare consiste nella sua semplicità. L'app, il piano e il contenuto, nonché molte impostazioni vengono clonate nella nuova risorsa e piano del servizio app.

Tenere presente che per i livelli Ambiente del servizio app (isolato) è necessario ridistribuire prima l'intero ambiente del servizio app in un'altra area e quindi avviare la ridistribuzione dei singoli piani nel nuovo ambiente del servizio app nella nuova area.

Per spostare le risorse del servizio app in una nuova area usando il portale di Azure:

1. Creare un backup dell'app di origine.
2. Creare un'app in un nuovo piano di servizio app nell'area di destinazione.
3. Ripristinare il backup nell'app di destinazione
4. Se si usa un dominio personalizzato, associarlo preventivamente all'app di destinazione con asuid. e abilitare il dominio nell'app di destinazione.
5. Configurare tutto il resto dell'app di destinazione in modo che corrisponda all'app di origine e verificare la configurazione.
6. Quando si è pronti per il dominio personalizzato in modo che punti all'app di destinazione, modificare il mapping del nome di dominio personalizzato.

Rilocare con IaC

Usare IaC quando esiste una pipeline di integrazione continua e distribuzione continua/distribuzione continua (CI/CD) o può essere creata. Con una pipeline CI/CD sul posto, la risorsa del servizio app può essere creata nell'area di destinazione tramite un'azione di distribuzione o una distribuzione zip Kudu.

I requisiti del contratto di servizio devono determinare quanto impegno aggiuntivo è necessario. Ad esempio: si tratta di una ridistribuzione con tempi di inattività limitati o è un cutover quasi in tempo reale necessario senza tempi di inattività minimi?

L'inclusione di servizi perimetrali di routing del traffico esterni e globali, ad esempio Gestione traffico o Frontdoor di Azure, consente di semplificare il cut-over per utenti e applicazioni esterni.

Convalida

Al termine della rilocazione, testare e convalidare il servizio app di Azure con le linee guida consigliate:

• Una volta spostato il servizio app di Azure nell'area di destinazione, eseguire un test di integrazione e fumo. È possibile testare manualmente o eseguire un test tramite uno script. Assicurarsi di verificare che tutte le configurazioni e le risorse dipendenti siano collegate correttamente e che tutti i dati configurati siano accessibili.

• Convalidare tutti i componenti e l'integrazione del servizio app di Azure.

• Eseguire test di integrazione nella distribuzione dell'area di destinazione, inclusi tutti i test di regressione formali. I test di integrazione devono essere allineati ai normali processi di distribuzione e test del ritmo aziendale applicabili al carico di lavoro.

• In alcuni scenari, in particolare in cui la rilocazione include aggiornamenti, modifiche alle applicazioni o alle risorse di Azure o una modifica del profilo di utilizzo, usare i test di carico per verificare che il nuovo carico di lavoro sia adatto a scopo. Il test di carico è anche un'opportunità per convalidare le operazioni e il monitoraggio della copertura. Ad esempio, usare test di carico per verificare che l'infrastruttura necessaria e i log applicazioni vengano generati correttamente. I test di carico devono essere misurati in base alle baseline delle prestazioni del carico di lavoro stabilite.

Eseguire la pulizia

Eliminare l'app di origine e il piano di servizio app. Un piano di servizio app nel livello non gratuito comporta un addebito, anche se non è in esecuzione alcuna app.

Passaggi successivi

Clonazione di app del servizio app di Azure con PowerShell