Guida per sviluppatori di Funzioni di Azure
In Funzioni di Azure tutte le funzioni condividono alcuni concetti tecnici e componenti di base, indipendentemente dal linguaggio o dall'ambiente di sviluppo preferito. Questo articolo è specifico della lingua. Scegliere la lingua preferita nella parte superiore dell'articolo.
Questo articolo presuppone che sia già stato letto Panoramica di Funzioni di Azure.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva tramite Visual Studioo Visual Studio Code o dal prompt dei comandi.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva usando Maven (riga di comando), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud o Visual Studio Code.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva tramite Visual Studio Code o dal prompt dei comandi.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva tramite Visual Studio Code o dal prompt dei comandi.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva tramite Visual Studio Code o dal prompt dei comandi.
Se si preferisce iniziare subito, è possibile completare un'esercitazione introduttiva tramite Visual Studio Code o dal prompt dei comandi.
Progetto di codice
Alla base di Funzioni di Azure è presente un progetto di codice specifico del linguaggio che implementa una o più unità di esecuzione del codice denominate funzioni. Le funzioni sono semplicemente metodi eseguiti nel cloud di Azure in base agli eventi, in risposta alle richieste HTTP o in base a una pianificazione. Si pensi al progetto di codice di Funzioni di Azure come a un meccanismo per organizzare, distribuire e gestire collettivamente le singole funzioni nel progetto quando vengono eseguite in Azure. Per altre informazioni, vedere Organizzare le funzioni.
Il modo in cui si dispone il progetto di codice e come indicare quali metodi nel progetto sono funzioni dipende dal linguaggio di sviluppo del progetto. Per indicazioni dettagliate specifiche del linguaggio, vedere la Guida per sviluppatori C#.
Il modo in cui si dispone il progetto di codice e come indicare quali metodi nel progetto sono funzioni dipende dal linguaggio di sviluppo del progetto. Per indicazioni specifiche del linguaggio, vedere la Guida per sviluppatori Java.
Il modo in cui si dispone il progetto di codice e come indicare quali metodi nel progetto sono funzioni dipende dal linguaggio di sviluppo del progetto. Per indicazioni specifiche del linguaggio, vedere la Guida per sviluppatori Node.js.
Il modo in cui si dispone il progetto di codice e come indicare quali metodi nel progetto sono funzioni dipende dal linguaggio di sviluppo del progetto. Per indicazioni specifiche del linguaggio, vedere la Guida per sviluppatori PowerShell.
Il modo in cui si dispone il progetto di codice e come indicare quali metodi nel progetto sono funzioni dipende dal linguaggio di sviluppo del progetto. Per indicazioni specifiche del linguaggio, vedere la Guida per sviluppatori Python.
Tutte le funzioni devono avere un trigger, che definisce l'avvio della funzione e può fornirle input. Le funzioni possono facoltativamente definire associazioni di input e output. Queste associazioni semplificano le connessioni ad altri servizi senza dover usare SDK client. Per altre informazioni, vedere Concetti relativi a trigger e associazioni in Funzioni di Azure.
Funzioni di Azure offre un set di modelli di funzione e progetto specifici del linguaggio che semplificano la creazione di nuovi progetti di codice e l'aggiunta di funzioni al progetto. È possibile usare uno degli strumenti che supportano lo sviluppo di Funzioni di Azure per generare nuove app e funzioni usando questi modelli.
Strumenti di sviluppo
Gli strumenti seguenti offrono un'esperienza di sviluppo e pubblicazione integrata per Funzioni di Azure nel linguaggio preferito:
Azure Functions Core Tools (prompt dei comandi)
Questi strumenti si integrano con Azure Functions Core Tools in modo da consentire l'esecuzione e il debug nel computer locale usando il runtime di Funzioni. Per altre informazioni, vedere Scrivere codice per Funzioni di Azure e testarle in locale.
È disponibile anche un editor nel portale di Azure che consente di aggiornare il codice e il file di definizione function.json direttamente nel portale. È consigliabile usare questo editor solo per piccole modifiche o creare funzioni di verifica. È consigliabile sviluppare sempre le funzioni in locale, quando possibile. Per altre informazioni, vedere Creare la prima funzione nel portale di Azure.
La modifica del portale è supportata solo per Node.js versione 3, che usa il file function.json.
Distribuzione
Quando si pubblica il progetto di codice in Azure, si distribuisce essenzialmente il progetto in una risorsa dell'app per le funzioni esistente. Un'app per le funzioni offre un contesto di esecuzione in Azure in cui vengono eseguite le funzioni. Di conseguenza, è l'unità di distribuzione e gestione per le funzioni. Dal punto di vista delle risorse di Azure, un'app per le funzioni equivale a una risorsa del sito (Microsoft.Web/sites
) nel servizio app di Azure, equivalente a un'app Web.
Un'app per le funzioni è costituita da una o più funzioni singole che vengono gestite, distribuite e ridimensionate insieme. Tutte le funzioni in un'app per le funzioni condividono lo stesso piano tariffario, lo stesso metodo di distribuzione e la stessa versione di runtime. Per altre informazioni, vedere Come gestire un'app per le funzioni.
Quando l'app per le funzioni e tutte le altre risorse necessarie non esistono già in Azure, è prima necessario creare queste risorse prima di poter distribuire i file di progetto. È possibile creare queste risorse in uno dei modi seguenti:
- Durante la pubblicazione di Visual Studio
Usando Visual Studio Code
A livello di codice usando l'interfaccia della riga di comando di Azure, Azure PowerShell, modelli ARM o modelli Bicep
Nel portale di Azure
Oltre alla pubblicazione basata su strumenti, Funzioni supporta altre tecnologie per la distribuzione del codice sorgente in un'app per le funzioni esistente. Per altre informazioni, vedere Tecnologie di distribuzione in Funzioni di Azure.
Connettersi ai servizi
Un requisito principale di qualsiasi servizio di calcolo basato sul cloud consiste nel leggere i dati e scrivere dati in altri servizi cloud. Funzioni offre un ampio set di associazioni che semplifica la connessione ai servizi senza dover usare SDK client.
Indipendentemente dal fatto che si usino le estensioni di associazione offerte da Funzioni o si usino direttamente gli SDK client, si archiviano in modo sicuro i dati di connessione senza includerli nel codice. Per altre informazioni, vedere Connections.
Bindings
Funzioni offre associazioni per molti servizi di Azure e alcuni servizi di terze parti, implementati come estensioni. Per altre informazioni, vedere l'elenco completo delle associazioni supportate.
Le estensioni di associazione possono supportare sia input che output e molti trigger fungono anche da associazioni di input. Le associazioni consentono di configurare la connessione ai servizi in modo che l'host di Funzioni possa gestire automaticamente l'accesso ai dati. Per altre informazioni, vedere Concetti relativi a trigger e associazioni in Funzioni di Azure.
Se si verificano problemi con errori provenienti dalle associazioni, vedere la documentazione Codici di errore di associazione di Funzioni di Azure.
SDK client
Sebbene Funzioni offra associazioni per semplificare l'accesso ai dati nel codice della funzione, è comunque possibile usare un SDK client nel progetto per accedere direttamente a un determinato servizio, se si preferisce. Potrebbe essere necessario usare direttamente SDK client se le funzioni richiedono una funzionalità dell'SDK sottostante non supportata dall'estensione di associazione.
Quando si usano SDK client, è consigliabile usare lo stesso processo per archiviare e accedere alle stringhe di connessione usate dalle estensioni di associazione.
Quando si crea un'istanza dell'SDK client nelle funzioni, è necessario ottenere le informazioni di connessione richieste dal client dalle variabili di ambiente.
Quando si crea un'istanza dell'SDK client nelle funzioni, è necessario ottenere le informazioni di connessione richieste dal client dalle variabili di ambiente.
Quando si crea un'istanza dell'SDK client nelle funzioni, è necessario ottenere le informazioni di connessione richieste dal client dalle variabili di ambiente.
Quando si crea un'istanza dell'SDK client nelle funzioni, è necessario ottenere le informazioni di connessione richieste dal client dalle variabili di ambiente.
Quando si crea un'istanza dell'SDK client nelle funzioni, è necessario ottenere le informazioni di connessione richieste dal client dalle variabili di ambiente.
Connessioni
Come procedura consigliata per la sicurezza, Funzioni di Azure sfrutta le funzionalità delle impostazioni dell'applicazione del servizio app di Azure per consentire di archiviare in modo più sicuro stringhe, chiavi e altri token necessari per connettersi ad altri servizi. Le impostazioni dell'applicazione in Azure vengono archiviate crittografate e possono essere accessibili in fase di esecuzione dall'app come coppie name
value
di variabili di ambiente. Per i trigger e le associazioni che richiedono una proprietà di connessione, impostare il nome dell'impostazione dell'applicazione anziché la stringa di connessione effettiva. Non è possibile configurare un'associazione direttamente con una stringa di connessione o una chiave.
Si consideri, ad esempio, una definizione di trigger con una proprietà connection
. Anziché la stringa di connessione, impostare connection
sul nome di una variabile di ambiente contenente la stringa di connessione. L'uso di questa strategia di accesso ai segreti rende le app più sicure e semplifica la modifica delle connessioni tra ambienti. Per una maggiore sicurezza, è possibile usare connessioni basate su identità.
Il provider di configurazione predefinito usa variabili di ambiente. Queste variabili vengono definite nelle impostazioni dell'applicazione durante l'esecuzione in Azure e nel file delle impostazioni locali durante lo sviluppo in locale.
Valori delle connessioni
Quando la risoluzione del nome della connessione genera un singolo valore esatto, durante il runtime tale valore viene identificato come stringa di connessione, in cui, di solito, è incluso un segreto. I dettagli di una stringa di connessione dipendono dal servizio a cui ci si connette.
Tuttavia, un nome di connessione può anche fare riferimento a una raccolta di più elementi di configurazione, utile per configurare le connessioni basate su identità. Le variabili di ambiente possono essere gestite come una raccolta utilizzando un prefisso condiviso che termina con doppio underscore __
. A questo punto, sarà possibile definire un riferimento al gruppo impostando il nome della connessione su questo prefisso.
Ad esempio, la proprietà connection
per una definizione di trigger BLOB di Azure potrebbe essere Storage1
. Se non esiste un singolo valore stringa configurato da una variabile di ambiente denominata Storage1
, è possibile usare una variabile di ambiente denominata Storage1__blobServiceUri
per informare la proprietà blobServiceUri
della connessione. Le proprietà di connessione sono diverse per ogni servizio. Fare riferimento alla documentazione relativa al componente che usa la connessione.
Nota
Quando si usano Configurazione app di Azure o Key Vault per fornire le impostazioni per le connessioni di Identità gestita, i nomi delle impostazioni devono usare un separatore di chiavi valido, ad esempio :
o /
invece di __
per garantire che i nomi vengano risolti correttamente.
Ad esempio: Storage1:blobServiceUri
.
Configurare una connessione basata sull'identità
Alcune connessioni in Funzioni di Azure possono essere configurate per l'uso di un'identità anziché di un segreto. Il supporto dipende dalla versione di runtime e dall'estensione che usa la connessione. In alcuni casi, potrebbe essere comunque necessaria una stringa di connessione in Funzioni, anche se il servizio a cui ci si connette supporta le connessioni basate su identità. Per un'esercitazione sulla configurazione delle app per le funzioni con identità gestite, vedere l'esercitazione Creazione di un'app per le funzioni con connessioni basate sull'identità.
Nota
Quando viene eseguita in un piano a consumo o Elastic Premium, l'app usa le impostazioni WEBSITE_AZUREFILESCONNECTIONSTRING
e WEBSITE_CONTENTSHARE
durante la connessione a File di Azure nell'account di archiviazione usato dall'app per le funzioni. File di Azure non supporta l'uso dell'identità gestita quando si accede alla condivisione file. Per altre informazioni, vedere Scenari di autenticazione supportati da File di Azure
Le connessioni basate su identità sono supportate solo in Funzioni 4.x. Se si usa la versione 1.x, è prima necessario eseguire la migrazione alla versione 4.x.
I componenti seguenti supportano connessioni basate su identità:
Quando sono ospitate nel servizio Azure Functions, le connessioni basate su identità usano una identità gestita. Per impostazione predefinita, viene usata l’identità assegnata a livello di sistema, ma è comunque possibile specificare un’identità assegnata dall’utente a cui siano associate le proprietà credential
e clientID
. Si noti che la configurazione di un'identità assegnata dall'utente con un ID risorsa non è supportata. Quando viene eseguita in altri contesti, ad esempio lo sviluppo locale, viene usata l'identità dello sviluppatore, anche se può essere personalizzata. Vedere Sviluppo locale con connessioni basate su identità.
Concedere l'autorizzazione all'identità
Qualsiasi identità usata deve avere le autorizzazioni necessarie per eseguire le azioni previste. Per la maggior parte dei servizi di Azure, questo significa che è necessario assegnare un ruolo nel controllo degli accessi in base al ruolo di Azure, usando ruoli predefiniti o personalizzati che forniscono tali autorizzazioni.
Importante
È possibile che alcune autorizzazioni esposte dal servizio di destinazione non siano necessarie per tutti i contesti. Laddove possibile, rispettare il principio dei privilegi minimi e concedere all’identità solo i privilegi necessari. Ad esempio, se l'app deve essere in grado di leggere solo da un'origine dati, usare un ruolo che disponga solo dell'autorizzazione per la lettura. Sarebbe inappropriato assegnare un ruolo che consenta anche la scrittura in tale servizio, in quanto sarebbe eccessiva l'autorizzazione per un'operazione di lettura. Analogamente, è consigliabile assicurarsi che l'assegnazione di ruolo sia con ambito solo sulle risorse che devono essere lette.
Scegliere una di queste schede per ottenere informazioni sulle autorizzazioni per ogni componente:
- Estensione BLOB di Azure
- Estensione Code di Azure
- Estensione Tabelle di Azure
- Estensione Hub eventi
- Estensione Bus di servizio
- Estensione Griglia di eventi
- Estensione Azure Cosmos DB
- Estensione Azure SignalR
- Provider di archiviazione Durable Functions
- Archiviazione host di Funzioni
È necessario creare un'assegnazione di ruolo che fornisca l'accesso al contenitore BLOB in fase di esecuzione. I ruoli di gestione come Proprietario non sono sufficienti. Nella tabella seguente vengono illustrati i ruoli predefiniti consigliati quando si usa l'estensione Archiviazione BLOB in condizioni di normale funzionamento. L'applicazione potrebbe richiedere ulteriori autorizzazioni in base al codice scritto.
Tipo di associazione | Ruoli predefiniti di esempio |
---|---|
Trigger | Proprietario dei dati del BLOB di archiviazione e Collaboratore ai dati della coda di archiviazione1 È necessario concedere autorizzazioni aggiuntive anche alla connessione AzureWebJobsStorage.2 |
Associazione di input | Lettore dei dati del BLOB di archiviazione |
Associazione di output | Proprietario dei dati del BLOB di archiviazione |
1 Il trigger BLOB gestisce l'errore tra più tentativi scrivendo BLOB non elaborabili in una coda nell'account di archiviazione specificato dalla connessione.
2 La connessione AzureWebJobsStorage viene usata internamente per BLOB e code che abilitano il trigger. Se è configurato per l'uso di una connessione basata su identità, sono necessarie autorizzazioni aggiuntive oltre il requisito predefinito. Le autorizzazioni necessarie sono coperte dai ruoli Proprietario dei dati del BLOB di archiviazione, Collaboratore ai dati della coda di archiviazione e Collaboratore dell'account di archiviazione. Per altre informazioni, vedere Connessione all'archiviazione host con un'identità.
Proprietà comuni per le connessioni basate su identità
Una connessione basata su identità per un servizio di Azure accetta le proprietà comuni seguenti, in cui <CONNECTION_NAME_PREFIX>
è il valore della proprietà connection
nella definizione del trigger o dell'associazione:
Proprietà | Modello di variabile di ambiente | Descrizione |
---|---|---|
Credenziali token | <CONNECTION_NAME_PREFIX>__credential |
Definisce come ottenere un token per la connessione. Questa impostazione deve essere impostata su managedidentity se la funzione di Azure distribuita intende usare l'autenticazione dell'identità gestita. Questo valore è valido solo quando un'identità gestita è disponibile nell'ambiente di hosting. |
ID client | <CONNECTION_NAME_PREFIX>__clientId |
Quando credential è impostato su managedidentity , questa proprietà può essere impostata per specificare l'identità assegnata dall'utente da usare per ottenere un token. La proprietà accetta un ID client corrispondente a un'identità assegnata dall'utente assegnata all'applicazione. Non è valido specificare sia un ID risorsa che un ID client. Se non specificata, viene usata l'identità assegnata dal sistema. Questa proprietà viene usata in modo diverso in scenari di sviluppo locale, quando non è consigliabile impostare credential . |
ID risorsa | <CONNECTION_NAME_PREFIX>__managedIdentityResourceId |
Quando credential è impostato su managedidentity , questa proprietà può essere impostata per specificare l'identificatore della risorsa da usare quando si ottiene un token. La proprietà accetta un identificatore di risorsa corrispondente all'ID risorsa dell'identità gestita definita dall'utente. Non è valido specificare sia un ID risorsa che un ID client. Se non viene specificato nessuno dei due valori, viene usata l'identità assegnata dal sistema. Questa proprietà viene usata in modo diverso in scenari di sviluppo locale, quando non è consigliabile impostare credential . |
Altre opzioni possono essere supportate per un determinato tipo di connessione. Vedere la documentazione relativa al componente che effettua la connessione.
Variabili di ambiente di Azure SDK
Attenzione
L'uso delle variabili di ambiente di EnvironmentCredential
Azure SDK non è consigliato a causa dell'impatto potenzialmente involontario su altre connessioni. Non sono inoltre completamente supportati quando vengono distribuiti in Funzioni di Azure.
Le variabili di ambiente associate a Azure SDK EnvironmentCredential
possono anche essere impostate, ma non vengono elaborate dal servizio Funzioni per il ridimensionamento nei piani a consumo. Queste variabili di ambiente non sono specifiche di una connessione e verranno applicate come impostazione predefinita, a meno che una proprietà corrispondente non sia impostata per una determinata connessione. Ad esempio, se AZURE_CLIENT_ID
è impostato, verrà usato come se <CONNECTION_NAME_PREFIX>__clientId
fosse stato configurato. L'impostazione <CONNECTION_NAME_PREFIX>__clientId
esplicita sostituisce questa impostazione predefinita.
Sviluppo locale con connessioni basate su identità
Nota
Lo sviluppo locale con connessioni basate su identità richiede la versione 4.0.3904
di Azure Functions Core Toolso versione successiva.
Quando si esegue il progetto di funzione in locale, la configurazione precedente indica al runtime di usare l'identità dello sviluppatore locale. La connessione tenta di ottenere un token dalle posizioni seguenti, in ordine:
- Una cache locale condivisa tra le applicazioni Microsoft
- Contesto utente corrente in Visual Studio
- Contesto utente corrente in Visual Studio Code
- Contesto utente corrente nell'interfaccia della riga di comando di Azure
Se nessuna di queste opzioni ha esito positivo, si verifica un errore.
L'identità potrebbe avere già alcune assegnazioni di ruolo per le risorse di Azure usate per lo sviluppo, ma questi ruoli potrebbero non fornire l'accesso ai dati necessario. I ruoli di gestione come Proprietario non sono sufficienti. Verificare le autorizzazioni necessarie per le connessioni per ogni componente e assicurarsi di averlo assegnato a se stessi.
In alcuni casi, è possibile specificare l'uso di un'identità diversa. È possibile aggiungere proprietà di configurazione per la connessione che puntano all'identità alternativa in base a un ID client e a un segreto client per un'entità servizio Microsoft Entra. Questa opzione di configurazione non è supportata quando è ospitata nel servizio Funzioni di Azure. Per usare un ID e un segreto nel computer locale, definire la connessione con le proprietà aggiuntive seguenti:
Proprietà | Modello di variabile di ambiente | Descrizione |
---|---|---|
ID tenant | <CONNECTION_NAME_PREFIX>__tenantId |
ID tenant di Microsoft Entra (directory). |
ID client | <CONNECTION_NAME_PREFIX>__clientId |
L'ID client (applicazione) di una registrazione dell'app nel tenant. |
Segreto client | <CONNECTION_NAME_PREFIX>__clientSecret |
Segreto client generato per la registrazione dell'app. |
Di seguito è riportato un esempio di proprietà local.settings.json
necessarie per la connessione basata su identità ai BLOB di Azure:
{
"IsEncrypted": false,
"Values": {
"<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
"<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
"<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
"<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
"<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
}
}
Connessione all'archiviazione host con un'identità
L'host di Funzioni di Azure usa la connessione di archiviazione impostata in AzureWebJobsStorage
per abilitare comportamenti di base, ad esempio coordinare l'esecuzione singleton dei trigger timer e l'archiviazione predefinita delle chiavi dell'app. Questa connessione può essere configurata anche per l'uso di un'identità.
Attenzione
Altri componenti in Funzioni si basano su AzureWebJobsStorage
per i comportamenti predefiniti. Non è consigliabile spostarlo in una connessione basata su identità se si usano versioni precedenti di estensioni che non supportano questo tipo di connessione, inclusi trigger e associazioni per BLOB di Azure, Hub eventi e Durable Functions. Analogamente, AzureWebJobsStorage
viene usato per gli artefatti di distribuzione quando si usa la compilazione lato server a consumo per Linux e, se abilitato, sarà necessario eseguire la distribuzione tramite un pacchetto di distribuzione esterno.
Inoltre, l'app per le funzioni potrebbe riutilizzare AzureWebJobsStorage
per altre connessioni di archiviazione nei trigger, nelle associazioni e/o nel codice della funzione. Assicurarsi che tutti gli usi di AzureWebJobsStorage
siano in grado di sfruttare il formato di connessione basato sull'identità prima di modificare questa connessione da una stringa.
Per usare una connessione basata su identità per AzureWebJobsStorage
, configurare le impostazioni dell'app seguenti:
Impostazione | Descrizione | Valore di esempio |
---|---|---|
AzureWebJobsStorage__blobServiceUri |
URI del piano dati del servizio BLOB dell'account di archiviazione, usando lo schema HTTPS. | https://<storage_account_name>.blob.core.windows.net |
AzureWebJobsStorage__queueServiceUri |
URI del piano dati del servizio di accodamento dell'account di archiviazione, usando lo schema HTTPS. | https://<storage_account_name>.queue.core.windows.net |
AzureWebJobsStorage__tableServiceUri |
URI del piano dati di un servizio tabelle dell'account di archiviazione, usando lo schema HTTPS. | https://<storage_account_name>.table.core.windows.net |
Anche le proprietà comuni per le connessioni basate su identità possono essere impostate.
Se si configura AzureWebJobsStorage
usando un account di archiviazione che usa il suffisso DNS predefinito e il nome del servizio per Azure globale, seguendo il formato https://<accountName>.[blob|queue|file|table].core.windows.net
, è invece possibile impostare AzureWebJobsStorage__accountName
sul nome dell'account di archiviazione. Gli endpoint per ogni servizio di archiviazione vengono dedotti per questo account. Questo non funziona quando l'account di archiviazione si trova in un cloud sovrano o ha un DNS personalizzato.
Impostazione | Descrizione | Valore di esempio |
---|---|---|
AzureWebJobsStorage__accountName |
Il nome dell'account di un account di archiviazione, valido solo se l'account non si trova in un cloud sovrano e non ha un DNS personalizzato. Questa sintassi è univoca per AzureWebJobsStorage e non può essere usata per altre connessioni basate su identità. |
<storage_account_name> |
È necessario creare un'assegnazione di ruolo che fornisca l'accesso all'account di archiviazione per AzureWebJobsStorage in fase di esecuzione. I ruoli di gestione come Proprietario non sono sufficienti. Il ruolo Proprietario dei dati dei BLOB di archiviazione copre le esigenze di base dell'archiviazione host di Funzioni: il runtime richiede sia l'accesso in lettura che in scrittura ai BLOB e la possibilità di creare contenitori. Diverse estensioni usano questa connessione come percorso predefinito per BLOB, code e tabelle e questi usi possono aggiungere requisiti come indicato nella tabella seguente. Potrebbero essere necessarie autorizzazioni aggiuntive se si usa "AzureWebJobsStorage" per qualsiasi altro scopo.
Estensione | Ruoli necessari | Spiegazione |
---|---|---|
nessuna estensione (solo host) | Proprietario dei dati del BLOB di archiviazione | Usato per il coordinamento generale, archivio chiavi predefinito |
BLOB di Azure (solo trigger) | Tutti i valori con: Collaboratore account di archiviazione, Proprietario dei dati del BLOB di archiviazione, Collaboratore ai dati della coda di archiviazione |
Il trigger BLOB usa internamente code di Azure e scrive ricevute BLOB. Per queste usa AzureWebJobsStorage, indipendentemente dalla connessione configurata per il trigger. |
Hub eventi di Azure (solo trigger) | (nessuna modifica rispetto al requisito predefinito) Proprietario dei dati del BLOB di archiviazione |
I checkpoint vengono salvati in modo permanente nei BLOB usando la connessione AzureWebJobsStorage. |
Trigger timer | (nessuna modifica rispetto al requisito predefinito) Proprietario dei dati del BLOB di archiviazione |
Per garantire un'esecuzione per evento, i blocchi vengono acquisiti con i BLOB usando la connessione AzureWebJobsStorage. |
Funzioni durevoli | Tutti i valori con: Collaboratore ai dati del BLOB di archiviazione, Collaboratore ai dati della coda di archiviazione, Collaboratore ai dati della tabella di archiviazione |
Durable Functions usa BLOB, code e tabelle per coordinare le funzioni di attività e mantenere lo stato di orchestrazione. Usa la connessione AzureWebJobsStorage per tutti questi elementi per impostazione predefinita, ma è possibile specificare una connessione diversa nella configurazione dell'estensione Durable Functions. |
Segnalazione di problemi
Articolo | Descrizione | Collega |
---|---|---|
esecuzione | Host di script, trigger e associazioni, supporto del linguaggio | Registrare un problema |
Modelli | Problemi di codice nel modello di creazione | Registrare un problema |
Portale | Problema con l'esperienza utente o l'interfaccia utente | Registrare un problema |
Repository open source
Il codice per Funzioni di Azure è open source ed è possibile trovare i componenti chiave in questi repository GitHub:
Passaggi successivi
Per ulteriori informazioni, vedi le seguenti risorse:
- Scenari di Funzioni di Azure
- Scrivere codici per Funzioni di Azure e testarle in locale
- Best Practices for Azure Functions (Procedure consigliate per Funzioni di Azure)