Rilocare App Web statiche di Azure in un'altra area

Questo articolo illustra come rilocare le risorse di App Web statiche di Azure in un'altra area di Azure.

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à.

Prerequisiti

Esaminare i prerequisiti seguenti prima di prepararsi per la rilocazione.

• Convalidare che App Web statiche di Azure sia disponibile nell'area di destinazione.

• Assicurarsi di disporre dell'autorizzazione per creare risorse di App Web statiche nell'area di destinazione.

• Scoprire se sono state applicate restrizioni di Criteri di Azure a livello di area all’organizzazione.

• Se si usa il supporto dell’API integrato fornito da Funzioni di Azure:

  • Determinare la disponibilità di Funzioni di Azure nell'area di destinazione.
  • Determinare se vengono usate Chiavi API della funzione. Ad esempio, si usa Key Vault o le si distribuisce come parte dei file di configurazione dell'applicazione?
  • Determinare il modello di distribuzione per il supporto api nell'area di destinazione: Bring Your own functions (Bring Your own functions). Informazioni sulle differenze tra i due modelli.

• Assicurarsi che il Piano di hosting Standard venga usato per ospitare l'App Web statica. Per altre informazioni sui piani di hosting, vedere Piani di hosting di App Web statiche di Azure.

• Determinare il tempo di inattività consentito per la rilocazione.

• A seconda della distribuzione di App Web statiche di Azure, potrebbe essere necessario distribuire e configurare le risorse dipendenti seguenti nell'area di destinazione prima della rilocazione:

  • Funzioni di Azure.
  • Rete virtuale di Azure
  • Frontdoor di Azure
  • Gruppo di sicurezza di rete
  • Servizio collegamento privato di Azure
  • Azure Key Vault
  • Account di archiviazione di Azure
  • Gateway applicazione di Azure

Tempo di inattività

La rilocazione di un sito Web statico di Azure comporta tempi di inattività per l'applicazione. Il tempo di inattività dipende dal tipo di modello a disponibilità elevata implementato per il sito Web statico di Azure. I modelli generali sono i seguenti:

• Cold standby: i dati del carico di lavoro vengono sottoposti regolarmente a backup in base ai requisiti. In caso di emergenza, il carico di lavoro viene ridistribuito in una nuova area di Azure e i dati vengono ripristinati.
• Warm standby: il carico di lavoro viene distribuito nell'area di continuità aziendale e ripristino di emergenza (BCDR) e i dati vengono replicati in modo asincrono o sincrono. In caso di emergenza, la distribuzione nell'area di ripristino di emergenza viene scalata verticalmente e orizzontalmente.
• Multi-area: il carico di lavoro viene distribuito in entrambe le aree e i dati vengono replicati in modo sincrono. Entrambe le aree dispongono di una copia scrivibile dei dati. L'implementazione può essere attiva/passiva o attiva/attiva.

Preparazione

Distribuzioni con endpoint privati

Se le App Web statiche vengono distribuite con endpoint privati, assicurarsi di:

• Aggiornare il nome host per l'endpoint di connessione.
• Aggiornare il nome host nella zona privata DNS o nel server DNS personalizzato (applicabile solo al collegamento privato).

Per altre informazioni, vedere Configurare un endpoint privato in App Web statiche di Azure.

Tutte le altre distribuzioni

Per tutti gli altri tipi di distribuzione, assicurarsi di:

• Se applicabile, recuperare le nuove chiavi API della funzione da Funzioni di Azure nella nuova area.

• Se la funzione di Azure dispone di una dipendenza in un database, assicurarsi che il DATABASE_CONNECTION_STRING sia aggiornato. Questo database potrebbe non rientrare nell'ambito della migrazione a livello di area.

• Aggiornare il dominio personalizzato in modo che punti al nuovo nome host dell'app Web statica.

• Se si usa Key Vault, effettuare il provisioning di un nuovo insieme di credenziali delle chiavi nell'area di destinazione. Aggiornare le chiavi API della funzione in Key Vault, se applicabile. Tutti gli altri dati sensibili che non devono essere archiviati in file di codice o di configurazione devono essere archiviati in Key Vault

Esportare il modello

Per esportare il modello di Resource Manager che contiene le impostazioni che descrivono l'app Web statica:

1. Accedere al portale di Azure.

2. Passare all'app Web statica.

3. Nel menu a sinistra, in Automazione, selezionare Esporta modello.

   La generazione del modello può richiedere qualche minuto.

4. Selezionare Download.

5. Individuare il file .zip scaricato e aprirlo in una cartella di propria scelta.

   Questo file contiene i file .json che includono il modello e gli script per distribuirlo.

6. Apportare le modifiche necessarie al modello, ad esempio aggiornare la posizione con l'area di destinazione.

Rilocare

Usare la procedura seguente per rilocare l'app Web statica in un'altra area.

1. Se si esegue la rilocazione con endpoint privato, seguire le linee guida riportate in Rilocare il servizio collegamento privato di Azure in un'altra area.

2. Se è stata fornita un'istanza di Funzioni di Azure esistente all'app Web statica, seguire la procedura di rilocazione prevista per Funzioni di Azure.

3. Ridistribuire l'app Web statica usando il modello esportato e configurato nella sezione precedente.

   Importante

   Se non si usa un dominio personalizzato, l'URL dell'applicazione si modifica nell'area di destinazione. In questo scenario, è necessario assicurarsi che gli utenti siano a conoscenza della modifica dell'URL.

4. Se si usa un'API integrata, creare una nuova API integrata supportata da Funzioni di Azure.

5. Riconfigurare il repository (GitHub o Azure DevOps) per eseguire la distribuzione nella nuova app Web statica dell'area di destinazione. Avviare la distribuzione dell'applicazione usando GitHub Actions o Azure Pipelines.

6. Nel caso di una distribuzione in cold standby, assicurarsi di informare i clienti del nuovo URL. Se si usa un dominio DNS personalizzato, è sufficiente modificare la voce DNS in modo che punti all'area di destinazione. Nel caso di una distribuzione warm standby, un servizio di bilanciamento del carico, ad esempio Frontdoor o Gestione traffico, gestisce la migrazione dell'app Web statica dall'area di origine all'area di destinazione.