Scrivere codici per Funzioni di Azure e testarle in locale

  • Articolo

Benché sia possibile sviluppare e testare Funzioni di Azure nel portale di Azure, molti sviluppatori preferiscono un'esperienza di sviluppo locale. Quando si usano Funzioni, l'editor di codice preferito e gli strumenti di sviluppo per creare e testare funzioni nel computer locale diventa più semplice. Le funzioni locali possono connettersi ai servizi di Azure in tempo reale ed è possibile eseguirne il debug nel computer locale usando il runtime completo di Funzioni.

Questo articolo fornisce collegamenti a ambienti di sviluppo specifici per il linguaggio preferito. Fornisce inoltre alcune indicazioni condivise per lo sviluppo locale, ad esempio l'uso del file di local.settings.json.

Ambienti di sviluppo locale

Il modo in cui si sviluppano le funzioni nel computer locale dipende dal linguaggio e dalle preferenze relative agli strumenti. Gli ambienti nella tabella seguente supportano lo sviluppo locale:

Ambiente Lingue Descrizione
Visual Studio Code C# (in-process)
C# (processo di lavoro isolato)
JavaScript
PowerShell
Python		 L'estensione di Funzioni di Azure per Visual Studio Code aggiunge il supporto di Funzioni di Azure a Visual Studio Code. Richiede gli strumenti di base. Supporta lo sviluppo in Linux, macOS e Windows quando si usa la versione 2.x di Core Tools. Per altre informazioni, vedere Creare la prima funzione con Visual Studio Code.
Prompt dei comandi o terminal C# (in-process)
C# (processo di lavoro isolato)
JavaScript
PowerShell
Python		 Funzioni di Azure Core Tools fornisce il runtime di base e i modelli per la creazione di funzioni, che consentono lo sviluppo locale. La versione 2.x supporta lo sviluppo in Linux, macOS e Windows. Tutti gli ambienti si basano su Strumenti di base per il runtime Funzioni di Azure locale.
Visual Studio C# (in-process)
C# (processo di lavoro isolato)		 Gli strumenti di Funzioni di Azure sono inclusi nel carico di lavoro Sviluppo di Azure di Visual Studio, a partire da Visual Studio 2019. Consente di compilare le funzioni in una libreria di classi e di pubblicare il file con estensione dll in Azure. Include gli strumenti di base per il test locale. Per altre informazioni, vedere Sviluppare Funzioni di Azure con Visual Studio.
Maven (varie) Java L'archetipo Maven supporta Core Tools per abilitare lo sviluppo di funzioni Java. La versione 2.x supporta lo sviluppo in Linux, macOS e Windows. Per altre informazioni, vedere Creare la prima funzione con Java e Maven. Supporta anche lo sviluppo con Eclipse e IntelliJ IDEA.

Nota

A causa delle limitazioni alla modifica del codice della funzione nel portale di Azure, è consigliabile sviluppare le funzioni in locale e pubblicare il progetto di codice in un'app per le funzioni in Azure. Per altre informazioni, vedere Limitazioni per lo sviluppo nel portale di Azure

Ognuno di questi ambienti di sviluppo locale consente di creare progetti di app per le funzioni e di usare modelli di funzione predefiniti per creare nuove funzioni. Ognuno di essi usa gli strumenti di base per consentire di testare ed eseguire il debug delle funzioni con il runtime reale di Funzioni di Azure nel proprio computer esattamente come qualsiasi altra app. È anche possibile pubblicare il progetto dell'app per le funzioni da uno di questi ambienti in Azure.

File di progetto locali

Una directory del progetto di Funzioni contiene i file seguenti nella cartella radice del progetto, indipendentemente dal linguaggio:

File name Descrizione
host.json Per altre informazioni, vedere Informazioni di riferimento su host.json.
local.settings.json Impostazioni usate da Core Tools durante l'esecuzione in locale, incluse le impostazioni dell'app. Per altre informazioni, vedere file di impostazioni locali.
gitignore. Impedisce la pubblicazione accidentale del file local.settings.json in un repository Git. Per altre informazioni, vedere file di impostazioni locali.
.vscode\extensions.json File di impostazioni usato quando si apre la cartella del progetto in Visual Studio Code.

Gli altri file nel progetto dipendono dal linguaggio e dalle funzioni specifiche. Per altre informazioni, vedere la guida per sviluppatori per il linguaggio.

File di impostazioni locali

Il file local.settings.json archivia le impostazioni e le impostazioni dell'app usate dagli strumenti di sviluppo locali. Le impostazioni nel file local.settings.json vengono usate solo quando si esegue il progetto in locale. Quando si pubblica il progetto in Azure, assicurarsi di aggiungere anche le impostazioni necessarie alle impostazioni dell'app per l'app per le funzioni.

Importante

Poiché il local.settings.json può contenere segreti, ad esempio le stringhe di connessione, non è mai consigliabile archiviarlo in un repository remoto. Gli strumenti che supportano Funzioni consentono di sincronizzare le impostazioni nel file local.settings.json con le impostazioni dell'app nell'app per le funzioni in cui viene distribuito il progetto.

La struttura del file di impostazioni locali è la seguente:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "<language worker>",
    "AzureWebJobsStorage": "<connection-string>",
    "MyBindingConnection": "<binding-connection-string>",
    "AzureWebJobs.HttpExample.Disabled": "true"
  },
  "Host": {
    "LocalHttpPort": 7071,
    "CORS": "*",
    "CORSCredentials": false
  },
  "ConnectionStrings": {
    "SQLConnectionString": "<sqlclient-connection-string>"
  }
}

Queste impostazioni sono supportate quando si eseguono progetti in locale:

Impostazione Descrizione
IsEncrypted Quando questa impostazione è impostata su true, tutti i valori vengono crittografati con una chiave del computer locale. Usato con i comandi func settings. Il valore predefinito è false. Potrebbe essere necessario crittografare il file local.settings.json nel computer locale quando contiene segreti, ad esempio le stringhe di connessione al servizio. L'host decrittografa automaticamente le impostazioni durante l'esecuzione. Usare il comando func settings decrypt prima di provare a leggere le impostazioni crittografate in locale.
Values Raccolta di impostazioni dell'applicazione usate quando un progetto è in esecuzione in locale. Queste coppie chiave-valore (stringa-stringa) corrispondono alle impostazioni dell'applicazione nell'app per le funzioni in Azure, ad esempio AzureWebJobsStorage. Molti trigger e associazioni includono una proprietà che fa riferimento a un'impostazione di app per la stringa di connessione, ad esempio Connection per il trigger di archiviazione BLOB. Per queste proprietà è necessaria un'impostazione dell'applicazione definita nella matrice Values. Vedere la tabella successiva per un elenco di impostazioni usate di frequente.
I valori devono essere stringhe e non oggetti o matrici JSON. I nomi delle impostazioni non possono includere una sottolineatura doppia (__) e non devono includere due punti (:). I caratteri di sottolineatura doppia sono riservati dal runtime e i due punti sono riservati per supportare l'inserimento delle dipendenze.
Host Le impostazioni in questa sezione consentono di personalizzare il processo host di Funzioni durante l'esecuzione dei progetti in locale. Queste impostazioni sono distinte da quelle del file host.json, che vengono applicate anche quando si eseguono progetti in Azure.
LocalHttpPort Consente di impostare la porta predefinita usata durante l'esecuzione nell'host locale di Funzioni, ovvero func host start e func run. L'opzione --port della riga di comando ha la precedenza su questa impostazione. Ad esempio, quando si esegue nell'IDE di Visual Studio, è possibile modificare il numero di porta passando alla finestra "Proprietà progetto -> Debug" e specificando in modo esplicito il numero di porta in un host start --port <your-port-number> comando che può essere fornito nel campo "Argomenti applicazione".
CORS Definisce le origini consentite per la condivisione di risorse tra le origini (CORS). Le origini sono elencate in un elenco delimitato dalla virgola senza spazi. Il valore con caratteri jolly (*) è supportato, che consente le richieste provenienti da qualsiasi origine.
CORSCredentials Quando è impostata su true, consente le richieste withCredentials.
ConnectionStrings Raccolta. Non usare questa raccolta per le stringhe di connessione usate per le associazioni di funzione. Questa raccolta viene usata solo dai framework che in genere ottengono le stringhe di connessione dalla sezione ConnectionStrings di un file di configurazione, ad esempio Entity Framework. Le stringhe di connessione in questo oggetto vengono aggiunte all'ambiente con il tipo di provider di System.Data.SqlClient. Gli elementi in questa raccolta non vengono pubblicati in Azure con altre impostazioni di app. È necessario aggiungere questi valori in modo esplicito alla raccolta Connection strings delle impostazioni dell'app per le funzioni. Se si crea una connessione SqlConnection nel codice di funzione, è consigliabile archiviare il valore della stringa di connessione insieme alle altre connessioni in Impostazione applicazione nel portale.

Le impostazioni dell'applicazione seguenti possono essere incluse nella matrice Values durante l'esecuzione in locale:

Impostazione Valori Descrizione
AzureWebJobsStorage Stringa di connessione dell'account di archiviazione oppure
UseDevelopmentStorage=true		 Contiene la stringa di connessione per un account di archiviazione di Azure. Obbligatoria quando si usano trigger diversi da HTTP. Vedere le informazioni di riferimento per AzureWebJobsStorage.
Quando l'emulatore Azurite è installato in locale e si imposta su AzureWebJobsStorage UseDevelopmentStorage=true, Core Tools usa l'emulatore. Per altre informazioni, vedere Emulatore di archiviazione locale.
AzureWebJobs.<FUNCTION_NAME>.Disabled true|false Per disabilitare una funzione durante l'esecuzione in locale, aggiungere "AzureWebJobs.<FUNCTION_NAME>.Disabled": "true" alla raccolta, dove <FUNCTION_NAME> è il nome della funzione. Per altre informazioni, vedere Come disabilitare le funzioni in Funzioni di Azure.
FUNCTIONS_WORKER_RUNTIME dotnet
dotnet-isolated
node
java
powershell
python		 Indica il linguaggio di destinazione del runtime di Funzioni. Obbligatoria per la versione 2.x e successive del runtime di Funzioni. Questa impostazione viene generata per il progetto da Core Tools. Vedere le informazioni di riferimento per FUNCTIONS_WORKER_RUNTIME.
FUNCTIONS_WORKER_RUNTIME_VERSION ~7 Indica di usare PowerShell 7 durante l'esecuzione in locale. Se non è impostata, viene usato PowerShell Core 6. Questa impostazione viene usata solo durante l'esecuzione in locale. La versione del runtime di PowerShell è determinata dall'impostazione di configurazione del powerShellVersion sito, quando viene eseguita in Azure, che può essere impostata nel portale.

Sincronizzare le impostazioni

Quando si sviluppano le funzioni in locale, tutte le impostazioni locali richieste dall'app devono essere presenti anche nelle impostazioni dell'app per le funzioni in cui viene distribuito il codice. Potrebbe anche essere necessario scaricare le impostazioni correnti dall'app per le funzioni al progetto locale. Sebbene sia possibile configurare manualmente le impostazioni dell'app nella portale di Azure, gli strumenti seguenti consentono anche di sincronizzare le impostazioni dell'app con le impostazioni locali nel progetto:

Trigger e associazioni

Quando si sviluppano le funzioni in locale, è necessario prendere in considerazione i comportamenti di trigger e binding. Per i trigger HTTP, è sufficiente chiamare l'endpoint HTTP nel computer locale usando http://localhost/. Per le funzioni attivate non HTTP, sono disponibili diverse opzioni per l'esecuzione in locale:

  • Il modo più semplice per testare le associazioni durante lo sviluppo locale consiste nell'usare stringa di connessione destinati ai servizi di Azure in tempo reale. È possibile impostare come destinazione i servizi live aggiungendo le impostazioni stringa di connessione appropriate nella Values matrice nel file local.settings.json. Quando si esegue questa operazione, le esecuzioni locali durante i test influiscono su dati del servizio live. Per questo motivo, prendere in considerazione la configurazione di servizi separati da usare durante lo sviluppo e il test e quindi passare a servizi diversi durante l'ambiente di produzione.
  • Per i trigger basati sull'archiviazione, è possibile usare un emulatore di archiviazione locale.
  • È possibile eseguire manualmente funzioni di trigger non HTTP usando endpoint di amministratore speciali. Per altre informazioni, vedere Eseguire manualmente una funzione non attivata da HTTP.

Durante i test locali, è necessario eseguire l'host fornito da Core Tools (func.exe) in locale. Per altre informazioni, vedere Funzioni di Azure Core Tools.

Strumenti di test HTTP

Durante lo sviluppo, è facile chiamare uno degli endpoint di funzione da un Web browser quando supportano il metodo HTTP GET. Tuttavia, per altri metodi HTTP che supportano payload, ad esempio POST o PUT, è necessario usare uno strumento di test HTTP per creare e inviare queste richieste HTTP agli endpoint di funzione.

Attenzione

Per gli scenari in cui le richieste devono includere dati sensibili, assicurarsi di usare uno strumento che protegge i dati e riduce il rischio di esporre i dati sensibili al pubblico. I dati sensibili da proteggere possono includere: credenziali, segreti, token di accesso, chiavi API, dati di georilevazione, anche informazioni personali.

È possibile proteggere i dati scegliendo uno strumento di test HTTP che funziona offline o in locale, non sincronizza i dati nel cloud e non richiede l'accesso a un account online. Alcuni strumenti possono anche proteggere i dati dall'esposizione accidentale implementando funzionalità di sicurezza specifiche.

Evitare di usare strumenti che archiviano centralmente la cronologia delle richieste HTTP (incluse le informazioni riservate), non seguono le procedure di sicurezza consigliate o non rispettano i problemi di privacy dei dati.

Prendere in considerazione l'uso di uno di questi strumenti per l'invio sicuro di richieste HTTP agli endpoint di funzione:

Emulatore di archiviazione locale

Durante lo sviluppo locale, è possibile usare l'emulatore Azurite locale durante il test delle funzioni con associazioni Archiviazione di Azure (archiviazione code, archiviazione BLOB e archiviazione tabelle), senza dover connettersi ai servizi di archiviazione remota. Azurite si integra con Visual Studio Code e Visual Studio ed è anche possibile eseguirlo dal prompt dei comandi usando npm. Per altre informazioni, vedere Usare l'emulatore Azurite per lo sviluppo locale di Archiviazione di Azure.

L'impostazione Values seguente nella raccolta del file local.settings.json indica all'host funzioni locale di usare Azurite per la connessione predefinita AzureWebJobsStorage :

"AzureWebJobsStorage": "UseDevelopmentStorage=true"

Con questo valore di impostazione, qualsiasi trigger o associazione Archiviazione di Azure che usa AzureWebJobsStorage come connessione si connette a Azurite durante l'esecuzione in locale. Tenere presenti queste considerazioni quando si usa l'emulazione dell'archiviazione durante l'esecuzione locale:

  • È necessario che Azurite sia installato e in esecuzione.
  • È necessario testare con una connessione di archiviazione effettiva ai servizi di Azure prima di eseguire la pubblicazione in Azure.
  • Quando si pubblica il progetto, non pubblicare l'impostazione AzureWebJobsStorage come UseDevelopmentStorage=true. In Azure l'impostazione AzureWebJobsStorage deve essere sempre la stringa di connessione dell'account di archiviazione usato dall'app per le funzioni. Per ulteriori informazioni, vedere AzureWebJobsStorage.

Passaggi successivi