Considerazioni sull'archiviazione per Funzioni di Azure

Funzioni di Azure richiede un account di Archiviazione di Azure quando si crea un'istanza dell'app per le funzioni. I servizi di archiviazione seguenti possono essere usati dall'app per le funzioni:

Servizio di archiviazione Utilizzo delle funzioni
Archivio BLOB di Azure Mantenere lo stato delle associazioni e i tastifunzione 1.
Usato per impostazione predefinita per gli hub attività in Durable Functions.
Può essere usato per archiviare il codice dell'app per le funzioni per la compilazione remota a consumo linux o come parte delle distribuzioni di URL del pacchetto esterno.
File di Azure 2 Condivisione file usata per archiviare ed eseguire il codice dell'app per le funzioni in un piano a consumo e in un piano Premium.
Archiviazione code di Azure Usato per impostazione predefinita per gli hub attività in Durable Functions. Usato per la gestione degli errori e dei nuovi tentativi in trigger di Funzioni di Azure specifici. Usato per il rilevamento degli oggetti dal trigger di archiviazione BLOB.
Archivio tabelle di Azure Usato per impostazione predefinita per gli hub attività in Durable Functions.

1 L'archivio BLOB è l'archivio predefinito per le chiavi di funzione, ma è possibile configurare un archivio alternativo.

2 File di Azure è configurato per impostazione predefinita, ma è possibile creare un'app senza File di Azure in determinate condizioni.

Considerazioni importanti

È necessario considerare fortemente i fatti seguenti relativi agli account di archiviazione usati dalle app per le funzioni:

  • Quando l'app per le funzioni è ospitata nel piano a consumo o nel piano Premium, il codice della funzione e i file di configurazione vengono archiviati in File di Azure nell'account di archiviazione collegato. Quando si elimina questo account di archiviazione, il contenuto viene eliminato e non può essere recuperato. Per altre informazioni, vedere Archiviazione account eliminato

  • I dati importanti, ad esempio il codice della funzione, le chiavi di accesso e altri dati importanti correlati al servizio, possono essere salvati in modo permanente nell'account di archiviazione. È necessario gestire attentamente l'accesso agli account di archiviazione usati dalle app per le funzioni nei modi seguenti:

    • Controllare e limitare l'accesso di app e utenti all'account di archiviazione in base a un modello con privilegi minimi. Le autorizzazioni per l'account di archiviazione possono provenire da azioni sui dati nel ruolo assegnato o tramite l'autorizzazione per eseguire l'operazione listKeys.

    • Monitorare sia l'attività del piano di controllo ,ad esempio il recupero delle chiavi, sia le operazioni del piano dati (ad esempio la scrittura in un BLOB) nell'account di archiviazione. Valutare la possibilità di mantenere i log di archiviazione in una posizione diversa da Archiviazione di Azure. Per altre informazioni, vedere Archiviazione log.

Requisiti dell'account di archiviazione

Archiviazione gli account creati come parte del flusso di creazione dell'app per le funzioni nel portale di Azure sono garantiti per funzionare con la nuova app per le funzioni. Quando si sceglie di usare un account di archiviazione esistente, l'elenco fornito non include alcuni account di archiviazione non supportati. Le restrizioni seguenti si applicano agli account di archiviazione usati dall'app per le funzioni, pertanto è necessario assicurarsi che un account di archiviazione esistente soddisfi questi requisiti:

  • Il tipo di account deve supportare l'archiviazione BLOB, coda e tabelle. Alcuni account di archiviazione non supportano code e tabelle. Questi account includono account di archiviazione solo BLOB e Archiviazione Premium di Azure. Per altre informazioni sui tipi di account di archiviazione, vedere Archiviazione panoramica dell'account.

  • Non è possibile usare un account di archiviazione già protetto usando un firewall o una rete privata virtuale quando si crea l'app per le funzioni nel portale di Azure. Tuttavia, il portale non filtra attualmente questi account di archiviazione protetti. Per informazioni su come usare un account di archiviazione protetto con l'app per le funzioni, vedere Come usare un account di archiviazione protetto con Funzioni di Azure.

  • Non è possibile usare account di archiviazione protetti con le app per le funzioni ospitate nel piano a consumo.

  • Quando si crea l'app per le funzioni nel portale, è consentito scegliere solo un account di archiviazione esistente nella stessa area dell'app per le funzioni che si sta creando. Si tratta di un'ottimizzazione delle prestazioni e non di una limitazione rigorosa. Per altre informazioni, vedere Archiviazione percorso dell'account.

  • Quando si crea l'app per le funzioni in un piano con supporto per la zona di disponibilità abilitata, sono supportati solo gli account di archiviazione con ridondanza della zona.

È possibile creare app per le funzioni in un piano Elastic Premium o Dedicato (servizio app) usando l'automazione della distribuzione. Tuttavia, è necessario includere configurazioni di rete specifiche nel modello arm o nel file Bicep. Quando non si includono queste impostazioni e risorse, la distribuzione automatizzata potrebbe non riuscire nella convalida. Per altre informazioni, vedere Distribuzioni protette.

Linee guida sugli account di archiviazione

Ogni app per le funzioni richiede un account di archiviazione per funzionare. Quando l'account viene eliminato, l'app per le funzioni non verrà eseguita. Per risolvere i problemi correlati all'archiviazione, vedere Come risolvere i problemi relativi all'archiviazione. Le altre considerazioni seguenti si applicano all'account Archiviazione usato dalle app per le funzioni.

Posizione dell'account di archiviazione

Per ottenere prestazioni ottimali, l'app per le funzioni deve usare un account di archiviazione nella stessa area, riducendo la latenza. Il portale di Azure applica questa procedura consigliata. Se per qualche motivo è necessario usare un account di archiviazione in un'area diversa dall'app per le funzioni, è necessario creare l'app per le funzioni all'esterno del portale.

L'account di archiviazione deve essere accessibile all'app per le funzioni. Se è necessario usare un account di archiviazione protetto, è consigliabile limitare l'account di archiviazione a una rete virtuale.

Impostazione di connessione dell'account di archiviazione

Per impostazione predefinita, le app per le funzioni configurano la AzureWebJobsStorage connessione come stringa di connessione archiviata nell'impostazione dell'applicazione AzureWebJobs Archiviazione ma è anche possibile configurare AzureWebJobs Archiviazione per usare una connessione basata su identità senza un segreto.

Le app per le funzioni in esecuzione in un piano a consumo (solo Windows) o in un piano Elastic Premium (Windows o Linux) possono usare File di Azure per archiviare le immagini necessarie per abilitare il ridimensionamento dinamico. Per questi piani, impostare il stringa di connessione per l'account di archiviazione nell'impostazione WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e il nome della condivisione file nell'impostazione WEBSITE_CONTENTSHARE. Si tratta in genere dello stesso account usato per AzureWebJobsStorage. È anche possibile creare un'app per le funzioni che non usa File di Azure, ma il ridimensionamento potrebbe essere limitato.

Nota

Un account di archiviazione stringa di connessione deve essere aggiornato quando si rigenerano le chiavi di archiviazione. Altre informazioni sulla gestione delle chiavi archiviazione qui.

Account di archiviazione condivisi

È possibile che più app per le funzioni condividano lo stesso account di archiviazione senza problemi. Ad esempio, in Visual Studio è possibile sviluppare più app usando l'emulatore di archiviazione Azurite. In questo caso, l'emulatore funge da singolo account di archiviazione. È anche possibile usare lo stesso account di archiviazione dell'app per le funzioni per archiviare i dati dell'applicazione. Tuttavia, questo approccio non è sempre una scelta ideale in un ambiente di produzione.

Potrebbe essere necessario usare account di archiviazione separati per evitare conflitti di ID host.

Considerazioni sui criteri di gestione del ciclo di vita

Non è consigliabile applicare i criteri di gestione del ciclo di vita all'account di Archiviazione BLOB usato dall'app per le funzioni. Le funzioni usano l'archiviazione BLOB per rendere persistenti informazioni importanti, ad esempio le chiavi di accesso alle funzioni, e i criteri potrebbero rimuovere i BLOB (ad esempio le chiavi) necessari dall'host di Funzioni. Se è necessario usare i criteri, escludere i contenitori usati da Funzioni, preceduti azure-webjobs da o scm.

Log di archiviazione

Poiché il codice e le chiavi della funzione potrebbero essere persistenti nell'account di archiviazione, la registrazione dell'attività sull'account di archiviazione è un buon modo per monitorare l'accesso non autorizzato. I log delle risorse di Monitoraggio di Azure possono essere usati per tenere traccia degli eventi rispetto al piano dati di archiviazione. Per informazioni dettagliate su come configurare ed esaminare questi log, vedere Monitoraggio Archiviazione di Azure.

Il log attività di Monitoraggio di Azure mostra gli eventi del piano di controllo, inclusa l'operazione listKeys. È tuttavia necessario configurare anche i log delle risorse per l'account di archiviazione per tenere traccia dell'uso successivo di chiavi o altre operazioni del piano dati basato su identità. È necessario avere almeno la categoria di log Archiviazione Write abilitata per identificare le modifiche ai dati al di fuori delle normali operazioni di Funzioni.

Per limitare l'impatto potenziale di qualsiasi autorizzazione di archiviazione con ambito generale, è consigliabile usare una destinazione non di archiviazione per questi log, ad esempio Log Analytics. Per altre informazioni, vedere Monitoraggio di Archiviazione BLOB di Azure.

Ottimizzare le prestazioni di archiviazione

Per incrementare le prestazioni, usare un account di archiviazione diverso per ogni app per le funzioni. Questo accorgimento è particolarmente importante in presenza di funzioni attivate da Hub eventi o Durable Functions, che generano entrambe un volume elevato di transazioni di archiviazione. Quando la logica dell'applicazione interagisce con Archiviazione di Azure, direttamente (usando Storage SDK) o tramite una delle associazioni di archiviazione, è necessario usare un account di archiviazione dedicato. Ad esempio, se si dispone di una funzione attivata da Hub eventi che scrive alcuni dati nell'archivio BLOB, usare due account di archiviazione, uno per l'app per le funzioni e un altro per i BLOB archiviati dalla funzione.

Uso dei BLOB

Uno scenario chiave per Funzioni è l'elaborazione di file in un contenitore BLOB, ad esempio per l'elaborazione di immagini o l'analisi del sentiment. Per altre informazioni, vedere Elaborare i caricamenti dei file.

Trigger in un contenitore BLOB

Esistono diversi modi per eseguire il codice della funzione in base alle modifiche apportate ai BLOB in un contenitore di archiviazione. Usare la tabella seguente per determinare il trigger di funzione più adatto alle proprie esigenze:

Considerazioni Archiviazione BLOB (polling) Archiviazione BLOB (basata su eventi) Archiviazione code Griglia di eventi
Latenza Alto (fino a 10 minuti) Basso Medium Basso
limitazioni dell'account Archiviazione Account solo BLOB non supportati¹ utilizzo generico v1 non supportato Nessuno utilizzo generico v1 non supportato
Versione dell'estensione Any Archiviazione v5.x+ Qualsiasi Qualsiasi
Elabora i BLOB esistenti No No No
Filtri Modello di nome BLOB Filtri eventi n/d Filtri eventi
Richiede una sottoscrizione di eventi No No
Supporta scalabilità elevata² No
Descrizione Comportamento del trigger predefinito, che si basa sul polling del contenitore per gli aggiornamenti. Per altre informazioni, vedere gli esempi nel riferimento al trigger di archiviazione BLOB. Utilizza gli eventi di archiviazione BLOB da una sottoscrizione di eventi. Richiede un Source valore di parametro pari a EventGrid. Per altre informazioni, vedere Esercitazione: Attivare Funzioni di Azure nei contenitori BLOB usando una sottoscrizione di eventi. La stringa del nome BLOB viene aggiunta manualmente a una coda di archiviazione quando un BLOB viene aggiunto al contenitore. Questo valore viene passato direttamente da un trigger di archiviazione code a un'associazione di input dell'archiviazione BLOB nella stessa funzione. Offre la flessibilità di attivare eventi oltre a quelli provenienti da un contenitore di archiviazione. Usare quando è necessario anche che gli eventi di non archiviazione attivino la funzione. Per altre informazioni, vedere Come usare trigger e associazioni di Griglia di eventi in Funzioni di Azure.

1 Le associazioni di input e output dell'archiviazione BLOB supportano gli account solo BLOB.
2 La scalabilità elevata può essere definita in modo libero come contenitori con più di 100.000 BLOB in essi o account di archiviazione con più di 100 aggiornamenti BLOB al secondo.

Crittografia dei dati di archiviazione

Archiviazione di Azure crittografa tutti i dati in un account di archiviazione inattivo. Per altre informazioni, vedere Crittografia di Archiviazione di Azure per dati inattivi.

Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi di crittografia, è possibile specificare chiavi gestite dal cliente da usare per la crittografia dei dati BLOB e di file. Queste chiavi devono essere presenti in Azure Key Vault affinché le funzioni possano accedere all'account di archiviazione. Per altre informazioni, vedere Crittografia dei dati inattivi con le chiavi gestite dal cliente.

Residenza dei dati nell'area geografica

Quando tutti i dati dei clienti devono rimanere all'interno di una singola area, l'account di archiviazione associato all'app per le funzioni deve essere uno con ridondanza nell'area. È necessario usare anche un account di archiviazione con ridondanza nell'area con Funzioni permanenti di Azure.

Altri dati dei clienti gestiti dalla piattaforma vengono archiviati solo all'interno dell'area quando si ospita in un ambiente del servizio app con carico bilanciato internamente (A edizione Standard). Per altre informazioni, vedere Ridondanza della zona A edizione Standard.

Considerazioni sull'ID host

Funzioni usa un valore ID host come modo per identificare in modo univoco una particolare app per le funzioni negli artefatti archiviati. Per impostazione predefinita, questo ID viene generato automaticamente dal nome dell'app per le funzioni, troncato ai primi 32 caratteri. Questo ID viene quindi usato quando si archiviano le informazioni di correlazione e rilevamento per app nell'account di archiviazione collegato. Quando sono presenti app per le funzioni con nomi più lunghi di 32 caratteri e quando i primi 32 caratteri sono identici, questo troncamento può comportare valori di ID host duplicati. Quando due app per le funzioni con ID host identici usano lo stesso account di archiviazione, si ottiene un conflitto di ID host perché i dati archiviati non possono essere collegati in modo univoco all'app per le funzioni corretta.

Nota

Questo stesso tipo di collisore ID host può verificarsi tra un'app per le funzioni in uno slot di produzione e la stessa app per le funzioni in uno slot di staging, quando entrambi gli slot usano lo stesso account di archiviazione.

A partire dalla versione 3.x del runtime di Funzioni, viene rilevato un conflitto di ID host e viene registrato un avviso. Nella versione 4.x viene registrato un errore e l'host viene arrestato, causando un errore rigido. Altri dettagli sulla collisione con ID host sono disponibili in questo problema.

Evitare conflitti di ID host

È possibile usare le strategie seguenti per evitare conflitti di ID host:

  • Usare un account di archiviazione separato per ogni app per le funzioni o slot coinvolto nella collisione.
  • Rinominare una delle app per le funzioni in un valore di lunghezza inferiore a 32 caratteri, che modifica l'ID host calcolato per l'app e rimuove la collisione.
  • Impostare un ID host esplicito per una o più app in collisione. Per altre informazioni, vedere Override dell'ID host.

Importante

La modifica dell'account di archiviazione associato a un'app per le funzioni esistente o la modifica dell'ID host dell'app possono influire sul comportamento delle funzioni esistenti. Ad esempio, un trigger di archiviazione BLOB tiene traccia del fatto che i singoli BLOB vengano elaborati scrivendo ricevute in un percorso ID host specifico nell'archiviazione. Quando l'ID host cambia o si punta a un nuovo account di archiviazione, è possibile rielaborare i BLOB elaborati in precedenza.

Eseguire l'override dell'ID host

È possibile impostare in modo esplicito un ID host specifico per l'app per le funzioni nelle impostazioni dell'applicazione usando l'impostazione AzureFunctionsWebHost__hostid . Per altre informazioni, vedere AzureFunctionsWebHost__hostid.

Quando si verifica una collisione tra slot, è necessario impostare un ID host specifico per ogni slot, incluso lo slot di produzione. È anche necessario contrassegnare queste impostazioni come impostazioni di distribuzione in modo che non vengano scambiate. Per informazioni su come creare le impostazioni dell'app, vedere Usare le impostazioni dell'applicazione.

Cluster abilitati per Azure Arc

Quando l'app per le funzioni viene distribuita in un cluster Kubernetes abilitato per Azure Arc, un account di archiviazione potrebbe non essere richiesto dall'app per le funzioni. In questo caso, un account di archiviazione è richiesto solo da Funzioni quando l'app per le funzioni usa un trigger che richiede l'archiviazione. La tabella seguente indica quali trigger potrebbero richiedere un account di archiviazione e che non lo fanno.

Non obbligatorio potrebbe richiedere l'archiviazione
Azure Cosmos DB
HTTP
Kafka
RabbitMQ
bus di servizio
SQL di Azure
Archiviazione BLOB
Griglia di eventi
Hub eventi
hub IoT
Archiviazione code
SendGrid
SignalR
Archiviazione tabelle
Timer
Twilio

Per creare un'app per le funzioni in un cluster Kubernetes abilitato per Azure Arc senza archiviazione, è necessario usare il comando dell'interfaccia della riga di comando di Azure az functionapp create. La versione dell'interfaccia della riga di comando di Azure deve includere la versione 0.1.7 o successiva dell'estensione appservice-kube. Usare il az --version comando per verificare che l'estensione sia installata ed è la versione corretta.

La creazione di risorse dell'app per le funzioni usando metodi diversi dall'interfaccia della riga di comando di Azure richiede un account di archiviazione esistente. Se si prevede di usare trigger che richiedono un account di archiviazione, è necessario creare l'account prima di creare l'app per le funzioni.

Creare un'app senza File di Azure

File di Azure è configurato per impostazione predefinita per i piani a consumo Elastic Premium e non Linux da usare come file system condiviso in scenari su larga scala. Il file system viene usato dalla piattaforma per alcune funzionalità, ad esempio il flusso di log, ma garantisce principalmente la coerenza del payload della funzione distribuita. Quando un'app viene distribuita usando un URL del pacchetto esterno, il contenuto dell'app viene gestito da un file system di sola lettura separato. Ciò significa che è possibile creare l'app per le funzioni senza File di Azure. Se si crea l'app per le funzioni con File di Azure, viene comunque fornito un file system scrivibile. Tuttavia, questo file system potrebbe non essere disponibile per tutte le istanze dell'app per le funzioni.

Quando File di Azure non viene usato, è necessario soddisfare i requisiti seguenti:

  • È necessario eseguire la distribuzione da un URL del pacchetto esterno.
  • L'app non può basarsi su un file system scrivibile condiviso.
  • L'app non può usare la versione 1.x del runtime di Funzioni.
  • Registrare le esperienze di streaming nei client, ad esempio il portale di Azure impostazione predefinita per i log del file system. È invece consigliabile basarsi sui log di Application Insights.

Se l'account precedente è corretto, è possibile creare l'app senza File di Azure. Creare l'app per le funzioni senza specificare le impostazioni dell'applicazione WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE . È possibile evitare queste impostazioni generando un modello di Resource Manager per una distribuzione standard, rimuovendo le due impostazioni e quindi distribuendo il modello.

Poiché le funzioni usano File di Azure durante parti del processo di scalabilità orizzontale dinamico, il ridimensionamento potrebbe essere limitato quando è in esecuzione senza File di Azure nei piani Consumption e Elastic Premium.

Montare condivisioni file

Questa funzionalità è attualmente disponibile solo quando è in esecuzione in Linux.

È possibile montare condivisioni di File di Azure esistenti nelle app per le funzioni di Linux. Montando una condivisione nell'app per le funzioni Linux, è possibile usare modelli di Machine Learning esistenti o altri dati nelle funzioni. È possibile usare il comando seguente per montare una condivisione esistente nell'app per le funzioni Linux.

az webapp config storage-account add

In questo comando share-name è il nome della condivisione File di Azure esistente e custom-id può essere qualsiasi stringa che definisca in modo univoco la condivisione quando viene montata nell'app per le funzioni. mount-path, invece, è il percorso da cui viene eseguito l'accesso alla condivisione nell'app per le funzioni. mount-path deve essere nel formato /dir-name e non può iniziare con /home.

Per un esempio completo, vedere gli script in Creare un'app per le funzioni Python e montare una condivisione File di Azure.

Attualmente è supportato solo un storage-type di AzureFiles. È possibile montare solo cinque condivisioni in una determinata app per le funzioni. Il montaggio di una condivisione file può aumentare l'ora di avvio a freddo di almeno 200-300 ms o ancora di più quando l'account di archiviazione si trova in un'area diversa.

La condivisione montata è disponibile per il codice della funzione nel mount-path specificato. Ad esempio, quando mount-path è /path/to/mount, è possibile accedere alla directory di destinazione tramite API del file system, come nell'esempio Python seguente:

import os
...

files_in_share = os.listdir("/path/to/mount")

Passaggi successivi

Altre informazioni sulle opzioni di hosting di Funzioni di Azure.