Sviluppare Funzioni di Azure in locale con Core Tools

Articolo
08/08/2024

Azure Functions Core Tools consente di sviluppare e testare le funzioni nel computer locale. Quando si è pronti, è anche possibile usare Core Tools per distribuire il progetto di codice in Azure e usare le impostazioni dell'applicazione.

Si sta visualizzando la versione C# di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione Java di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione JavaScript di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione di PowerShell di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione Python di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Si sta visualizzando la versione TypeScript di questo articolo. Assicurarsi di selezionare il linguaggio di programmazione di Funzioni preferito nella parte superiore dell'articolo.

Per iniziare subito, completare l'articolo di avvio rapido sugli strumenti di base.

Installare gli strumenti di base per Funzioni di Azure

Il modo consigliato per installare Core Tools dipende dal sistema operativo del computer di sviluppo locale.

La procedura seguente usa un programma di installazione di Windows per installare Core Tools v4.x. Per altre informazioni su altri programmi di installazione basati su pacchetti, vedere il file leggimi Core Tools.

Scaricare ed eseguire il programma di installazione di Core Tools, in base alla versione di Windows:

v4.x - Windows a 64 bit (scelta consigliata. Il debug di Visual Studio Code richiede 64 bit).
v4.x - Windows 32-bit

Se in precedenza è stato usato Windows Installer (MSI) per installare Core Tools in Windows, è necessario disinstallare la versione precedente da Installazione applicazioni prima di installare la versione più recente.

I passaggi seguenti usano Homebrew per installare gli strumenti di base su macOS.

Installare Homebrew, se non è già installato.

Installare il pacchetto degli strumenti di base:

brew tap azure/functions
brew install azure-functions-core-tools@4
# if upgrading on a machine that has 2.x or 3.x installed:
brew link --overwrite azure-functions-core-tools@4

La procedura seguente usa APT per installare gli strumenti di base nella distribuzione Ubuntu/Debian Linux. Per altre distribuzioni Linux, vedere il file leggimi degli strumenti di base.

Installare la chiave GPG del repository di pacchetti Microsoft per convalidare l'integrità del pacchetto:

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg

Configurare l'elenco di origine APT prima di eseguire un aggiornamento APT.

Ubuntu

sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-$(lsb_release -cs 2>/dev/null)-prod $(lsb_release -cs 2>/dev/null) main" > /etc/apt/sources.list.d/dotnetdev.list'

Debian

sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/debian/$(lsb_release -rs 2>/dev/null | cut -d'.' -f 1)/prod $(lsb_release -cs 2>/dev/null) main" > /etc/apt/sources.list.d/dotnetdev.list'

Verificare il file /etc/apt/sources.list.d/dotnetdev.list per una delle stringhe di versione Linux appropriate nella tabella seguente:

Distribuzione di Linux	Versione
Debian 12	`bookworm`
Debian 11	`bullseye`
Debian 10	`buster`
Debian 9	`stretch`
Ubuntu 22.04	`jammy`
Ubuntu 20.04	`focal`
Ubuntu 19.04	`disco`
Ubuntu 18.10	`cosmic`
Ubuntu 18.04	`bionic`
Ubuntu 17.04	`zesty`
Ubuntu 16.04/Linux Mint 18	`xenial`

Avviare l'aggiornamento dell'origine APT:
```
sudo apt-get update
```

Installare il pacchetto degli strumenti di base:

sudo apt-get install azure-functions-core-tools-4

Per informazioni sui problemi relativi alla versione, vedere versioni di Core Tools.

Creare il progetto locale

Importante

Per Python, è necessario eseguire i comandi Core Tools in un ambiente virtuale. Per altre informazioni, vedere Avvio rapido: Creare una funzione Python in Azure dalla riga di comando.

Nella finestra del terminale o da un prompt dei comandi eseguire il comando seguente per creare un progetto nella cartella MyProjFolder:

Processo isolato
In-process

func init MyProjFolder --worker-runtime dotnet-isolated

Per impostazione predefinita, questo comando crea un progetto che viene eseguito in-process con l'host funzioni nella versione corrente LTS (Long-Term Support) di .NET Core. È possibile usare l'opzione --target-framework per specificare una versione supportata specifica di .NET, incluso .NET Framework. Vedere le informazioni di riferimento per func init.

func init MyProjFolder --worker-runtime dotnet

Questo comando crea un progetto eseguito nella versione corrente del supporto a lungo termine (LTS) corrente di .NET Core. Per altre versioni di .NET, creare un'app eseguita in un processo di lavoro isolato dall'host funzioni.

Per un confronto tra i due modelli di processo .NET, vedere l'articolo confronto tra modalità processo.

Java usa un archetipo Maven per creare il progetto locale, insieme alla prima funzione attivata tramite HTTP. Invece di usare func init e func new, è consigliabile seguire la procedura descritta nella guida introduttiva alla riga di comando.

func init MyProjFolder --worker-runtime javascript --model V4

func init MyProjFolder --worker-runtime javascript --model V3

Questo comando crea un progetto JavaScript che usa la versione del modello di programmazione desiderata.

func init MyProjFolder --worker-runtime typescript --model V4

func init MyProjFolder --worker-runtime typescript --model V3

Questo comando crea un progetto TypeScript che usa la versione del modello di programmazione desiderata.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

func init MyProjFolder --worker-runtime python

Questo comando crea un progetto Python che usa la versione del modello di programmazione desiderata.

Quando si esegue func init senza l'opzione --worker-runtime, viene richiesto di scegliere il linguaggio del progetto. Per altre informazioni sulle opzioni disponibili per il comando func init, vedere le informazioni di riferimento su func init.

Creare una funzione

Per aggiungere una funzione al progetto, eseguire il comando func new usando l'opzione --template per selezionare il modello di trigger. L'esempio seguente crea un trigger HTTP denominato MyHttpTrigger:

func new --template "Http Trigger" --name MyHttpTrigger

Questo esempio crea un trigger di archiviazione code denominato MyQueueTrigger:

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

Quando si aggiungono funzioni, si applicano le considerazioni seguenti:

Quando si esegue func new senza l'opzione --template, viene richiesto di scegliere un modello.
Usare il comando func templates list per visualizzare l'elenco completo dei modelli disponibili per la lingua.
Quando si aggiunge un trigger che si connette a un servizio, è necessario aggiungere anche un'impostazione dell'applicazione che fa riferimento a una stringa di connessione o a un'identità gestita al file local.settings.json. L'uso delle impostazioni dell'app in questo modo impedisce di dover incorporare le credenziali nel codice. Per altre informazioni, vedere Usare le impostazioni dell'app in locale.

Core Tools aggiunge anche un riferimento all'estensione di associazione specifica al progetto C#.

Per altre informazioni sulle opzioni disponibili per il comando func new, vedere le informazioni di riferimento su func new.

Aggiungere un'associazione alla funzione

Funzioni fornisce un set di associazioni di input e output specifiche del servizio, che semplificano la connessione della funzione ad altri servizi di Azure senza dover usare gli SDK client specifici del servizio. Per altre informazioni, vedere Concetti relativi a trigger e associazioni in Funzioni di Azure.

Per aggiungere un'associazione di input o output a una funzione esistente, è necessario aggiornare manualmente la definizione della funzione.

L'esempio seguente illustra la definizione della funzione dopo l'aggiunta di un'associazione di output di archiviazione code a una funzione attivata tramite HTTP:

Processo isolato
In-process

Poiché una funzione attivata da HTTP restituisce anche una risposta HTTP, la funzione restituisce un oggetto MultiResponse, che rappresenta sia l'output HTTP che quello della coda.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

Questo esempio è la definizione dell'oggetto MultiResponse che include l'associazione di output:

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

Quando si applica tale esempio al proprio progetto, potrebbe essere necessario modificare HttpRequest in HttpRequestData e IActionResult in HttpResponseData, a seconda che si usi ASP.NET core integration o meno.

[FunctionName("HttpExample")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req, 
    [Queue("outqueue"),StorageAccount("AzureWebJobsStorage")] ICollector<string> msg, 
    ILogger log)

I messaggi vengono inviati alla coda al termine della funzione. Il modo in cui si definisce l'associazione di output dipende dal modello di processo. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Associazione di esempio per Node.js modello v4 non ancora disponibile.

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Il modo in cui si definisce l'associazione di output dipende dalla versione del modello di Node.js. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Il modo in cui si definisce l'associazione di output dipende dalla versione del modello Python. Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Associazione di esempio per Node.js modello v4 non ancora disponibile.

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "msg",
      "queueName": "outqueue",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Quando si aggiungono associazioni a una funzione, si applicano le considerazioni seguenti:

Per i linguaggi che definiscono le funzioni usando il file di configurazione function.json, Visual Studio Code semplifica il processo di aggiunta di associazioni a una definizione di funzione esistente. Per altre informazioni, vedere Connettere le funzioni ai servizi di Azure usando le associazioni.

Quando si aggiungono associazioni che si connettono a un servizio, è necessario aggiungere anche un'impostazione dell'applicazione che fa riferimento a una stringa di connessione o a un'identità gestita al file local.settings.json. Per altre informazioni, vedere Usare le impostazioni dell'app in locale.

Quando si aggiunge un'associazione supportata, l'estensione deve essere già installata quando l'app usa il bundle di estensione. Per altre informazioni, vedere Bundle di estensioni.

Quando si aggiunge un'associazione che richiede una nuova estensione di associazione, è necessario aggiungere anche un riferimento a tale estensione di associazione specifica nel progetto C#.

Per altre informazioni, inclusi i collegamenti al codice di associazione di esempio a cui è possibile fare riferimento, vedere Aggiungere associazioni a una funzione.

Avviare il runtime di Funzioni

Prima di poter eseguire o eseguire il debug delle funzioni nel progetto, è necessario avviare l'host funzioni dalla directory radice del progetto. L'host abilita i trigger per tutte le funzioni del progetto. Usare questo comando per avviare il runtime locale:

mvn clean package 
mvn azure-functions:run

func start

npm install
npm start

Questo comando deve essere eseguito in un ambiente virtuale.

All'avvio dell'host funzioni, restituisce un elenco di funzioni nel progetto, inclusi gli URL di qualsiasi funzione attivata da HTTP, come nell'esempio seguente:

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

Quando si eseguono le funzioni in locale, tenere presenti le considerazioni seguenti:

Per impostazione predefinita, l'autorizzazione non viene applicata localmente per gli endpoint HTTP. Questo significa che tutte le richieste HTTP locali vengono gestite come authLevel = "anonymous". Per maggiori informazioni, vedere Livello di autorizzazione. È possibile usare l'opzione --enableAuth per richiedere l'autorizzazione durante l'esecuzione in locale. Per altre informazioni, vedere func start.
È possibile usare l'emulatore Local Azurite quando si eseguono funzioni che richiedono l'accesso ai servizi di archiviazione di Azure (archiviazione code, archiviazione BLOB e archiviazione tabelle) senza dover connettersi a questi servizi in Azure. Quando si usa l'emulazione locale, assicurarsi di avviare Azurite prima di avviare l'host locale (func.exe). Per altre informazioni, vedere Emulazione di archiviazione locale.

È possibile usare l'emulazione locale di Azurite per soddisfare i requisiti di archiviazione del ruolo di lavoro Python v2.

È possibile attivare funzioni non HTTP in locale senza connettersi a un servizio attivo. Per altre informazioni, vedere Eseguire una funzione locale.
Quando si includono le informazioni di connessione di Application Insights nel file local.settings.json, i dati di log locali sono scritti nell'istanza specifica di Application Insights. Per mantenere i dati di telemetria locali separati dai dati di produzione, è consigliabile usare un'istanza separata di Application Insights per lo sviluppo e il test.

Quando si usa la versione 1.x di Core Tools, usare invece il comando func host start per avviare il runtime locale.

Eseguire una funzione locale

Con l'host di Funzioni locali (func.exe) in esecuzione, è ora possibile attivare singole funzioni per eseguire ed eseguire il debug del codice della funzione. Il modo in cui si esegue una singola funzione dipende dal tipo di trigger.

Nota

Gli esempi in questo argomento usano lo strumento cURL per inviare richieste HTTP dal terminale o da un prompt dei comandi. È possibile usare lo strumento preferito per inviare richieste HTTP al server locale. Lo strumento cURL è disponibile per impostazione predefinita nei sistemi basati su Linux e Windows 10 build 17063 e versioni successive. In Windows precedente è necessario prima scaricare e installare lo strumento cURL.

I trigger HTTP vengono avviati inviando una richiesta HTTP all'endpoint locale e alla porta come visualizzato nell'output func.exe, che ha questo formato generale:

http://localhost:<PORT>/api/<FUNCTION_NAME>

In questo modello di URL <FUNCTION_NAME> è il nome della funzione o della route e <PORT> è la porta locale su cui func.exe è in ascolto.

Ad esempio, questo comando cURL attiva la funzione di avvio rapido MyHttpTrigger da una richiesta GET con il parametro nome passato nella stringa di query:

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

Questo esempio è la stessa funzione chiamata da una richiesta POST che passa il nome nel corpo della richiesta, visualizzata sia per la shell Bash che per la riga di comando di Windows:

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

Quando si chiamano endpoint HTTP in locale, si applicano le considerazioni seguenti:

È possibile effettuare richieste GET da un browser passando dati nella stringa di query. Per tutti gli altri metodi HTTP, è necessario usare uno strumento di test HTTP che consente anche di proteggere i dati. Per altre informazioni, vedere strumenti di test HTTP.
Assicurarsi di usare lo stesso nome server e la stessa porta su cui è in ascolto l'host di Funzioni. Nell'output generato all'avvio dell'host funzione viene visualizzato un endpoint simile al seguente. È possibile chiamare questo URL usando qualsiasi metodo HTTP supportato dal trigger.

Esistono due modi per eseguire trigger non HTTP in locale. Prima di tutto, è possibile connettersi ai servizi di Azure in tempo reale, ad esempio Archiviazione di Azure e bus di servizio di Azure. Questo rispecchia direttamente il comportamento della funzione durante l'esecuzione in Azure. Quando si usano i servizi live, assicurarsi di includere le stringhe di connessione denominate necessarie nel file di impostazioni locali. È possibile usare una connessione al servizio diversa durante lo sviluppo rispetto a quella eseguita nell'ambiente di produzione usando una stringa di connessione diversa nel file local.settings.json rispetto a quella usata nelle impostazioni dell'app per le funzioni in Azure.

I trigger di Griglia di eventi richiedono una configurazione aggiuntiva per l'esecuzione in locale.

È anche possibile eseguire una funzione non HTTP in locale usando REST chiamando un endpoint speciale denominato endpoint amministratore. Usare questo formato per chiamare l'endpoint admin e attivare una funzione non HTTP specifica:

http://localhost:<PORT>/admin/functions/<FUNCTION_NAME>

In questo modello di URL <FUNCTION_NAME> è il nome della funzione o della route e <PORT> è la porta locale su cui func.exe è in ascolto.

È facoltativamente possibile passare dati di test all'esecuzione nel corpo del messaggio della richiesta POST. Per superare i dati di test, è necessario specificare i dati nel corpo di un messaggio di richiesta POST, che ha questo formato JSON:

{
    "input": "<TRIGGER_INPUT>"
}

Il valore <TRIGGER_INPUT> contiene dati nel formato previsto dalla funzione. Questo esempio cURL viene visualizzato sia per la shell Bash che per la riga di comando di Windows:

curl --request POST -H "Content-Type:application/json" --data '{"input":"sample queue data"}' http://localhost:7071/admin/functions/QueueTrigger

curl --request POST -H "Content-Type:application/json" --data "{'input':'sample queue data'}" http://localhost:7071/admin/functions/QueueTrigger

Gli esempi precedenti generano una richiesta POST che passa una stringa sample queue data a una funzione denominata funzione QueueTrigger, che simula i dati in arrivo nella coda e attiva la funzione

Quando si usa l'endpoint di amministratore per i test locali, è necessario tenere presenti le considerazioni seguenti:

È possibile chiamare l'endpoint amministratore di functions (http://localhost:{port}/admin/functions/) per restituire un elenco di URL di amministratore per tutte le funzioni disponibili, attivate sia da HTTP che da non HTTP attivate.
L'autenticazione e l'autorizzazione vengono ignorate durante l'esecuzione in locale. Le stesse API esistono in Azure, ma quando si tenta di chiamare gli stessi endpoint di amministratore in Azure, è necessario fornire una chiave di accesso. Per altre informazioni, vedere Usare le chiavi di accesso.
Le chiavi di accesso sono segreti condivisi importanti. Se usate in locale, devono essere archiviate in modo sicuro all'esterno del controllo del codice sorgente. Poiché l'autenticazione e l'autorizzazione non sono richieste da Funzioni durante l'esecuzione in locale, è consigliabile evitare l'uso e l'archiviazione delle chiavi di accesso, a meno che gli scenari non lo richiedano.
La chiamata di un endpoint amministratore e il passaggio dei dati di test è simile all'uso della scheda Test nel portale di Azure.

Pubblicare in Azure

Azure Functions Core Tools supporta tre tipi di distribuzione:

Tipo di distribuzione	Comando	Descrizione
File di progetto	`func azure functionapp publish`	Distribuisce i file di progetto della funzione direttamente nell'app per le funzioni usando la distribuzione ZIP.
App contenitore di Azure	`func azurecontainerapps deploy`	Distribuisce un'app per le funzioni in contenitori in un ambiente app contenitore esistente.
Cluster Kubernetes	`func kubernetes deploy`	Distribuisce l'app per le funzioni Linux come contenitore Docker personalizzato in un cluster Kubernetes.

Per poter pubblicare in Azure da Core Tools, è necessario che sia installata l'interfaccia della riga di comando di Azure o Azure PowerShell in locale. Per impostazione predefinita, Core Tools usa questi strumenti per l'autenticazione con l'account Azure.

Se questi strumenti non sono installati, è necessario ottenere un token di accesso valido da usare durante la distribuzione. È possibile presentare un token di accesso usando l'opzione --access-token nei comandi di distribuzione.

Distribuire i file di progetto

Per pubblicare il codice locale in un'app per le funzioni in Azure, usare il comando func azure functionapp publish, come nell'esempio seguente:

func azure functionapp publish <FunctionAppName>

Questo comando pubblica i file di progetto dalla directory corrente a <FunctionAppName> come pacchetto di distribuzione .zip. Se il progetto richiede la compilazione, viene eseguito in remoto durante la distribuzione.

Java usa Maven per pubblicare il progetto locale in Azure anziché in Core Tools. Usare il comando Maven seguente per pubblicare il progetto in Azure:

mvn azure-functions:deploy

Quando si esegue questo comando, le risorse di Azure vengono create durante la distribuzione iniziale in base alle impostazioni nel file pom.xml. Per altre informazioni, vedere Distribuire il progetto di funzione in Azure.

Le considerazioni seguenti si applicano a questo tipo di distribuzione:

La pubblicazione sovrascrive i file esistenti nella distribuzione dell'app per le funzioni remote.
È necessario avere già creato un'app per le funzioni nella sottoscrizione di Azure. Core Tools distribuisce il codice del progetto in questa risorsa dell'app per le funzioni. Per informazioni su come creare un'app per le funzioni dal prompt dei comandi o dalla finestra del terminale usando l'interfaccia della riga di comando di Azure o Azure PowerShell, vedere Creare un'app per le funzioni per l'esecuzione serverless. È anche possibile creare queste risorse nel portale di Azure. Viene visualizzato un errore quando si tenta di pubblicare in un oggetto <FunctionAppName> che non esiste nella sottoscrizione.
Una cartella di progetto può contenere file e directory specifici della lingua che non devono essere pubblicati. Gli elementi esclusi sono elencati in un file .funcignore nella cartella del progetto radice.
Per impostazione predefinita, il progetto viene distribuito in modo che venga eseguito dal pacchetto di distribuzione. Per disabilitare questa modalità di distribuzione consigliata, usare l'opzione --nozip.
Una compilazione remota viene eseguita su progetti compilati. Questa operazione può essere controllata usando l'opzione --no-build.
Usare l'opzione --publish-local-settings per creare automaticamente le impostazioni dell'app nell'app per le funzioni in base ai valori nel file local.settings.json.
Per pubblicare in uno slot denominato specifico nell'app per le funzioni, usare l'opzione --slot.

Distribuire contenitori

Core Tools consente di distribuire l'app per le funzioni in contenitori sia in ambienti di App Azure Container gestite che in cluster Kubernetes gestiti.

App contenitore
Cluster Kubernetes

Usare il comando func azurecontainerapps deploy seguente per distribuire un'immagine del contenitore esistente in un ambiente app contenitore:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Quando si esegue la distribuzione in un ambiente di App Azure Container, si applicano le considerazioni seguenti:

L'ambiente e l'account di archiviazione devono già esistere. La stringa di connessione dell'account di archiviazione specificata viene usata dall'app per le funzioni distribuita.
Non è necessario creare una risorsa dell'app per le funzioni separata durante la distribuzione in App contenitore.
Le stringhe di connessione di archiviazione e altre credenziali del servizio sono segreti importanti. Assicurarsi di archiviare in modo sicuro tutti i file di script usando func azurecontainerapps deploy e di non archiviarli in sistemi di controllo del codice sorgente accessibili pubblicamente. È possibile crittografare il file local.settings.json per una maggiore sicurezza.

Per altre informazioni, vedere Hosting di App contenitore di Azure di Funzioni di Azure.

Il comando func kubernetes deploy seguente usa il Dockerfile per generare un contenitore nel registro specificato e distribuirlo nel cluster Kubernetes predefinito.

func kubernetes deploy --name <DEPLOYMENT_NAME> --registry <REGISTRY_USERNAME>

Funzioni di Azure in Kubernetes con KEDA è un'operazione open source che è possibile usare gratuitamente. Il supporto ottimale viene fornito dai collaboratori e dalla community. Per altre informazioni, vedere Distribuzione di un'app per le funzioni in Kubernetes.

Usare le impostazioni dell'app in locale

Quando si esegue in un'app per le funzioni in Azure, le impostazioni richieste dalle funzioni vengono archiviate in modo sicuro nelle impostazioni dell'app. Durante lo sviluppo locale, queste impostazioni vengono invece aggiunte alla raccolta Values nel file local.settings.json. Il file local.settings.json archivia anche le impostazioni usate dagli strumenti di sviluppo locali.

Gli elementi nella raccolta di Values nel file di local.settings.json del progetto sono destinati a eseguire il mirroring degli elementi nelle impostazioni di applicazione dell'app per le funzioni in Azure.

Quando si lavora con il file di impostazioni locali, si applicano le considerazioni seguenti:

Poiché il local.settings.json può contenere segreti, ad esempio le stringhe di connessione, non è mai consigliabile archiviarlo in un repository remoto. Core Tools consente di crittografare questo file di impostazioni locali per migliorare la sicurezza. Per maggiori informazioni, vedere File di impostazioni locali. È anche possibile crittografare il file local.settings.json per una maggiore sicurezza.
Per impostazione predefinita, le impostazioni locali non vengono migrate automaticamente quando il progetto viene pubblicato in Azure. Usare l'opzione --publish-local-settings quando si pubblicano i file di progetto per assicurarsi che queste impostazioni vengano aggiunte all'app per le funzioni in Azure. I valori nella sezione ConnectionStrings non vengono mai pubblicati. È anche possibile caricare le impostazioni dal file local.settings.json in qualsiasi momento.
È possibile scaricare e sovrascrivere le impostazioni nel file local.settings.json con le impostazioni dell'app per le funzioni in Azure. Per altre informazioni, vedere Scaricare le impostazioni dell'applicazione.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere Variabili di ambiente.

Quando non viene impostata alcuna stringa di connessione di archiviazione valida per AzureWebJobsStorage e non viene usato un emulatore di archiviazione locale, viene visualizzato un errore. È possibile usare Core Tools per scaricare una stringa di connessione specifica da uno degli account di archiviazione di Azure.

Scaricare le impostazioni dell'applicazione

Dalla radice del progetto usare il comando seguente per scaricare tutte le impostazioni dell'applicazione dall'app myfunctionapp12345 in Azure:

func azure functionapp fetch-app-settings myfunctionapp12345

Questo comando sovrascrive le impostazioni esistenti nel file local.settings.json con i valori di Azure. Quando non è già presente, i nuovi elementi vengono aggiunti alla raccolta. Per ulteriori informazioni, vedere il comando func azure functionapp fetch-app-settings.

Scaricare una stringa di connessione a risorsa di archiviazione

Core Tools consente anche di ottenere facilmente la stringa di connessione di qualsiasi account di archiviazione a cui si ha accesso. Dalla radice del progetto usare il comando seguente per scaricare la stringa di connessione da un account di archiviazione denominato mystorage12345.

func azure storage fetch-connection-string mystorage12345

Questo comando aggiunge un'impostazione denominata mystorage12345_STORAGE al file local.settings.json, che contiene la stringa di connessione per l'account mystorage12345. Per ulteriori informazioni, vedere il comando func azure storage fetch-connection-string.

Per una maggiore sicurezza durante lo sviluppo, è consigliabile crittografare il file local.settings.json.

Caricare le impostazioni locali in Azure

Quando si pubblicano i file di progetto in Azure senza usare l'opzione --publish-local-settings, le impostazioni nel file local.settings.json non vengono impostate nell'app per le funzioni. È sempre possibile eseguire di nuovo il func azure functionapp publish con l'opzione --publish-settings-only per caricare solo le impostazioni senza ripubblicare i file di progetto.

L'esempio seguente carica solo le impostazioni dalla raccolta Values nel file local.settings.json all'app per le funzioni in Azure denominata myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

Crittografare il file delle impostazioni locali

Per migliorare la sicurezza delle stringhe di connessione e altri dati importanti nelle impostazioni locali, Core Tools consente di crittografare il file di local.settings.json. Quando questo file viene crittografato, il runtime decrittografa automaticamente le impostazioni quando necessario allo stesso modo con l'impostazione dell'applicazione in Azure. È anche possibile decrittografare un file crittografato in locale per usare le impostazioni.

Usare il comando seguente per crittografare il file di impostazioni locali per il progetto:

func settings encrypt

Usare il comando seguente per decrittografare un'impostazione locale crittografata, in modo che sia possibile usarla:

func settings decrypt

Quando il file di impostazioni viene crittografato e decrittografato, viene aggiornata anche l'impostazione IsEncrypted del file.

Configurare le estensioni di associazione

i trigger e le associazioni di Funzioni vengono implementati come pacchetti di estensione .NET (NuGet). Per poter usare un'estensione di associazione specifica, tale estensione deve essere installata nel progetto.

Questa sezione non si applica alla versione 1.x del runtime di Funzioni. Nella versione 1.x le associazioni supportate sono state incluse nell'estensione del prodotto principale.

Per i progetti di libreria di classi C#, aggiungere riferimenti ai pacchetti NuGet specifici per le estensioni di associazione richieste dalle funzioni. Il progetto script C# (con estensione csx) deve usare bundle di estensioni.

Funzioni fornisce bundle di estensioni per semplificare l'uso delle estensioni di binding nel progetto. I bundle di estensione, che vengono con versione e definiti nel file host.json, installano un set completo di pacchetti di estensioni di associazione compatibili per la tua app. Il host.json dovrebbe avere già bundle di estensioni abilitati. Se per qualche motivo è necessario aggiungere o aggiornare il bundle di estensione nel file host.json, vedere Bundle di estensioni.

Se è necessario usare un'estensione di associazione o una versione di estensione non in un bundle supportato, è necessario installare manualmente le estensioni. Per questi rari scenari, vedere il comando func extensions install.

Versioni di Core Tools

Le versioni principali di Azure Functions Core Tools sono collegate a versioni principali specifiche del runtime di Funzioni di Azure. Ad esempio, la versione 4.x di Core Tools supporta la versione 4.x del runtime di Funzioni. Questa versione è la versione principale consigliata sia del runtime di Funzioni che di Core Tools. È possibile determinare la versione più recente di Core Tools nel repository Azure Functions Core Tools.

Eseguire il comando seguente per determinare la versione dell'installazione corrente di Core Tools:

func --version

Se non specificato diversamente, gli esempi in questo articolo si riferiscono alla versione 4.x.

Le considerazioni seguenti si applicano alle installazioni di Core Tools:

È possibile installare una sola versione degli strumenti in un determinato computer.
Quando si esegue l'aggiornamento alla versione più recente di Core Tools, è necessario usare lo stesso metodo usato per l'installazione originale per eseguire l'aggiornamento. Ad esempio, se è stata usata un'identità del servizio gestito in Windows, disinstallare l'identità del servizio gestito corrente e installarla più recente. In alternativa, se è stato usato npm, eseguire di nuovo npm install command.
La versione 2.x e la 3.x di Core Tools sono state usate con le versioni 2.x e 3.x del runtime di Funzioni, che hanno raggiunto la fine del supporto. Per altre informazioni, vedere Panoramica delle versioni del runtime per Funzioni di Azure.

La versione 1.x di Core Tools è necessaria quando si usa la versione 1.x del runtime di Funzioni, che è ancora supportata. Questa versione di Core Tools può essere eseguita solo in locale nei computer Windows. Se è attualmente in esecuzione nella versione 1.x, è consigliabile prendere in considerazione eseguire la migrazione dell'app alla versione 4.x oggi.

Passaggi successivi

Informazioni su come sviluppare, testare e pubblicare funzioni di Azure usando gli strumenti di base di Funzioni di Azure. Strumenti di base di Funzioni di Azure è open source ed è ospitato su GitHub. Per registrare una richiesta per un bug o una funzionalità aprire un problema di GitHub.

Condividi tramite

Sviluppare Funzioni di Azure in locale con Core Tools

Installare gli strumenti di base per Funzioni di Azure

Ubuntu

Debian

Creare il progetto locale

Creare una funzione

Aggiungere un'associazione alla funzione

Avviare il runtime di Funzioni

Eseguire una funzione locale

Pubblicare in Azure

Distribuire i file di progetto

Distribuire contenitori

Usare le impostazioni dell'app in locale

Scaricare le impostazioni dell'applicazione

Scaricare una stringa di connessione a risorsa di archiviazione

Caricare le impostazioni locali in Azure

Crittografare il file delle impostazioni locali

Configurare le estensioni di associazione

Versioni di Core Tools

Passaggi successivi

Commenti e suggerimenti

Risorse aggiuntive