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 | Gestire lo stato delle associazioni e i tasti funzione1. Origine di distribuzione per app eseguite in un piano a consumo Flex. 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 Azure2 | 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 specifici di Funzioni di Azure. 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. |
- L'archiviazione BLOB è l'archivio predefinito per le chiavi di funzione, ma è possibile configurare un archivio alternativo.
- File di Azure è configurato per impostazione predefinita, ma è possibile creare un'app senza File di Azure in determinate condizioni.
Considerazioni importanti
È necessario considerare 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 Account di archiviazione eliminato
I dati importanti, come 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. Prendere in considerazione la gestione dei log di archiviazione in una posizione diversa da Archiviazione di Azure. Per altre informazioni, vedere Log di archiviazione.
Requisiti dell'account di archiviazione
Gli account di archiviazione 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 la panoramica degli account di archiviazione.
Non è possibile usare un account di archiviazione protetto dalla rete quando l'app per le funzioni è ospitata nel piano a consumo.
Quando si crea l'app per le funzioni nel portale, è consentito scegliere un solo 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 Posizione dell'account di archiviazione.
Quando si crea l'app per le funzioni in un piano con supporto per la zona di disponibilità abilitato, sono supportati solo gli account di archiviazione con ridondanza della zona.
Quando si usa l'automazione della distribuzione per creare l'app per le funzioni con un account di archiviazione protetto dalla rete, è necessario includere configurazioni di rete specifiche nel modello ARM o nel file Bicep. Quando non si includono queste impostazioni e le risorse, la distribuzione automatizzata potrebbe non riuscire nella convalida. Per indicazioni più specifiche su ARM e Bicep, vedere Distribuzioni protette. Per una panoramica sulla configurazione degli account di archiviazione con la rete, vedere Come usare un account di archiviazione protetto con Funzioni di Azure.
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 sarà eseguibile. Per risolvere i problemi correlati all'archiviazione, vedere Come risolvere i problemi relativi all'archiviazione. Le altre considerazioni seguenti sono valide per l'account di 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, il che riduce la latenza. Il portale di Azure applica questa procedura consigliata. Se per qualche motivo è necessario usare un account di archiviazione in un'area diversa da quella dell’app per le funzioni, è necessario creare l'app per le funzioni al di fuori 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 connessione AzureWebJobsStorage come stringa di connessione archiviata nell'impostazione dell'applicazione AzureWebJobsStorage, ma è anche possibile configurare AzureWebJobsStorage affinché usi 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 la 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. È inoltre possibile creare un'app per le funzioni che non usa File di Azure, ma il ridimensionamento potrebbe essere limitato.
Nota
Se si rigenerano le chiavi di archiviazione, è necessario aggiornare le stringhe di connessione dell'account di archiviazione precedente. 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 di Azure. 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 conservare 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 conservati 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 di 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 di altre operazioni del piano dati basato su identità. È necessario avere almeno la categoria di log StorageWrite abilitata per identificare le modifiche apportate 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 è presente 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.
Routing coerente tramite reti virtuali
Più app per le funzioni ospitate nello stesso piano possono anche utilizzare lo stesso account di archiviazione per la condivisione dei contenuti di File di Azure (definita da WEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Quando questo account di archiviazione è protetto anche da una rete virtuale. Tutte queste app devono usare lo stesso valore per vnetContentShareEnabled (in precedenza WEBSITE_CONTENTOVERVNET) per garantire che il traffico venga instradato in modo coerente attraverso la rete virtuale prevista. Una mancata corrispondenza di questa impostazione tra le app che usano lo stesso account di archiviazione di File di Azure potrebbe comportare l'instradamento del traffico attraverso reti pubbliche, causando il blocco dell'accesso da parte delle regole di rete dell'account di archiviazione.
Uso dei BLOB
Uno scenario chiave di 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:
| Strategia | Contenitore (polling) | Contenitore (eventi) | Trigger di accodamento | Griglia di eventi |
|---|---|---|---|---|
| Latenza | Alto (fino a 10 minuti) | Basso | Medium | Basso |
| Limitazioni dell'account di archiviazione | Account solo BLOB non supportati¹ | utilizzo generico v1 non supportato | Nessuno | utilizzo generico v1 non supportato |
| Tipo di trigger | Archiviazione BLOB | Archiviazione BLOB | Archiviazione code | Griglia di eventi |
| Versione dell'estensione | Any | Archiviazione v5.x+ | Qualsiasi | Qualsiasi |
| Elabora i BLOB esistenti | Sì | No | No | No |
| Filtri | Modello nome BLOB | Filtri eventi | n/d | Filtri eventi |
| Richiede una sottoscrizione di eventi | No | Sì | No | Sì |
| Supporta il Piano a consumo Flex | No | Sì | Sì | Sì |
| Supporta scalabilità elevata² | No | Sì | Sì | Sì |
| Descrizione | Comportamento del trigger predefinito, che si basa sul polling del contenitore per gli aggiornamenti. Per altre informazioni, vedere gli esempi in Dizionari ed enciclopedie trigger di archiviazione BLOB. | Utilizza gli eventi di archiviazione BLOB di una sottoscrizione eventi. Richiede un valore di parametro Source di EventGrid. Per altre informazioni, vedere Esercitazione: Attivare Funzioni di Azure nei contenitori BLOB usando una sottoscrizione 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 che anche gli eventi non di archiviazione attivino la funzione. Per altre informazioni, vedere Come usare trigger e associazioni di Griglia di eventi in Funzioni di Azure. |
- Le associazioni di input e output dell'archiviazione BLOB supportano gli account solo BLOB.
- La scalabilità elevata può essere definita in modo generico come i contenitori con più di 100.000 BLOB o gli 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 avere ridondanza nell'area. È necessario usare un account di archiviazione con ridondanza nell'area anche con Durable Functions di Azure.
Altri dati dei clienti gestiti dalla piattaforma vengono archiviati solo all'interno dell'area quando l’hosting avviene in un ambiente del servizio app con carico bilanciato internamente. Per altre informazioni, vedere Ridondanza della zona dell'ambiente del servizio app.
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 conflitto 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 di funzionamento. Altri dettagli sul conflitto 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 nel conflitto.
- Rinominare una delle app per le funzioni in un valore con lunghezza inferiore a 32 caratteri, che modifica l'ID host calcolato per l'app e rimuove il conflitto.
- Impostare un ID host esplicito per una o più app in conflitto. 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 un conflitto tra slot, è necessario impostare un ID host specifico per ogni slot, incluso lo slot di produzione. È inoltre 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 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 quali no.
| Non obbligatorio | potrebbe richiedere l'archiviazione |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Bus di servizio |
• Azure SQL • 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 comando az --version per verificare che l'estensione sia installata e che sia la versione corretta.
La creazione di risorse dell'app per le funzioni con 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
Il servizio File di Azure fornisce un file system condiviso che supporta scenari su larga scala. Quando l'app per le funzioni viene eseguita in Windows in un piano Elastic Premium o a consumo, per impostazione predefinita viene creata una condivisione file di Azure nell'account di archiviazione. Tale condivisione viene usata da Funzioni per abilitare determinate funzionalità, ad esempio lo streaming di log. Viene usata anche come percorso di distribuzione del pacchetto condiviso, il che garantisce la coerenza del codice della funzione distribuita in tutte le istanze.
Per impostazione predefinita, le app per le funzioni ospitate nei piani Premium e a consumo usano la distribuzione zip, con i pacchetti di distribuzione archiviati in questa condivisione file di Azure. Questa sezione è rilevante solo per questi piani di hosting.
L'uso di File di Azure richiede l'uso di una stringa di connessione archiviata nelle impostazioni dell'app come WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. File di Azure non supporta attualmente le connessioni basate sull'identità. Se lo scenario richiede di non archiviare segreti nelle impostazioni dell'app, è necessario rimuovere la dipendenza dell'app da File di Azure. A tale scopo, è possibile creare l'app senza la dipendenza predefinita di File di Azure.
Nota
È anche consigliabile prendere in considerazione l'esecuzione nell'app per le funzioni nel piano a consumo Flex, che offre un maggiore controllo sul pacchetto di distribuzione, inclusa la possibilità di usare connessioni di identità gestite. Per altre informazioni, vedere Configurare le impostazioni di distribuzione nell'articolo Utilizzo a consumo Flex.
Per eseguire l'app senza la condivisione file di Azure, è necessario soddisfare i requisiti seguenti:
- È necessario distribuire il pacchetto in un contenitore di archiviazione BLOB di Azure remoto e quindi impostare l'URL che fornisce l'accesso a tale pacchetto come impostazione dell'app
WEBSITE_RUN_FROM_PACKAGE. Questa opzione consente di archiviare il contenuto dell'app nell'archiviazione BLOB anziché in File di Azure, il che supporta le identità gestite.
L'utente è responsabile dell'aggiornamento manuale del pacchetto di distribuzione e della gestione dell'URL del pacchetto di distribuzione, che probabilmente contiene una firma di accesso condiviso.
- L'app non può basarsi su un file system scrivibile condiviso.
- L'app non può usare la versione 1.x del runtime di Funzioni.
- Il registro delle esperienze di streaming nei client come il portale di Azure utilizzano di default i log del file system. È invece consigliabile basarsi sui log di Application Insights.
Se i requisiti precedenti soddisfano lo scenario, è possibile procedere con la creazione di un'app per le funzioni senza File di Azure. A tale scopo, è possibile creare un'app senza le impostazioni dell'app WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE. Per iniziare, generare un modello di Resource Manager per una distribuzione standard, rimuovere le due impostazioni e quindi distribuire il modello modificato.
Poiché File di Azure viene usato per abilitare la scalabilità orizzontale dinamica per Funzioni, il ridimensionamento potrebbe essere limitato quando si esegue l'app senza File di Azure nel piano Elastic Premium e nei piani a consumo in esecuzione su Windows.
Montare condivisione 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 di Linux è possibile usare i 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 di 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 i tempi di avvio a freddo di almeno 200-300 ms o anche oltre se 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.