Usare Strumenti di base di Funzioni di Azure

Azure Functions Core Tools consente di sviluppare e testare le funzioni nel computer locale dal prompt dei comandi o dal terminale. Le funzioni locali possono connettersi ai servizi di Azure attivi ed è possibile eseguire il debug delle funzioni nel computer locale usando il runtime completo di Funzioni di Azure. È anche possibile distribuire un'app per le funzioni all'abbonamento di Azure.

Nota

Non combinare lo sviluppo locale con lo sviluppo del portale nella stessa app per le funzioni. Quando si creano e pubblicano funzioni da un progetto locale, non sarà possibile gestire o modificare il codice del progetto nel portale.

Lo sviluppo di funzioni nel computer locale e la pubblicazione in Azure tramite Gli strumenti di base seguono questa procedura di base:

Prerequisiti

I prerequisiti specifici per Gli strumenti di base dipendono dalle funzionalità che si prevede di usare:

Pubblica: gli strumenti di base dipendono attualmente dall'interfaccia della riga di comando di Azure o dalla Azure PowerShell per l'autenticazione con l'account Azure. Ciò significa che è necessario installare uno di questi strumenti per poter pubblicare in Azure da Funzioni di Azure Core Tools.

Installare le estensioni: per installare manualmente le estensioni usando Core Tools, è necessario installare .NET Core 3.1 SDK . .NET Core SDK viene usato da Core Tools per installare le estensioni da NuGet. Non è necessario conoscere .NET per usare le estensioni Funzioni di Azure.

Versioni di Core Tools

Esistono quattro versioni di Funzioni di Azure Core Tools. La versione usata dipende dall'ambiente di sviluppo locale, dalla scelta del linguaggio e dal livello di supporto richiesto.

Scegliere una scheda versione seguente per informazioni su ogni versione specifica e per istruzioni dettagliate sull'installazione:

Supporta la versione 4.x del runtime di Funzioni. Questa versione supporta Windows, macOS e Linux e usa gestioni pacchetti specifici della piattaforma o npm per l'installazione. Si tratta della versione consigliata del runtime di Funzioni e degli strumenti di base.

È possibile installare una sola versione di Core Tools in un determinato computer. Se non diversamente indicato, gli esempi di questo articolo sono per la versione 3.x.

Installare gli strumenti di base per Funzioni di Azure

Strumenti di base di Funzioni di Azure comprende una versione dello stesso runtime che alimenta Funzioni di Azure che è possibile eseguire nel computer di sviluppo locale. Fornisce anche i comandi per creare le funzioni, connettersi ad Azure e distribuire i progetti della funzione.

A partire dalla versione 2.x, Gli strumenti di base vengono eseguiti in Windows, macOS e Linux.

I passaggi seguenti usano 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 readme degli strumenti di base.

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

Modifica delle versioni di Core Tools

Quando si passa a una versione diversa di Core Tools, è necessario usare lo stesso gestore pacchetti dell'installazione originale per passare a una versione del pacchetto diversa. Ad esempio, se è stato installato Core Tools versione 2.x usando npm, è necessario usare il comando seguente per eseguire l'aggiornamento alla versione 3.x:

npm install -g azure-functions-core-tools@3 --unsafe-perm true

Se è stato usato Windows Installer (MSI) per installare Gli strumenti di base in Windows, è necessario disinstallare la versione precedente da Aggiungi programmi prima di installare una versione diversa.

Creare un progetto Funzioni locale

Una directory del progetto Funzioni contiene i file e le cartelle seguenti, indipendentemente dalla lingua:

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

Per altre informazioni sulla cartella del progetto Funzioni, vedere la guida agli sviluppatori di Funzioni di Azure.

Nella finestra del terminale o da un prompt dei comandi, eseguire il comando seguente per creare il progetto e l’archivio Git locale:

func init MyFunctionProj

In questo esempio viene creato un progetto Functions in una nuova MyFunctionProj cartella. Viene richiesto di scegliere una lingua predefinita per il progetto.

Le considerazioni seguenti si applicano all'inizializzazione del progetto:

  • Se non si fornisce l'opzione --worker-runtime nel comando, viene richiesto di scegliere la lingua. Per altre informazioni, vedere il riferimento a func init.

  • Quando non si specifica un nome di progetto, la cartella corrente viene inizializzata.

  • Se si prevede di pubblicare il progetto in un contenitore Linux personalizzato, usare l'opzione --docker per assicurarsi che un Dockerfile venga generato per il progetto. Per altre informazioni, vedere Creare una funzione in Linux usando un'immagine personalizzata.

Alcune lingue possono avere considerazioni aggiuntive:

  • Gli strumenti di base consentono di creare progetti di app per le funzioni per il runtime .NET come progetti di libreria di classi C# isolati e in processo di lavoro isolato (con estensione csproj). Questi progetti, che possono essere usati con Visual Studio o Visual Studio Code, vengono compilati durante il debug e durante la pubblicazione in Azure.

  • Usare il --csx parametro se si vuole usare localmente i file di script C# (con estensione csx). Si tratta degli stessi file che si ottengono quando si creano funzioni nel portale di Azure e quando si usa la versione 1.x di Core Tools. Per altre informazioni, vedere il riferimento a func init.

Registrare le estensioni

A partire dalla versione di runtime 2.x, i trigger e le associazioni di Funzioni vengono implementati come pacchetti di estensione .NET (NuGet). Per i progetti C# compilati, è sufficiente fare riferimento ai pacchetti di estensione NuGet per i trigger e le associazioni specifici in uso. Le associazioni HTTP e i trigger timer non richiedono estensioni.

Per migliorare l'esperienza di sviluppo per progetti non C#, Funzioni consente di fare riferimento a un bundle di estensioni con versione nel file di progetto host.json. I bundle di estensioni rendono tutte le estensioni disponibili per l'app e rimuove la possibilità di problemi di compatibilità dei pacchetti tra le estensioni. I bundle di estensione eliminano anche il requisito di installazione di .NET Core 3.1 SDK e la necessità di gestire il file extensions.csproj.

I bundle di estensioni sono l'approccio consigliato per i progetti di funzioni diversi dai progetti C# conformi, nonché per gli script C#. Per questi progetti, l'impostazione del bundle di estensione viene generata nel file host.json durante l'inizializzazione. Se i bundle non sono abilitati, è necessario aggiornare il file host.json del progetto.

Il modo più semplice per installare le estensioni di binding è consentire aggregazioni di estensione. Quando si abilitano i bundle, viene installato automaticamente un set predefinito di pacchetti di estensioni.

Per abilitare i bundle di estensioni, aprire il file host.json e aggiornarne il contenuto in modo che corrisponda al codice seguente:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[2.*, 3.0.0)"
    }
}

Per altre informazioni, vedere Registrare Funzioni di Azure estensioni di associazione.

In un progetto di non-.NET possono verificarsi casi in cui non è possibile usare bundle di estensione, ad esempio quando è necessario specificare come destinazione una versione specifica di un'estensione non nel bundle. In questi rari casi, è possibile usare Core Tools per installare localmente i pacchetti di estensione specifici richiesti dal progetto. Per altre informazioni, vedere Installare le estensioni.

Impostazioni locali

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 all'oggetto Values nel file local.settings.json. Il file local.settings.json archivia anche le impostazioni usate dagli strumenti di sviluppo locali.

Poiché local.settings.json può contenere segreti, ad esempio le stringhe di connessione, non è mai consigliabile archiviarlo in un repository remoto. Per altre informazioni sulle impostazioni locali, vedere File delle impostazioni locali.

Per impostazione predefinita, queste impostazioni non vengono migrate automaticamente quando il progetto viene pubblicato in Azure. Usare l'opzione--publish-local-settings quando si pubblica per assicurarsi che queste impostazioni vengano aggiunte all'app per le funzioni in Azure. I valori nella ConnectionStrings sezione non vengono mai pubblicati.

I valori delle impostazioni dell'app di funzione possono anche essere letti nel codice come variabili di ambiente. Per altre informazioni, vedere la sezione Variabili di ambiente negli argomenti di riferimento specifici del linguaggio seguenti:

Quando non è impostata alcuna stringa di connessione di archiviazione valida per AzureWebJobsStorage e non viene usato un emulatore di archiviazione locale, viene visualizzato il messaggio di errore seguente:

Valore mancante per AzureWebJobsStorage in local.settings.json. È necessario per tutti i trigger diversi da HTTP. È possibile eseguire 'func azure functionapp fetch-app-settings <functionAppName>' o specificare una stringa di connessione in local.settings.json.

Ottenere le stringhe di connessione di archiviazione

Anche quando si usa l'emulatore di archiviazione Azurite per lo sviluppo, è possibile eseguire localmente con una connessione di archiviazione effettiva. Supponendo di aver già creato un account di archiviazione, è possibile ottenere una stringa di connessione di archiviazione valida in uno dei diversi modi seguenti:

  1. Nella portale di Azure cercare e selezionare Account di archiviazione.

    Selezionare Account di archiviazione da portale di Azure

  2. Selezionare l'account di archiviazione, selezionare Chiavi di accesso in Impostazioni e quindi copiare uno dei valori stringa di connessione .

    Copiare la stringa di connessione dal portale di Azure

Creare una funzione

Per creare una funzione in un progetto esistente, eseguire il comando seguente:

func new

Nella versione 3.x/2.x, quando viene func new richiesto di scegliere un modello nella lingua predefinita dell'app per le funzioni. Verrà quindi richiesto di scegliere un nome per la funzione. Nella versione 1.x è anche necessario scegliere la lingua.

È anche possibile specificare il nome e il modello della func new funzione nel comando . Nell'esempio seguente viene usata l'opzione --template per creare un trigger HTTP denominato MyHttpTrigger:

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

In questo esempio viene creato un trigger di archiviazione code denominato MyQueueTrigger:

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

Per altre informazioni, vedere il func new comando .

Eseguire funzioni localmente

Per eseguire un progetto di Funzioni, eseguire l'host di Funzioni dalla directory radice del progetto. L'host abilita i trigger per tutte le funzioni nel progetto. Il start comando varia a seconda del linguaggio del progetto.

func start

Nota

La versione 1.x del runtime di Funzioni richiede func host startinvece . Per altre informazioni, vedere Funzioni di Azure Informazioni di riferimento su Core Tools.

All'avvio dell'host di Funzioni viene restituito l'URL delle funzioni attivate tramite HTTP, come nell'esempio seguente:

Found the following functions:
Host.Functions.MyHttpTrigger

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

Importante

Quando si esegue localmente, l'autorizzazione non viene applicata per gli endpoint HTTP. Questo significa che tutte le richieste HTTP locali vengono gestite come authLevel = "anonymous". Per altre informazioni, vedere l'articolo sul binding HTTP.

Passaggio di dati di test a una funzione

Per testare le funzioni localmente, avviare l'host di Funzioni e chiamare gli endpoint nel server locale usando richieste HTTP. L'endpoint chiamato dipende dal tipo di funzione.

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.

Per informazioni più generali sui test delle funzioni, vedere Strategie per il test del codice in Funzioni di Azure.

Funzioni attivate tramite HTTP e webhook

È possibile chiamare l'endpoint seguente per eseguire localmente funzioni attivate tramite HTTP e webhook:

http://localhost:{port}/api/{function_name}

Assicurarsi di usare lo stesso nome server e la stessa porta su cui è in ascolto l'host di Funzioni. Questi valori sono visualizzati nell'output generato all'avvio dell'host di Funzioni. È possibile chiamare questo URL usando qualsiasi metodo HTTP supportato dal trigger.

Il comando cURL seguente attiva la funzione di avvio rapido MyHttpTrigger da una richiesta GET con il parametro name passato nella stringa di query.

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

L'esempio seguente è la stessa funzione chiamata da una richiesta POST passando name nel corpo della richiesta:

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

È possibile effettuare richieste GET da un browser passando dati nella stringa di query. Per tutti gli altri metodi HTTP, è necessario usare cURL, Fiddler, Postman o uno strumento di test HTTP simile che supporta le richieste POST.

Funzione attivate non da HTTP

Per tutte le funzioni diverse dai trigger HTTP e Griglia di eventi, è possibile testare le funzioni in locale usando REST chiamando un endpoint speciale denominato endpoint di amministrazione. Chiamando questo endpoint con una richiesta HTTP POST sul server locale si attiva la funzione.

Per testare le funzioni attivate in locale, vedere Test locali con l'app Web visualizzatore.

È facoltativamente possibile passare dati di test all'esecuzione nel corpo del messaggio della richiesta POST. Questa funzionalità è analoga alla scheda Test del portale di Azure.

Chiamare l'endpoint di amministrazione seguente per attivare funzioni non HTTP:

http://localhost:{port}/admin/functions/{function_name}

Per passare dati di test all'endpoint di amministrazione di una funzione, è necessario fornire i dati nel corpo di un messaggio di richiesta POST. Il corpo del messaggio deve avere il formato JSON seguente:

{
    "input": "<trigger_input>"
}

Il valore <trigger_input> contiene dati nel formato previsto dalla funzione. L'esempio cURL seguente è una richiesta POST per una funzione QueueTriggerJS. In questo caso l'input è una stringa che equivale al messaggio previsto nella coda.

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

Quando si chiama un endpoint di amministratore nell'app per le funzioni in Azure, è necessario fornire una chiave di accesso. Per altre informazioni, vedere Chiavi di accesso alle funzioni.

Pubblicazione in Azure

Gli strumenti di base Funzioni di Azure supportano due 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.
Cluster Kubernetes func kubernetes deploy Distribuisce l'app per le funzioni Linux come contenitore Docker personalizzato in un cluster Kubernetes.

Prima di pubblicare

Importante

È necessario avere l'interfaccia della riga di comando di Azure o Azure PowerShell installata in locale per poter pubblicare in Azure da Strumenti di base.

Una cartella del progetto può contenere file e directory specifici del linguaggio che non devono essere pubblicati. Gli elementi esclusi sono elencati in un file con estensione funcignore nella cartella del progetto radice.

È necessario aver già creato un'app per le funzioni nella sottoscrizione di Azure, a cui distribuire il codice. I progetti che richiedono la compilazione devono essere compilati in modo che i file binari possano essere distribuiti.

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.

Importante

Quando si crea un'app per le funzioni nella portale di Azure, usa la versione 3.x del runtime di funzioni per impostazione predefinita. Per far eseguire la versione 1.x del runtime all'app per le funzioni, osservare le istruzioni riportate in Run on version 1.x (Esecuzione sulla versione 1.x). Non è possibile modificare la versione di runtime per un'app per le funzioni che ha funzioni esistenti.

Distribuire i file di progetto

Per pubblicare il codice locale in un'app per le funzioni in Azure, usare il comando publish:

func azure functionapp publish <FunctionAppName>

Le considerazioni seguenti si applicano a questo tipo di distribuzione:

  • La pubblicazione sovrascrive i file esistenti nell'app per le funzioni.

  • 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.

  • Viene eseguita una compilazione remota nei progetti compilati. Questo può essere controllato usando l'opzione--no-build .

  • Il progetto viene distribuito in modo che venga eseguito dal pacchetto di distribuzione. Per disabilitare questa modalità di distribuzione consigliata, usare l'opzione--nozip .

  • Java usa Maven per pubblicare il progetto locale in Azure. Usare invece il comando seguente per pubblicare in Azure: mvn azure-functions:deploy. Le risorse di Azure vengono create durante la distribuzione iniziale.

  • Verrà visualizzato un errore se si tenta di pubblicare in un <FunctionAppName> oggetto che non esiste nella sottoscrizione.

Cluster Kubernetes

Le funzioni consentono anche di definire il progetto Funzioni da eseguire in un contenitore Docker. Usare l'opzione--docker di func init per generare un Dockerfile per la lingua specifica. Questo file viene quindi usato durante la creazione di un contenitore da distribuire. Per informazioni su come pubblicare un contenitore personalizzato in Azure senza Kubernetes, vedere Creare una funzione in Linux usando un contenitore personalizzato.

Gli strumenti di base possono essere usati per distribuire il progetto come immagine del contenitore personalizzata in un cluster Kubernetes.

Il comando seguente usa dockerfile per generare un contenitore e distribuirlo in un cluster Kubernetes.

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

Per altre informazioni, vedere Distribuzione di un'app per le funzioni in Kubernetes.

Installare le estensioni

Se non è possibile usare bundle di estensione, è possibile usare Funzioni di Azure Core Tools in locale per installare i pacchetti di estensione specifici richiesti dal progetto.

Importante

Non è possibile installare in modo esplicito le estensioni in un'app per le funzioni con bundle di estensioni abilitati. Prima di tutto, rimuovere la extensionBundle sezione in host.json prima di installare in modo esplicito le estensioni.

Gli elementi seguenti descrivono alcuni motivi per cui potrebbe essere necessario installare manualmente le estensioni:

  • È necessario accedere a una versione specifica di un'estensione non disponibile in un bundle.
  • È necessario accedere a un'estensione personalizzata non disponibile in un bundle.
  • È necessario accedere a una combinazione specifica di estensioni non disponibili in un singolo bundle.

Quando si installano in modo esplicito le estensioni, viene aggiunto un file di progetto .NET denominato extensions.csproj alla radice del progetto. Questo file definisce il set di pacchetti NuGet richiesti dalle funzioni. Anche se è possibile usare i riferimenti al pacchetto NuGet in questo file, Core Tools consente di installare le estensioni senza dover modificare manualmente questo file di progetto C#.

Esistono diversi modi per usare Gli strumenti di base per installare le estensioni necessarie nel progetto locale.

Installare tutte le estensioni

Usare il comando seguente per aggiungere automaticamente tutti i pacchetti di estensione usati dalle associazioni nel progetto locale:

func extensions install

Il comando legge il file function.json per visualizzare i pacchetti necessari, li installa e ricompila il progetto estensioni (extensions.csproj). Aggiunge nuove associazioni alla versione corrente, ma non aggiorna le associazioni esistenti. Usare l'opzione --force per aggiornare le associazioni esistenti alla versione più recente quando si installano quelle nuove. Per altre informazioni, vedere il func extensions install comando.

Se l'app per le funzioni usa associazioni o pacchetti NuGet che Core Tools non riconosce, è necessario installare manualmente l'estensione specifica.

Installare un'estensione specifica

Usare il comando seguente per installare un pacchetto di estensione specifico in una versione specifica, in questo caso l'estensione di archiviazione:

func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 5.0.0

È possibile usare questo comando per installare qualsiasi pacchetto NuGet compatibile. Per altre informazioni, vedere il func extensions install comando.

Monitoraggio delle funzioni

Il modo consigliato per monitorare l'esecuzione delle funzioni consiste nell'integrazione con applicazione Azure Insights. È anche possibile trasmettere i log di esecuzione al computer locale. Per altre informazioni, vedere Monitorare Funzioni di Azure.

Integrazione di Application Insights

L'integrazione di Application Insights deve essere abilitata quando si crea l'app per le funzioni in Azure. Se per qualche motivo l'app per le funzioni non è connessa a un'istanza di Application Insights, è facile eseguire questa integrazione nel portale di Azure. Per altre informazioni, vedere Abilitare l'integrazione di Application Insights.

Abilitare i log di streaming

È possibile visualizzare un flusso di file di log generati dalle funzioni in una sessione della riga di comando nel computer locale.

Streaming dei log predefinito

Usare il comando per avviare la func azure functionapp logstream ricezione di log di streaming di un'app per le funzioni specifica in esecuzione in Azure, come nell'esempio seguente:

func azure functionapp logstream <FunctionAppName>

Nota

Lo streaming di log predefinito non è ancora abilitato in Core Tools per le app per le funzioni in esecuzione in Linux con un piano a consumo. Per questi piani di hosting, è invece necessario usare Live Metrics Stream per visualizzare i log quasi in tempo reale.

Flusso di metriche live

È possibile visualizzare Live Metrics Stream per l'app per le funzioni in una nuova finestra del browser includendo l'opzione --browser, come nell'esempio seguente:

func azure functionapp logstream <FunctionAppName> --browser

Questo tipo di log di streaming richiede che l'integrazione di Application Insights sia abilitata per l'app per le funzioni.

Emulazione x86 in ARM64

Le funzioni attualmente non supportano lo sviluppo di funzioni Python locali nei dispositivi ARM64. Usare la procedura seguente per sviluppare funzioni Python in un Mac con un chip M1 eseguendo in un ambiente x86 emulato.

Abilitare Rosetta nel terminale

  1. Nel Mac aprire Finder, scegliere Applicazioni e individuare Terminale.

  2. Fare clic su Terminale e selezionare Recupera informazioni. È anche possibile creare un ambiente parallelo separato duplicando il terminale e rinominandolo.

    Screenshot della selezione di Ottieni informazioni facendo clic su Terminale

  3. Selezionare Apri usando Rosetta.

    Screenshot del terminale configurato per l'apertura con Rosetta

  4. Aprire Terminale, che ora ha Rosetta abilitato e assicurarsi che la shell sia zsh.

  5. Eseguire il comando seguente per convalidare l'emulazione x86.

    $ arch
    

    Una risposta di i386 indica che il terminale esegue un ambiente emulato x86.

Installare i pacchetti necessari

Reinstallare tutte le dipendenze richieste da Funzioni in questo ambiente, che include i pacchetti seguenti:

Reinstallare anche tutti gli altri pacchetti richiesti dal progetto Python.

Impostare gli alias (facoltativo)

Facoltativamente, è possibile impostare alias per semplificare il riferimento alle versioni corrette in Rosetta.

Di seguito è riportato un esempio di come creare un file con estensione zshrc per configurare il terminale zsh:

# file: .zshrc
# rosetta terminal setup
if [ $(arch) = "i386" ]; then
    alias python="/usr/local/bin/python3"
    alias brew86='/usr/local/bin/brew'
    alias pyenv86="arch -x86_64 pyenv"
    alias func="/usr/local/Cellar/azure-functions-core-tools@4/4.0.4785/func"
fi

Eseguire il comando seguente per applicare gli alias:

$ source .zshrc

Verificare di fare riferimento alle versioni corrette usando il which comando , come illustrato negli esempi seguenti:

Comando Risposta di esempio
$ which python python: aliased to /usr/local/bin/python3
$ which func func: aliased to /usr/local/Cellar/azure-functions-core-tools@4/4.0.4785/func

Queste risposte di esempio si basano sul file zshrc di esempio precedente.

A questo momento, è possibile usare Funzioni di Azure nell'ambiente x86 dal terminale.

Se si usa Visual Studio Code, è possibile integrare Rosetta con il terminale predefinito. Per altre informazioni, vedere Abilitare l'emulazione in Visual Studio Code.

Passaggi successivi

Informazioni su come sviluppare, testare e pubblicare funzioni di Azure usando Funzioni di Azure strumenti di base. 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.