Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si crea un'istanza dell'app per le funzioni in Azure, è necessario fornire l'accesso a un account di Archiviazione di Azure predefinito. Il diagramma e la tabella seguenti illustrano in dettaglio come Funzioni di Azure usa i servizi nell'account di archiviazione predefinito:
Seleziona il tuo piano di hosting in cima a questo articolo per visualizzare le linee guida sullo stoccaggio applicate alla tua app funzionale.
| Servizio di archiviazione | Utilizzo delle funzioni |
|---|---|
| Archiviazione di Azure Blob | 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 task hub 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. Gestire i bundle di estensioni. Archiviare i log di distribuzione. Supporta le dipendenze gestite in PowerShell. |
| Archiviazione code di Azure | Usato per impostazione predefinita per gli task hub in Durable Functions. Usato per la gestione degli errori e dei nuovi tentativi nei trigger specifici delle Funzioni di Azure. Usato per il rilevamento degli oggetti dal trigger di archiviazione BLOB. |
| Archiviazione tabelle di Azure | Usato per impostazione predefinita per gli task hub in Durable Functions. Usato per tenere traccia degli eventi di diagnostica. |
- 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
Considera i seguenti dati riguardo agli account di archiviazione utilizzati dalle tue app funzionali:
Quando ospiti la tua app funzione sul piano Consumption (Windows) o Premium, memorizzi il codice funzione e i file di configurazione in File di Azure nell'account di archiviazione collegato. Se elimini questo account di archiviazione, elimini permanentemente il contenuto. Per altre informazioni, vedere Account di archiviazione è stato eliminato.
L'account di archiviazione conserva dati importanti, come il codice di funzione, le chiavi di accesso e altri dati importanti relativi al servizio. È 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.
Se si usa Durable Functions, l'archiviazione dell'hub attività è particolarmente sensibile alla sicurezza perché l'accesso in scrittura può essere usato per modificare il comportamento dell'applicazione, inclusa l'attivazione di un'esecuzione arbitraria del codice. Per ulteriori informazioni, vedi Proteggere l'archivio dell'hub attività.
Requisiti dell'account di archiviazione
Gli account di archiviazione creati durante il processo di creazione dell'app per le funzioni nel portale di Azure funzionano 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. Assicurati che un account di archiviazione esistente soddisfi questi requisiti:
- Non è possibile usare un account di archiviazione protetto dalla rete quando l'app per le funzioni è ospitata nel piano a consumo.
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.
Quando si crea l'app per le funzioni nel portale di Azure, è possibile scegliere solo un account di archiviazione esistente nella stessa area dell'app per le funzioni creata. Questo requisito è un'ottimizzazione delle prestazioni e non 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 utilizza l'automazione della distribuzione per creare l'app per le funzioni con un account di archiviazione con protezione di rete, è necessario includere configurazioni di rete specifiche nel modello ARM o nel file Bicep. Se non si includono queste impostazioni e risorse, la distribuzione automatizzata potrebbe non riuscire nella convalida. Per informazioni sul modello ARM e indicazioni su 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 si elimina quell'account, la tua app per le funzioni smette di funzionare. Per risolvere i problemi correlati all'archiviazione, vedere Come risolvere i problemi relativi all'archiviazione. Le considerazioni seguenti si applicano all'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 è 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 di Azure.
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. È anche possibile configurare AzureWebJobsStorage 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 la stringa di connessione per l'account di archiviazione nell'impostazione WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e il nome della condivisione file nell'impostazione WEBSITE_CONTENTSHARE. Questo valore è in genere lo 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.
Note
È necessario aggiornare la stringa di connessione dell'account di archiviazione quando si rigenerano le chiavi di archiviazione. Per altre informazioni, vedere Creare un account di archiviazione Azure.
Account di archiviazione condivisi
Più app per le funzioni possono condividere 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. Lo stesso account di archiviazione usato dall'app per le funzioni può anche 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 applicare i criteri di gestione del ciclo di vita all'account gestione rete virtuale di Azure usato dall'app per le funzioni. Funzioni usa l'archiviazione BLOB per rendere persistenti informazioni importanti, ad esempio le chiavi di accesso alle funzioni. Le policy potrebbero rimuovere i blob, come ad esempio le chiavi, necessarie per l'host di Functions. 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 relativi al piano dati di archiviazione. Vedere Monitoraggio Archiviazione di Azure per informazioni dettagliate su come configurare ed esaminare questi log.
Il registro attività 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 Monitoring 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 approccio è particolarmente importante quando si hanno Durable Functions o funzioni attivate da Hub eventi, che generano entrambi 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, è consigliabile usare un account di archiviazione dedicato. Ad esempio, se si dispone di una funzione attivata dall'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 di funzioni ospitate nello stesso piano possono anche usare lo stesso account di archiviazione per la condivisione di contenuti File di Azure definita da WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Quando si protegge questo account di archiviazione usando una rete virtuale, tutte queste app (inclusi gli slot) devono usare lo stesso valore per vnetContentShareEnabled (in precedenza WEBSITE_CONTENTOVERVNET) e la stessa configurazione di integrazione della rete virtuale per garantire che il traffico venga instradato in modo coerente attraverso la rete virtuale prevista. Una mancata corrispondenza in questa impostazione tra le app che usano lo stesso account di archiviazione File di Azure potrebbe comportare il routing del traffico attraverso reti pubbliche. In questa configurazione le regole di rete dell'account di archiviazione bloccano l'accesso.
La vnetContentShareEnabled guida non si applica a Flex Consumption, Dedicated, Container App o Consumption Hosting.
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, come indicato in questo diagramma:
Usare la tabella seguente per determinare il trigger di funzione più adatto alle esigenze di elaborazione di BLOB aggiunti o aggiornati in un contenitore:
| Strategia | Trigger Blob (polling) | Trigger BLOB (guidato dagli eventi) | Trigger della coda | Trigger Griglia di eventi |
|---|---|---|---|---|
| Latenza | Alto (fino a 10 minuti) | Basso | Intermedio | Basso |
| Limitazioni dell'account di archiviazione | Non supporta gli account solo BLOB¹ né gli account con namespace gerarchico (HNS) abilitato, come gli account Azure Data Lake Storage Gen2 | Non supporta gli account per utilizzo generico v1 | Nessuno | Non supporta gli account v1 per utilizzo generico |
| Tipo di trigger | Archiviazione BLOB | Archiviazione BLOB | Archiviazione code | Griglia di eventi |
| Versione dell'estensione | Qualsiasi | 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ì |
| Funziona con le restrizioni di accesso in ingresso | Sì | NO | Sì | Sì3 |
| 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 Tutorial: 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. Un trigger di accodamento passa questo valore direttamente a un'associazione di input dell'archiviazione di 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. |
- La limitazione degli account di solo tipo BLOB si applica solo al trigger di Archiviazione BLOB basato sul polling. 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.
- È possibile aggirare le restrizioni di accesso in ingresso, facendo sì che la sottoscrizione degli eventi invii i dati su un canale crittografato nello spazio degli indirizzi IP pubblici, utilizzando un'identità utente nota. Per altre informazioni, vedere Distribuire eventi in modo sicuro usando le identità gestite.
Crittografia dei dati di archiviazione
Archiviazione di Azure crittografa tutti i dati a riposo in un account di archiviazione. Per ulteriori informazioni, vedere la crittografia di Archiviazione di Azure per i dati inattivi.
Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi di crittografia, è possibile fornire chiavi gestite dal cliente da usare per la crittografia dei dati di BLOB e file. Queste chiavi devono essere presenti in Azure Key Vault affinché Funzioni sia in grado di accedere all'account di archiviazione. Per ulteriori informazioni, consulta Crittografa i dati dell'applicazione a riposo utilizzando chiavi gestite dal cliente.
Residenza dei dati nell'area geografica
Quando tutti i dati dei clienti devono rimanere all'interno di un'unica area geografica, usa un account di archiviazione associato all'app per le funzioni che dispone di ridondanza interna all'area geografica. Usa anche un account di archiviazione ridondante in regione con Azure Durable Functions.
La piattaforma memorizza altri dati dei clienti gestiti dalla piattaforma solo all'interno della regione quando si ospita in un ambiente del servizio app (ASE) con bilanciamento interno del carico. Per altre informazioni, vedere Ridondanza della zona dell'ambiente del servizio app.
Considerazioni sull'ID host
Le considerazioni sull'ID host in questa sezione non si applicano al Flex Consumption. In questo piano di hosting, il valore dell'ID host viene creato in modo da evitare questi potenziali problemi.
Functions utilizza un valore di host ID per identificare in modo univoco una particolare function app negli artefatti memorizzati. Per impostazione predefinita, il runtime genera automaticamente questo ID a partire dal nome dell'app per le funzioni, limitato ai primi 32 caratteri. L'runtime utilizza questo ID quando memorizza le informazioni di correlazione e tracciamento per app nell'account di archiviazione collegato. Quando le app a funzione hanno nomi più lunghi di 32 caratteri e i primi 32 caratteri sono identici, questa troncatura può portare a valori duplicati dell'ID host. Quando due app di funzione con ID host identici usano lo stesso account di archiviazione, si verifica una collisione degli ID host perché i dati memorizzati non possono essere collegati in modo univoco all'app di funzione corretta.
Note
Lo stesso tipo di collisione dell'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.
Nella versione 4.x del runtime Functions, viene registrato un errore e l'host si ferma, causando un fallimento totale. Per altre informazioni, vedere Il troncamento dell'ID Host può causare collisioni.
Evitare conflitti di ID host
Utilizzare le seguenti strategie per evitare collisioni con l'ID dell'host:
- Usa account di archiviazione separati in modo che ogni host in collisione scriva su un account diverso.
- Rinomina una delle tue app di funzione in modo che il suo nome sia inferiore a 32 caratteri, il che cambia l'ID host calcolato per l'app e rimuove la collisione.
- Impostare un ID host esplicito per una o più app in conflitto. Per altre informazioni, vedere Eseguire l'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 storage Blob traccia se elabora i singoli blob scrivendo ricevute sotto un percorso specifico dell'ID host nello storage. 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
Puoi impostare un ID host esplicito per la tua app funzione nelle impostazioni dell'applicazione usando l'impostazione AzureFunctionsWebHost__hostid . Per altre informazioni, vedere AzureFunctionsWebHost__hostid.
Quando si verifica una collisione tra slot, devi impostare un ID host specifico per ogni slot, incluso quello 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.
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 un piano Elastic Premium o su Windows in un piano di Consumo, viene creata automaticamente una condivisione File di Azure nel tuo account di archiviazione. Le funzioni possono utilizzare questa condivisione per funzionalità come lo streaming di log e come posizione condivisa di contenuti dell'app. La località di distribuzione dipende dalla tecnologia di distribuzione e dalla configurazione dell'app. Ad esempio, un'app che utilizza un URL di pacchetto esterno esegue il suo pacchetto dall'URL configurato invece che dalla condivisione File di Azure.
Usare File di Azure richiede una stringa di connessione, che memorizzi nelle impostazioni dell'app come WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. File di Azure attualmente non supporta le connessioni basate sull'identità. Se il tuo scenario richiede di non memorizzare segreti nelle impostazioni dell'app, devi rimuovere la dipendenza dell'app da File di Azure. È possibile evitare questa dipendenza creando l'app senza la dipendenza predefinita File di Azure.
Note
Dovresti anche considerare di eseguire la tua app di funzionalità nel piano Flex Consumption, che offre un maggiore controllo sul pacchetto di distribuzione, inclusa la possibilità di utilizzare connessioni di identità gestite. Per altre informazioni, vedere Configurare le impostazioni di distribuzione.
Per eseguire la tua app senza la condivisione File di Azure, devi soddisfare i seguenti requisiti:
Devi distribuire il tuo pacchetto su un container Archiviazione BLOB di Azure che non consenta l'accesso anonimo e impostare l'URL gestione rete virtuale di Azure del pacchetto come impostazione dell'
WEBSITE_RUN_FROM_PACKAGEapp.Per evitare di memorizzare una credenziale di distribuzione nell'URL del pacchetto, concedi all'identità gestita dell'app per le funzioni l'accesso al pacchetto. Quando si utilizza un'identità assegnata dall'utente, impostare anche
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID. Se non puoi usare l'identità gestita, usa un URL con firma di accesso condiviso (SAS) e rinnovalo prima che il SAS scada.Per rimuovere la stringa di connessione dell'account di archiviazione host predefinito dalle impostazioni dell'app, configura
AzureWebJobsStorageper l'uso di un'identità gestita.Devi aggiornare manualmente il pacchetto di distribuzione e mantenere l'URL del pacchetto di distribuzione. Per informazioni su come riavviare l'app e sincronizzare i trigger quando aggiorni il pacchetto, vedi Run from an external package URL.
È anche consigliabile tenere presenti le considerazioni seguenti:
- L'app non può usare la versione 1.x del runtime di Funzioni.
- La tua app non può affidarsi a un file system scrittibile condiviso.
- La modifica del portale non è supportata.
- 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. Creare un'app senza le impostazioni dell'app WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE in uno dei modi seguenti:
- Modelli Bicep/ARM: rimuovi le due impostazioni dell'app dal template ARM o dal file Bicep e poi distribuisci l'app usando il template modificato.
- Il portale Azure: cancella Aggiungi una connessione File di Azure nella scheda Storage quando crei l'app nel portale Azure.
File di Azure viene usato per abilitare la scalabilità orizzontale dinamica per Funzioni. Il ridimensionamento può essere limitato quando si esegue l'app senza File di Azure nel piano Elastic Premium e nei piani a consumo in esecuzione in Windows.
Flex Consumption non dipende da una condivisione di contenuti File di Azure. Utilizza storage configurabile per il deployment Blob e supporta connessioni di identità gestite. Per altre informazioni, vedere Configurare le impostazioni di distribuzione.
Le app dedicate ai piani non hanno la dipendenza predefinita di File di Azure dalla condivisione contenuti descritta in questa sezione.
Le funzioni su App contenitore di Azure non hanno la dipendenza predefinita di File di Azure in condivisione di contenuti descritta in questa sezione.
Montare condivisioni file
Questa funzionalità è disponibile solo quando eseguita su Linux.
Puoi montare condivisioni File di Azure nelle tue app di funzione Linux, che puoi usare per accedere a file esistenti, modelli di machine learning o grandi binari nelle tue funzioni. Per indicazioni concettuali sulla scelta tra montaggi di archiviazione, associazioni e database esterni, vedere Scegliere una strategia di accesso ai file per Funzioni di Azure.
Flex Consumption supporta solo i mount di File di Azure tramite Server Message Block (SMB).
Usa il seguente comando per montare una condivisione esistente nella tua app di funzionalità Linux.
az webapp config storage-account add - Questo comando aggiunge un account di archiviazione alla configurazione di un'app web.
In questo comando share-name è il nome della condivisione File di Azure esistente.
custom-id può essere qualsiasi stringa che definisce in modo univoco la condivisione quando 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 Creare un'app per le funzioni Python e montare una condivisione File di Azure.
Per le Functions on App contenitore di Azure, configurare un volume di File di Azure nell'app container. Per altre informazioni, vedere Usare i montaggi di archiviazione in App contenitore di Azure.
Le montature di stoccaggio non sono supportate nel piano Consumo.
Importante
Le app basate su funzioni ancora in esecuzione con il runtime v3 in stato end-of-life su Linux in un piano A consumo smetteranno di funzionare dopo il 30 settembre 2026. Per evitare interruzioni del servizio, eseguire la migrazione dell'app al runtime v4.
L'opzione di ospitare le app basate su funzioni su Linux con un piano A consumo verrà ritirata il 30 settembre 2028. Il piano a consumo di Linux non riceverà nuove funzionalità o versioni linguistiche. Le applicazioni in esecuzione su Windows in un piano di consumo non sono attualmente interessate. Eseguire la migrazione delle app al piano Flex Consumption prima della data di ritiro.
Articolo correlato
Altre informazioni sulle opzioni di hosting Funzioni di Azure.