Guida per sviluppatori di Azure Functions

In Azure Functions tutte le funzioni condividono alcuni concetti e componenti tecnici 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 l'utente abbia già letto Azure Functions panoramica.

Progetto di codice

Al centro di Azure Functions è un progetto di codice specifico del linguaggio che implementa una o più unità di esecuzione del codice denominate functions. Le funzioni sono semplicemente metodi eseguiti nel cloud Azure in base agli eventi, in risposta alle richieste HTTP o in base a una pianificazione. Si pensi al progetto di codice Azure Functions come 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.

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 Azure Functions trigger e concetti relativi alle associazioni.

Azure Functions 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 Azure Functions 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 Azure Functions nel linguaggio preferito:

• Visual Studio Code

• Azure Functions Core Tools (prompt dei comandi)

Questi strumenti si integrano con Azure Functions Core Tools in modo da poter eseguire ed eseguire il debug nel computer locale usando il runtime di Funzioni. Per altre informazioni, vedere Code e testare Azure Functions in locale.

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 fornisce 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 della risorsa Azure, un'app per le funzioni equivale a una risorsa del sito (Microsoft.Web/sites) in Azure App Service, equivalente a un'app Web.

Un'app per le funzioni è costituita da una o più singole funzioni 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:

• Uso di Visual Studio Code

• A livello di codice usando Azure CLI, Azure PowerShell, ARM templates o Bicep file

• Nel portale 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 Deployment technologies in Azure Functions.

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.

Collegamenti

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 di Funzioni possa gestire automaticamente l'accesso ai dati. Per altre informazioni, vedere Azure Functions trigger e concetti relativi alle associazioni.

Se si verificano problemi con gli errori provenienti dalle associazioni, vedere la documentazione Azure Functions Codici di errore di binding.

Client SDK

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.

Connessioni

Come procedura consigliata per la sicurezza, Azure Functions sfrutta le funzionalità delle impostazioni dell'applicazione di Azure App Service 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 variabile di ambiente namevalue coppie. Per i trigger e le associazioni che richiedono una proprietà di connessione, impostare il nome dell'impostazione dell'applicazione anziché il connection string effettivo. Non è possibile configurare un'associazione direttamente con un connection string o una chiave.

Si consideri, ad esempio, una definizione di trigger con una proprietà connection. Anziché la connection string, impostare connection sul nome di una variabile di ambiente che contiene il connection string. 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 le variabili di ambiente. Queste variabili vengono definite in impostazioni di applicazione durante l'esecuzione nel Azure e nel file delle impostazioni locali durante lo sviluppo in locale.

Valori di connessione

Quando il nome della connessione viene risolto in un singolo valore esatto, il runtime identifica il valore come connection string, che in genere include un segreto. I dettagli di un connection string 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 considerate come una raccolta usando un prefisso condiviso che termina con caratteri di sottolineatura doppia __. È quindi possibile fare riferimento al gruppo impostando il nome della connessione su questo prefisso.

Ad esempio, la proprietà connection per una definizione di trigger BLOB 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.

Configurare una connessione basata su identità

Alcune connessioni in Azure Functions 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, un connection string potrebbe essere ancora necessario in Funzioni anche se il servizio a cui ci si connette supporta 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à.

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à:

Se ospitata nel servizio Azure Functions, le connessioni basate su identità usano un'identità managed identity. 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à in uso deve disporre delle autorizzazioni per eseguire le azioni desiderate. Per la maggior parte dei servizi di Azure, è necessario assegnare un ruolo in Azure controllo degli accessi in base al ruolo, usando ruoli predefiniti o personalizzati che forniscono tali autorizzazioni.

Scegliere una di queste schede per ottenere informazioni sulle autorizzazioni per ogni componente:

Proprietà comuni per le connessioni basate su identità

Una connessione basata su identità per un servizio Azure accetta le proprietà comuni seguenti, in cui <CONNECTION_NAME_PREFIX> è il valore della proprietà connection nella definizione del trigger o dell'associazione:

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

Variabili di ambiente Azure SDK

È anche possibile impostare le variabili di ambiente associate al EnvironmentCredential del Azure SDK, 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à

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 nel Azure CLI

Se nessuna di queste opzioni ha esito positivo, si verifica un errore.

L'identità potrebbe avere già alcune assegnazioni di ruolo rispetto alle risorse 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 Azure Functions. Per usare un ID e un segreto nel computer locale, definire la connessione con le proprietà aggiuntive seguenti:

Ecco un esempio di proprietà local.settings.json necessarie per la connessione basata su identità ai BLOB 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 Azure Functions 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 delle chiavi dell'app predefinita. Questa connessione può essere configurata anche per l'uso di un'identità.

Per usare una connessione basata su identità per AzureWebJobsStorage, configurare le impostazioni dell'app seguenti:

Anche le proprietà comuni per le connessioni basate su identità possono essere impostate.

Se si configura usando un account di archiviazione che usa il suffisso DNS predefinito e il nome del servizio per l'Azure globale, seguendo il formato /> 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.

È necessario creare un'assegnazione di ruolo che fornisce 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 altre autorizzazioni anche se si usa "AzureWebJobsStorage" per altri scopi.

¹ Per alcuni tipi di problemi, Azure Functions può generare un evento di diagnostica che possa facilitare la risoluzione dei problemi, anche quando il problema impedisce l'avvio dell'app per le funzioni. Se non è assegnato collaboratore ai dati della tabella di archiviazione, potrebbero essere visualizzati avvisi nei log sull'impossibilità di scrivere questi eventi.

Connessione a una risorsa in un altro tenant

Se la funzione deve connettersi a una risorsa in un tenant di Microsoft Entra diverso, la connessione deve usare una credenziale di identità federated identity. Ciò richiede un'identità gestita assegnata dall'utente e una registrazione dell'app Entra ID multi-tenant. Non è possibile usare un'identità gestita assegnata dal sistema per le connessioni tra tenant.

Per configurare una connessione basata su identità tra tenant, è prima necessario configurare l'infrastruttura seguendo questa procedura:

1. Nel tenant in cui viene distribuita la tua app per le funzioni, crea una nuova identità gestita assegnata all'utente.
2. Assegnare tale identità all'app per le funzioni.
3. Nello stesso tenant creare una registrazione dell'app Entra multi-tenant che rappresenta la risorsa tra tenant a cui si vuole accedere.
4. Aggiungere l'identità gestita come credenziale di identità federata per la registrazione dell'app.
5. Nel tenant in cui viene distribuita la risorsa creare un'applicazione aziendale per la registrazione dell'app.
6. Assegnare le autorizzazioni per l'applicazione aziendale per accedere alla risorsa.

Una connessione basata su identità tra tenant utilizza le seguenti proprietà, dove <CONNECTION_NAME_PREFIX> è il valore della tua proprietà connection nella definizione del trigger o dell'associazione.

¹ Quando credential è impostato su managedidentityasfederatedidentity, la connessione deve specificare esattamente uno di managedIdentityClientId, managedIdentityObjectIdo managedIdentityResourceId.

Questo è anche documentato dal Azure SDK in un formato JSON.

Segnalazione di problemi

Repository open source

Il codice per Azure Functions è open source ed è possibile trovare i componenti chiave in questi repository GitHub:

• Azure Functions

• Azure Functions host

• modelli Azure Functions

• Azure WebJobs SDK

• Azure WebJobs SDK Extensions

Passaggi successivi

Per altre informazioni, vedere le seguenti risorse:

• scenari Azure Functions
• Code e testare Azure Functions in locale
• procedure Best per Azure Functions