Guida per sviluppatori di Funzioni di Azure

  • Articolo

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 usando Visual Studio, 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 di avvio rapido usando Visual Studio Code o dal prompt dei comandi.

Se si preferisce iniziare subito, è possibile completare un'esercitazione di avvio rapido usando Visual Studio Code o dal prompt dei comandi.

Se si preferisce iniziare subito, è possibile completare un'esercitazione di avvio rapido usando Visual Studio Code o dal prompt dei comandi.

Se si preferisce iniziare subito, è possibile completare un'esercitazione di avvio rapido usando Visual Studio Code o dal prompt dei comandi.

Progetto di codice

Al centro di Funzioni di Azure è 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 Funzioni di Azure come 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 di 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ò fornire input alla funzione. Le funzioni possono facoltativamente definire associazioni di input e output. Queste associazioni semplificano le connessioni ad altri servizi senza dover usare gli SDK client. Per altre informazioni, vedere Concetti relativi a trigger e associazioni in Funzioni di Azure.

Funzioni di Azure fornisce 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 Funzioni di Azure sviluppo 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:

Questi strumenti si integrano con Funzioni di Azure Core Tools in modo da poter eseguire ed eseguire 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 nella 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.

La modifica del portale è supportata solo per Python versione 1, 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) in app Azure Servizio, 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, il metodo di distribuzione e la 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:

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 gli SDK client.

Indipendentemente dal fatto che si usino le estensioni di associazione fornite da Funzioni o si usano direttamente gli SDK client, si archiviano in modo sicuro i dati di connessione e non lo si include nel codice. Per altre informazioni, vedere Connessione ions.

Bindings

Funzioni fornisce 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 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 gli errori provenienti dalle associazioni, vedere la documentazione relativa ai codici di errore di associazione Funzioni di Azure.

SDK client

Sebbene Funzioni fornisca 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 gli SDK client se le funzioni richiedono una funzionalità dell'SDK sottostante non supportata dall'estensione di associazione.

Quando si usano gli SDK client, è consigliabile usare lo stesso processo per l'archiviazione e l'accesso alle stringa 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 di app Azure Servizio per 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 di variabili namevalue di ambiente. Per i trigger e le associazioni che richiedono una proprietà di connessione, impostare il nome dell'impostazione dell'applicazione anziché il stringa di connessione effettivo. Non è possibile configurare un'associazione direttamente con un stringa di connessione o una chiave.

Si consideri, ad esempio, una definizione di trigger con una connection proprietà . Anziché il stringa di connessione, impostare connection sul nome di una variabile di ambiente che contiene il 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 di 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 un 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 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 connection proprietà 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 blobServiceUri proprietà 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 usa app Azure Configurazione o Insieme di credenziali delle chiavi per specificare le impostazioni per le connessioni con identità gestite, i nomi delle impostazioni devono usare un separatore di chiavi valido, : ad esempio o / al posto di __ per assicurarsi 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 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 sulla creazione di un'app per le funzioni con connessioni basate su identità.

Nota

Quando si esegue in un piano a consumo o Elastic Premium, l'app usa le impostazioni e WEBSITE_CONTENTSHARE durante la connessione a File di Azure nell'account di archiviazione usato dall'app per le WEBSITE_AZUREFILESCONNECTIONSTRING funzioni. File di Azure non supporta l'uso dell'identità gestita durante l'accesso alla condivisione file. Per altre informazioni, vedere File di Azure scenari di autenticazione supportati

I componenti seguenti supportano connessioni basate su identità:

origine Connessione ion Piani supportati Altre informazioni
Trigger e associazioni di BLOB di Azure Tutte le date Estensione BLOB di Azure versione 5.0.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Trigger e associazioni di Code di Azure Tutte le date Estensione Code di Azure versione 5.0.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Tabelle di Azure (quando si usa Archiviazione di Azure) Tutte le date Estensione tabelle di Azure versione 1.0.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Database SQL di Microsoft Azure Tutte le date Connessione un'app per le funzioni a SQL di Azure con associazioni di identità gestite e SQL
Hub eventi di Azure trigger e associazioni Tutte le date Hub eventi di Azure'estensione versione 5.0.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
bus di servizio di Azure trigger e associazioni Tutte le date bus di servizio di Azure'estensione versione 5.0.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Griglia di eventi di Azure binding di output Tutte le date Griglia di eventi di Azure'estensione 3.3.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Trigger e associazioni di Azure Cosmos DB Tutte le date Estensione Azure Cosmos DB versione 4.0.0 o successiva,
Bundle di estensione 4.0.2 o versione successiva
Trigger e associazioni di Azure SignalR Tutte le date Estensione Azure SignalR versione 1.7.0 o successiva
Bundle di estensione 3.6.1 o versione successiva
Provider di archiviazione Durable Functions (Archiviazione di Azure) Tutte le date Estensione Durable Functions versione 2.7.0 o successiva,
Bundle di estensione 3.3.0 o versione successiva
Archiviazione richiesta dall'host ("AzureWebJobs Archiviazione") Tutte le date Connessione per ospitare l'archiviazione con un'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:

È necessario creare un'assegnazione di ruolo che fornisce l'accesso al contenitore BLOB in fase di esecuzione. I ruoli di gestione come proprietario non sono sufficienti. La tabella seguente illustra i ruoli predefiniti consigliati quando si usa l'estensione blob Archiviazione nel normale funzionamento. L'applicazione potrebbe richiedere ulteriori autorizzazioni in base al codice scritto.

Tipo di associazione Ruoli predefiniti di esempio
Trigger Archiviazione proprietario dei dati BLOBe Archiviazione Collaboratoredati coda 1

È inoltre necessario concedere autorizzazioni aggiuntive alla connessione AzureWebJobs Archiviazione.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 AzureWebJobs Archiviazione 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 Archiviazione Proprietario dati BLOB, Collaboratore dati coda Archiviazione e Collaboratore account Archiviazione. Per altre informazioni, vedere Connessione per ospitare l'archiviazione 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, dove <CONNECTION_NAME_PREFIX> è il valore della proprietà nella definizione del trigger o dell'associazione connection :

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.
Client ID <CONNECTION_NAME_PREFIX>__clientId Quando credential è impostato su , questa proprietà può essere impostata managedidentityper specificare l'identità assegnata dall'utente da usare quando si ottiene 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 specificato, viene usata l'identità assegnata dal sistema. Questa proprietà viene usata in modo diverso negli scenari di sviluppo locale, quando credential non deve essere impostata.
ID risorsa <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Quando credential è impostato su , questa proprietà può essere impostata managedidentityper specificare l'identificatore della risorsa da usare per ottenere 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 vengono specificati nessuno dei due valori, viene usata l'identità assegnata dal sistema. Questa proprietà viene usata in modo diverso negli scenari di sviluppo locale, quando credential non deve essere impostata.

Altre opzioni possono essere supportate per un determinato tipo di connessione. Vedere la documentazione relativa al componente che effettua la connessione.

Sviluppo locale con connessioni basate su identità

Nota

Lo sviluppo locale con connessioni basate su identità richiede la versione 4.0.3904 di Funzioni di Azure Core Tools o una 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).
Client ID <CONNECTION_NAME_PREFIX>__clientId ID client (applicazione) di una registrazione dell'app nel tenant.
Segreto client <CONNECTION_NAME_PREFIX>__clientSecret Segreto client generato per la registrazione dell'app.

Ecco un esempio di proprietà necessarie per la connessione basata su identità ai BLOB di local.settings.json 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 per ospitare l'archiviazione con un'identità

L'host Funzioni di Azure usa la connessione di archiviazione impostata in AzureWebJobsStorage per abilitare comportamenti principali, ad esempio coordinare l'esecuzione singleton dei trigger timer e l'archiviazione delle chiavi dell'app predefinita. 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 Funzioni permanenti. Analogamente, AzureWebJobsStorage viene usato per gli artefatti di distribuzione quando si usa la compilazione lato server in Consumo Linux e, se si abilita, sarà necessario eseguire la distribuzione tramite un pacchetto di distribuzione esterno.

Inoltre, l'app per le funzioni potrebbe essere riutilizzata AzureWebJobsStorage per altre connessioni di archiviazione nei trigger, nelle associazioni e/o nel codice della funzione. Assicurarsi che tutti gli usi di siano in grado di usare il formato di connessione basato sull'identità prima di AzureWebJobsStorage modificare questa connessione da un stringa di connessione.

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 sta configurando AzureWebJobsStorage usando un account di archiviazione che usa il suffisso DNS predefinito e il nome del servizio per Azure globale, seguendo il https://<accountName>.[blob|queue|file|table].core.windows.net formato, è possibile impostare AzureWebJobsStorage__accountName invece 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 fornisce l'accesso all'account di archiviazione per "AzureWebJobs Archiviazione" in fase di esecuzione. I ruoli di gestione come proprietario non sono sufficienti. Il ruolo proprietario dei dati BLOB 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 "AzureWebJobs Archiviazione" per altri scopi.

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:
Archiviazione Collaboratore account,
Archiviazione proprietario dei dati BLOB,
Collaboratore ai dati della coda di archiviazione		 Il trigger BLOB usa internamente code di Azure e scrive le ricevute del BLOB. Usa AzureWebJobs Archiviazione per questi, 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 AzureWebJobs Archiviazione.
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 AzureWebJobs Archiviazione.
Funzioni permanenti Tutti i valori con:
Archiviazione Collaboratore ai dati BLOB,
Archiviazione Collaboratore ai dati della coda,
Collaboratore dati tabella Archiviazione		 Durable Functions usa BLOB, code e tabelle per coordinare le funzioni di attività e mantenere lo stato di orchestrazione. Usa la connessione AzureWebJobs Archiviazione per tutti questi 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: