Condividi tramite

Rilocare l'app per le funzioni in un'altra area di Azure

  • Articolo

Questo articolo descrive come spostare un'app per le funzioni ospitata in Funzioni 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à.

Le risorse di Azure che ospitano l'app per le funzioni sono specifiche dell'area e non possono essere spostate in altre aree. È invece necessario creare una copia delle risorse dell'app per le funzioni esistenti nell'area di destinazione, quindi ridistribuire il codice delle funzioni nella nuova app.

È possibile spostare queste stesse risorse in un altro gruppo di risorse o in un'altra sottoscrizione, purché rimangano nella stessa area. Per altre informazioni, vedere Spostare le risorse del servizio app in un gruppo di risorse o una sottoscrizione nuovi.

Prerequisiti

  • Assicurarsi che l'area di destinazione supporti Funzioni di Azure e qualsiasi servizio correlato, le cui risorse si desidera spostare.
  • Assicurarsi di disporre dei privilegi per creare le risorse necessarie nella nuova area.

Preparazione

Identificare tutte le risorse dell'app per le funzioni usate nell'area di origine, che potenzialmente includono:

Quando ci si prepara a spostare l'app in una nuova area, alcune parti dell'architettura richiedono pianificazione e considerazioni speciali.

Nome dell'app per le funzioni

I nomi delle app per le funzioni devono essere univoci a livello globale in tutte le app di Azure. Ciò significa che la nuova app per le funzioni non può avere lo stesso nome e URL di quello originale. Questo vale anche quando si usa un DNS personalizzato, perché il <APP_NAME>.azurewebsites.net sottostante deve essere comunque univoco. Potrebbe essere necessario aggiornare tutti i client che si connettono agli endpoint HTTP nell'app per le funzioni. Questi client devono usare il nuovo URL durante l'esecuzione di richieste.

Codice sorgente

Idealmente, è possibile mantenere il codice sorgente in un repository di codice di qualche tipo o in un repository di contenitori se in esecuzione in un contenitore Linux. Se si usa la distribuzione continua, pianificare il passaggio del repository o della connessione di distribuzione del contenitore sul nuovo indirizzo dell'app per le funzioni. Se, per qualche motivo, il codice sorgente non è più disponibile, è possibile scaricare il pacchetto attualmente in esecuzione dall'app per le funzioni originale. È consigliabile archiviare i file di origine in un repository di codice e usare la distribuzione continua per gli aggiornamenti.

Account di archiviazione predefinito

L'host Funzioni richiede un account di archiviazione di Azure. Per altre informazioni, vedere Requisiti dell'account di archiviazione. Per ottenere prestazioni ottimali, l'app per le funzioni deve usare un account di archiviazione nella stessa area. Quando si crea una nuova app con un nuovo account di archiviazione nella nuova area, l'app ottiene un nuovo set di chiavi di accesso alle funzioni e lo stato di tutti i trigger (ad esempio i trigger timer) viene reimpostato.

Archiviazione locale persistente

Le esecuzioni delle funzioni devono essere senza stato. Non è tuttavia possibile scrivere dati nel file system locale. È possibile archiviare i dati generati e usati dall'applicazione nell'unità virtuale %HOME%\site, ma questi dati non devono essere correlati allo stato. Se lo scenario richiede di mantenere lo stato tra le esecuzioni delle funzioni, prendere in considerazione l'uso di Durable Functions.

Se l'applicazione conserva i dati nel percorso di archiviazione condiviso dell'app, assicurarsi di pianificare la modalità di gestione dello stato durante lo spostamento di una risorsa. Tenere presente che per le app del piano Dedicato (servizio app) la condivisione fa parte del sito. Per i piani a consumo e Premium, la condivisione è, per impostazione predefinita, una condivisione file di Azure nell'account di archiviazione predefinito. Le app in esecuzione su Linux potrebbero usare una condivisione montata in modo esplicito per l'archiviazione persistente.

Servizi connessi

Le funzioni possono connettersi a Servizi di Azure e ad altre risorse tramite un SDK del servizio o trigger e associazioni. Qualsiasi servizio connesso potrebbe risentire del fatto che l'app viene trasferita in una nuova area. Se si riscontrano problemi di latenza o velocità effettiva, prendere in considerazione anche lo spostamento di qualsiasi servizio connesso nella nuova area. Per informazioni su come spostare tali risorse tra aree, vedere la documentazione per i rispettivi servizi. Quando si sposta un'app con servizi connessi, è consigliabile valutare una strategia di ripristino di emergenza tra aree e continuità aziendale durante lo spostamento.

Le modifiche ai servizi connessi potrebbero richiedere l'aggiornamento dei valori archiviati nelle impostazioni dell'applicazione, che vengono usati per connettersi a tali servizi.

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.

Domini personalizzati

Se l'app per le funzioni usa un dominio personalizzato, associarlo preventivamente all'app di destinazione. Verificare e abilitare il dominio nell'app di destinazione. Dopo lo spostamento, è necessario rieseguire il mapping del nome di dominio.

Reti virtuali

Funzioni di Azure consente di integrare le app con le risorse di rete virtuale e persino di eseguirle in una rete virtuale. Per altre informazioni, vedere Opzioni di rete di Funzioni di Azure. Quando si passa a una nuova area, prima di distribuire l'app è necessario spostare o ricreare tutte le risorse di rete virtuale e subnet necessarie. Ciò include lo spostamento o la ricreazione di endpoint privati ed endpoint di servizio.

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.

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:

Tipo di certificato Exportable Commenti
Servizio app gestito No Ricreare questi certificati nella nuova area.
Azure Key Vault gestito Sì Questi certificati possono essere esportati da Key Vault e quindi importati in Key Vault nella nuova area.
Chiave privata (autogestito) Sì I certificati acquisiti all'esterno di Azure possono essere esportati dal servizio app e quindi importati nella nuova app o in Key Vault nella nuova area.
Chiave pubblica No L'app potrebbe avere certificati solo con una chiave pubblica e nessun segreto, che vengono usati per accedere ad altri endpoint protetti. Ottenere i file di certificato chiave pubblica necessari e importarli nell'app nella nuova area.

Chiavi di accesso

Funzioni usa le chiavi di accesso per rendere più difficile l'accesso agli endpoint HTTP nell'app per le funzioni. Queste chiavi vengono mantenute crittografate nell'account di archiviazione predefinito. Quando si crea una nuova app nella nuova area, viene creato un nuovo set di chiavi. È necessario aggiornare tutti i client esistenti che usano le chiavi di accesso per usare le nuove chiavi nella nuova area. Anche se è consigliabile usare le nuove chiavi, è possibile ricreare le chiavi precedenti nella nuova app. Per altre informazioni, vedere Usare le chiavi di accesso in Funzioni di Azure.

Tempo di inattività

Se è richiesto un tempo di inattività minimo, prendere in considerazione l'esecuzione dell'app per le funzioni in entrambe le aree come consigliato per implementare un'architettura di ripristino di emergenza. L'architettura specifica implementata dipende dai tipi di trigger dell'app per le funzioni. Per altre informazioni, vedere Affidabilità in Funzioni di Azure.

Funzioni durevoli

L'estensione Durable Functions consente di definire le orchestrazioni, in cui lo stato viene mantenuto nelle esecuzioni delle funzioni usando entità con stato. Idealmente, è consigliabile consentire il completamento delle orchestrazioni in esecuzione prima di eseguire la migrazione dell'app Durable Functions, soprattutto quando si prevede di passare a un nuovo account di archiviazione nella nuova area. Quando si esegue la migrazione delle app Durable Functions, è consigliabile usare una di queste strategie di ripristino di emergenza e distribuzione geografica.

Rilocare

La ricreazione dell'app per le funzioni in una nuova area richiede innanzitutto di ricreare l'infrastruttura di Azure di un piano di servizio app, l'istanza dell'app per le funzioni e le risorse correlate, ad esempio reti virtuali, identità e slot. È inoltre necessario riconnettersi o, nella nuova area, ricreare le risorse di Azure richieste dall'app. Queste risorse possono includere l'account di archiviazione di Azure predefinito e l'istanza di Application Insights.

È quindi possibile creare un pacchetto e ridistribuire il codice sorgente o il contenitore effettivo dell'applicazione nell'app per le funzioni in esecuzione nella nuova area.

Ricreare l'infrastruttura di Azure

Esistono diversi modi per creare un'app per le funzioni e le risorse correlate in Azure nell'area di destinazione:

  • Modelli di distribuzione: se l'app per le funzioni è stata distribuita in origine usando file IaC (Infrastructure-as-Code) come Bicep, modelli di ARM o Terraform, è possibile aggiornare le distribuzioni precedenti per definire come destinazione la nuova area e usarle per ricreare le risorse nella nuova area. Se questi file di distribuzione non sono più disponibili, è sempre possibile scaricare dal portale di Azure un modello di Resource Manager per il gruppo di risorse esistente.
  • Script dell'interfaccia della riga di comando di Azure/PowerShell: se l'app per le funzioni è stata distribuita in origine usando l'interfaccia della riga di comando di Azure o gli script di Azure PowerShell, è possibile aggiornare questi script in modo che vengano destinati alla nuova area ed eseguirli di nuovo. Se questi script non sono più disponibili, è sempre possibile scaricare dal portale di Azure un modello di Resource Manager per il gruppo di risorse esistente.
  • Portale di Azure: se è stata creata l'app per le funzioni nel portale in origine o non ci si sente a proprio agio nell'uso di script o file IaC, è sufficiente ricreare tutti gli elementi nel portale. Assicurarsi di usare lo stesso piano di hosting, il runtime del linguaggio e la versione del linguaggio dell'app originale.

Esaminare le risorse configurate

Esaminare e configurare le risorse identificate nel passaggio di preparazione precedente nell'area di destinazione, se non sono state configurate durante la distribuzione. Se si usa la distribuzione continua con l'autenticazione dell'identità gestita, assicurarsi che le identità e i mapping dei ruoli necessari esistano nella nuova app per le funzioni.

Ridistribuire il codice sorgente

Ora che è disponibile l'infrastruttura, è possibile creare nuovamente il pacchetto e ridistribuire il codice sorgente nell'app per le funzioni. Questo è un buon momento per spostare il codice sorgente o l'immagine del contenitore in un repository e abilitare la distribuzione continua da tale repository.

È inoltre possibile usare qualsiasi altro metodo di pubblicazione supportato da Funzioni. La maggior parte della pubblicazione basata su strumenti richiede l'abilitazione dell'autenticazione di base nell'endpoint scm, che non è consigliata per le app di produzione.

Considerazioni sulla rilocazione

Eseguire la pulizia

Al termine dello spostamento, eliminare l'app per le funzioni e il piano di hosting dall'area di origine. Nei piani Premium o Dedicato è previsto un costo per le app per le funzioni, anche quando l'app stessa non è in esecuzione. Se sono stati ricreati altri servizi nella nuova area, è consigliabile eliminare anche i servizi meno recenti dopo aver verificato che non sono più necessari.

Esaminare il Centro architetture di Azure per ottenere esempi di app per le funzioni in esecuzione in più aree come parte di architetture di soluzioni più avanzate e con ridondanza geografica.