Utiliser Azure Functions Core Tools

Azure Functions Core Tools vous permet de développer et de tester vos fonctions sur votre ordinateur local à partir de l’invite de commandes ou du terminal. Vos fonctions locales peuvent être connectées aux services Azure actifs, et vous pouvez déboguer vos fonctions sur votre ordinateur local à l’aide du runtime Functions complet. Vous pouvez même déployer une application de fonction sur votre abonnement Azure.

Important

Ne mélangez pas un développement local avec un développement de portail dans une même application de fonction. Lorsque vous créez et publiez des fonctions à partir d'un projet local, vous ne devez pas essayer de maintenir ou de modifier le code du projet dans le portail.

Développez des fonctions sur votre ordinateur local et publiez-les sur Azure à l’aide de Core Tools en suivant ces étapes de base :

Versions de Core Tools

Il existe trois versions d’Azure Functions Core Tools. La version que vous utilisez dépend de votre environnement de développement local, du choix du langage et du niveau de prise en charge requis :

  • Version 3.x/2.x : Prend en charge la version 3.x ou 2.x du runtime Azure Functions. Ces versions prennent en charge Windows, macOS et Linux et utilisent des gestionnaires de package spécifiques à la plateforme ou npm pour l’installation.

  • Version 1.x : Prend en charge la version 1.x du runtime Azure Functions. Cette version des outils est uniquement prise en charge sur les ordinateurs Windows et est installée à partir d’un package npm.

Vous ne pouvez installer qu’une seule version de Core Tools sur un ordinateur donné. Sauf indication contraire, les exemples de cet article concernent la version 3.x.

Prérequis

Azure Functions Core Tools dépend d’Azure CLI ou d’Azure PowerShell pour l’authentification auprès de votre compte Azure. Cela signifie que vous devez installer l’un de ces outils pour pouvoir publier sur Azure à partir d’Azure Functions Core Tools.

Installer Azure Functions Core Tools

Azure Functions Core Tools inclut une version du même runtime qu’Azure Functions, que vous pouvez exécuter sur votre ordinateur de développement local. Il fournit également des commandes pour créer des fonctions, se connecter à Azure et déployer des projets de fonction.

Versions 3.x et 2.x

La version 3.x ou 2.x des outils utilise le runtime Azure Functions qui repose sur .NET Core. Cette version est prise en charge sur tous les supports des plateformes .NET Core, notamment Windows, macOS et Linux.

Important

Vous pouvez contourner l’obligation d’installer le kit SDK .NET Core en utilisant des bundles d’extension.

Les étapes suivantes utilisent un programme d’installation Windows (MSI) pour installer Core Tools v3.x. Pour plus d’informations sur les autres programmes d’installation basés sur des packages, qui sont nécessaires à l’installation de Core Tools v2.x, consultez le fichier Lisez-moi de Core Tools.

  1. Téléchargez et exécutez le programme d’installation de Core Tools, selon votre version de Windows :

  2. Si vous ne prévoyez pas d’utiliser des bundles d’extension, installez le Kit de développement logiciel (SDK) .NET Core 3.x pour Windows.

Créer un projet Functions local

Un répertoire de projet Functions contient les fichiers host.json et local.settings.json, ainsi que des sous-dossiers qui contiennent le code des fonctions individuelles. Ce répertoire est l’équivalent d’une application de fonction dans Azure. Pour en savoir plus sur la structure de dossiers Functions, consultez le Guide de développement Azure Functions.

Pour la version 3.x/2.x, vous devez sélectionner un langage par défaut pour votre projet lors de son initialisation. Dans la version 3.x/2.x, toutes les fonctions ajoutées utilisent des modèles de langage par défaut. Dans la version 1.x, vous spécifiez le langage à chaque fois que vous créez une fonction.

Dans la fenêtre du terminal ou à partir d’une invite de commandes, exécutez la commande suivante pour créer le projet et le référentiel Git local :

func init MyFunctionProj

Important

Java utilise un archétype Maven pour créer le projet Functions local, ainsi que votre première fonction déclenchée par HTTP. Utilisez la commande suivante pour créer votre projet Java : mvn archetype:generate -DarchetypeGroupId=com.microsoft.azure -DarchetypeArtifactId=azure-functions-archetype. Pour obtenir un exemple d’utilisation de l’archétype Maven, consultez le démarrage rapide par lignes de commande.

Lorsque vous fournissez un nom de projet, un nouveau dossier portant ce nom est créé et initialisé. Sinon, le dossier actif est initialisé.
Dans la version 3.x/2.x, lorsque vous exécutez la commande, vous devez choisir un runtime pour votre projet.

Select a worker runtime:
dotnet
node
python 
powershell

Utilisez les touches de direction haut/bas pour choisir un langage, puis appuyez sur Entrée. Si vous envisagez de développer des fonctions JavaScript ou TypeScript, choisissez nœud, puis sélectionnez la langue. TypeScript comprend des exigences supplémentaires.

Le résultat ressemble à l’exemple suivant pour un projet JavaScript :

Select a worker runtime: node
Writing .gitignore
Writing host.json
Writing local.settings.json
Writing C:\myfunctions\myMyFunctionProj\.vscode\extensions.json
Initialized empty Git repository in C:/myfunctions/myMyFunctionProj/.git/

func init prend en charge les options suivantes, qui sont, sauf indication contraire, uniquement des versions 3.x/2.x :

Option Description
--csx Crée des fonctions .NET en tant que script C#, ce qui correspond au comportement de la version 1.x. Valide uniquement avec --worker-runtime dotnet.
--docker Crée un fichier Dockerfile pour un conteneur à l’aide d’une image de base définie par le --worker-runtime choisi. Utiliser cette option lorsque vous projetez de publier sur un conteneur Linux personnalisé.
--docker-only Ajoute un fichier Dockerfile à un projet existant. Demande le runtime Worker s’il n’est pas spécifié ou défini dans local.settings.json. Utiliser cette option lorsque vous projetez de publier un projet existant sur un conteneur Linux personnalisé.
--force Initialiser le projet même lorsque celui-ci contient des fichiers existants. Ce paramètre remplace les fichiers existants portant le même nom. D’autres fichiers dans le dossier du projet ne sont pas affectés.
--language Initialise un projet spécifique au langage. Actuellement pris en charge lorsque --worker-runtime est défini sur node. Les options sont typescript et javascript. Vous pouvez également utiliser --worker-runtime javascript ou --worker-runtime typescript.
--managed-dependencies Installe des dépendances gérées. Actuellement, seul un runtime worker PowerShell prend en charge cette fonctionnalité.
--source-control Contrôle la création d’un référentiel git. Par défaut, un référentiel n’est pas créé. Un référentiel est créé lorsque true.
--worker-runtime Définit le runtime de langage pour le projet. Les valeurs prises en charge sont : csharp, dotnet, javascript,node (JavaScript), powershell, python et typescript. Pour Java, utilisez Maven. Lorsqu’il n’est pas défini, vous êtes invité à choisir votre runtime pendant l’initialisation.

Important

Par défaut, la version 2.x et les versions ultérieures des outils Core créent les projets d’application de fonctions pour le runtime .NET en tant que projets de classes C# (.csproj). Ces projets C#, qui peuvent être utilisés avec Visual Studio ou Visual Studio Code, sont compilés pendant les tests et lors de la publication sur Azure. Si vous voulez plutôt créer et utiliser les mêmes fichiers de script C# (.csx) que ceux créés dans la version 1.x et dans le portail, vous devez inclure le paramètre --csx quand vous créez et que vous déployez des fonctions.

Inscrire des extensions

À l’exception des déclencheurs HTTP et de minuteur, les liaisons Functions dans les versions 2.x et ultérieures du runtime sont implémentées sous la forme de packages d’extension. Les liaisons HTTP et les déclencheurs de minuteur ne nécessitent pas d’extensions.

Pour réduire les incompatibilités entre les différents packages d’extension, Functions vous permet de référencer un groupe d’extensions dans votre fichier de projet host.json. Si vous choisissez de ne pas utiliser les packages d’extension, vous devez également installer le kit de développement logiciel (SDK) .NET Core 2. x localement et conserver un fichier extensions.csproj avec votre projet Functions.

Dans les versions 2.x et ultérieures du runtime Azure Functions, vous devez inscrire explicitement les extensions pour les types de liaisons utilisés dans vos fonctions. Vous pouvez choisir d’installer les extensions de liaison individuellement, ou ajouter une référence de bundle d’extensions au fichier du projet host.json. Les bundles d’extensions suppriment le risque d’avoir des problèmes de compatibilité de packages lors de l’utilisation de plusieurs types de liaisons. C’est la méthode recommandée pour inscrire des extensions de liaison. Les bundles d’extensions éliminent également l’obligation d’installer le kit SDK .NET Core 2.x.

Utiliser les packs d’extensions

Le moyen le plus simple d’installer les extensions de liaison consiste à activer les offres groupées d’extension. Lorsque vous activez les offres groupées, un ensemble prédéfini de packages d’extension sont automatiquement installés.

Pour activer les offres groupées d’extension, ouvrez le fichier host.json et mettez à jour son contenu pour qu’il corresponde au code suivant :

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

Pour en savoir plus, consultez Inscrire des extensions de liaison Azure Functions. Vous devez ajouter des packages d’extension au fichier host.json avant d’ajouter des liaisons au fichier function.json.

Installer des extensions de manière explicite

Si vous ne pouvez pas utiliser les packs d’extensions, vous pouvez utiliser Azure Functions Core Tools localement pour installer les packs d’extensions spécifiques requis par votre projet.

Important

Vous ne pouvez pas installer explicitement des extensions dans une application de fonction qui utilise des bundles d’extension. Supprimez la section extensionBundle dans host.json avant d’installer des extensions de manière explicite.

Les éléments suivants décrivent certaines raisons pour lesquelles vous devrez peut-être installer des extensions manuellement :

  • Vous devez accéder à une version spécifique d’une extension qui n’est pas disponible dans un bundle.
  • Vous devez accéder à une extension personnalisée qui n’est pas disponible dans un bundle.
  • Vous devez accéder à une combinaison spécifique d’extensions non disponibles dans un seul bundle.

Notes

Pour installer manuellement des extensions avec Core Tools, le kit SDK .NET Core 2.x doit être installé. Azure Functions Core Tools installe le kit SDK .NET Core pour installer des extensions à partir de NuGet. Vous n’avez pas besoin de connaître .NET pour utiliser les extensions Azure Functions.

Lorsque vous installez explicitement des extensions, un fichier de projet .NET nommé extensions.csproj est ajouté à la racine de votre projet. Ce fichier définit l’ensemble des packages NuGet requis par vos fonctions. Bien que vous puissiez utiliser les références de package NuGet dans ce fichier, Core Tools vous permet d’installer des extensions sans avoir à modifier manuellement le fichier.

Il existe plusieurs façons d’utiliser les outils de base pour installer les extensions requises dans votre projet local.

Installer toutes les extensions

Utilisez la commande suivante pour ajouter automatiquement tous les packages d’extensions utilisés par les liaisons dans votre projet local :

func extensions install

La commande lit le fichier function.json pour voir les packages dont vous avez besoin, les installe et regénère le projet des extensions (extensions.csproj). Il ajoute les nouvelles liaisons à la version actuelle, mais ne met pas à jour les liaisons existantes. Utilisez l’option --force pour mettre à jour les liaisons existantes vers la dernière version pendant les nouvelles installations.

Si votre application de fonction utilise des liaisons que les outils Core ne reconnaissent pas, vous devez installer manuellement l’extension spécifique.

Installer une extension spécifique

Utilisez la commande suivante pour installer un package d’extension spécifique à une version spécifique, dans ce cas l’extension Storage :

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

Fichier de paramètres locaux

Le fichier local.settings.json stocke des paramètres d’application, des chaînes de connexion et des paramètres utilisés par des outils de développement locaux. Les paramètres dans le fichier local.settings.json sont uniquement utilisés lorsque vous exécuter les projets localement. Le fichier de paramètres locaux possède la structure suivante :

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

Ces paramètres sont pris en charge lorsque vous exécutez des projets localement :

Paramètre Description
IsEncrypted Lorsque ce paramètre est défini sur true, toutes les valeurs sont chiffrées à l’aide d’une clé d’ordinateur local. Utilisé avec les commandes func settings. La valeur par défaut est false. Vous voudrez peut-être chiffrer le fichier local.settings.json sur votre ordinateur local lorsqu’il contient des secrets, tels que des chaînes de connexion de service. L’hôte déchiffre automatiquement les paramètres quand il s’exécute. Utilisez la commande func settings decrypt avant d’essayer de lire les paramètres chiffrés localement.
Values Tableau des paramètres d’application et des chaînes de connexion utilisés lors de l’exécution locale d’un projet. Ces paires clé-valeur (chaîne-chaîne) correspondent aux paramètres d’application dans votre Function App dans Azure, tels que [AzureWebJobsStorage]. Plusieurs déclencheurs et liaisons ont une propriété qui fait référence à un paramètre d’application de chaîne de connexion, par exemple Connection pour le déclencheur de stockage blob. Pour ces propriétés, vous avez besoin d’un paramètre d’application défini dans le tableau Values. Consultez le tableau suivant pour une liste des paramètres couramment utilisés.
Les valeurs doivent être des chaînes et non des objets JSON ou des tableaux. Les noms de paramètres ne peuvent pas contenir le signe deux points (:) ou un trait de soulignement double (__). Les caractères de soulignement double sont réservés par le runtime, et le signe deux-points est réservé pour la prise en charge de l’injection de dépendances.
Host Les paramètres de cette section personnalisent le processus hôte Functions lorsque vous exécutez localement des projets. Ces paramètres sont séparés des paramètres host.json, qui s’appliquent également lorsque vous exécutez localement des projets dans Azure.
LocalHttpPort Définit le port par défaut utilisé lors de l’exécution de l’hôte Functions local (func host start et func run). --portL’option de ligne de commande est prioritaire sur ce paramètre. Par exemple, lors de l’exécution dans l’IDE Visual Studio, vous pouvez changer le numéro de port en accédant à la fenêtre « Propriétés du projet -> Débogage » et en spécifiant explicitement le numéro de port dans une commande host start --port <your-port-number> qui peut être fournie dans le champ « Arguments de l’application ».
CORS Définit les origines autorisées pour cross-origin resource sharing (CORS). Les origines sont fournies sous la forme d’une liste séparée par des virgules, sans espaces. La valeur de caractère générique (*) est prise en charge, ce qui autorise les demandes à partir de toute origine.
CORSCredentials Lorsque qu’il est défini sur true, autorise withCredentials les requêtes.
ConnectionStrings Une collection. N’utilisez pas cette collection pour les chaînes de connexion utilisées par vos liaisons de fonction. Cette collection est utilisée seulement par les infrastructures qui obtiennent généralement les chaînes de connexion à partir de la ConnectionStringssection d’un fichier de configuration, comme Entity Framework. Les chaînes de connexion dans cet objet sont ajoutées à l’environnement avec le type de fournisseur System.Data.SqlClient. Les éléments de cette collection ne sont pas publiés sur Azure avec d’autres paramètres d’application. Vous devez explicitement ajouter ces valeurs à la collection Connection strings des paramètres de Function App. Si vous créez un SqlConnection dans votre code de fonction, vous devez stocker la valeur de la chaîne de connexion et vos autres connexions dans Paramètres d’application dans le portail.

Les paramètres d’application suivants peuvent être inclus dans le tableau Values lors d’une exécution locale :

Paramètre Valeurs Description
AzureWebJobsStorage Chaîne de connexion de compte de stockage ou
UseDevelopmentStorage=true
Contient la chaîne de connexion pour un compte de stockage Azure. Obligatoire lors de l’utilisation de déclencheurs autres que HTTP. Pour plus d’informations, consultez les informations de référence sur [AzureWebJobsStorage].
Lorsque vous installez l’émulateur de stockage Azure localement et définissez [AzureWebJobsStorage] sur UseDevelopmentStorage=true, Core Tools utilise l’émulateur. L’émulateur est utile lors du développement, mais vous devez le tester avec une connexion de stockage réelle avant le déploiement.
AzureWebJobs.<FUNCTION_NAME>.Disabled true|false Pour désactiver une fonction qui s’exécute localement, ajoutez "AzureWebJobs.<FUNCTION_NAME>.Disabled": "true" à la collection, où <FUNCTION_NAME> est le nom de la fonction. Pour en savoir plus, consultez Guide pratique pour désactiver des fonctions dans Azure Functions
FUNCTIONS_WORKER_RUNTIME dotnet
node
java
powershell
python
Indique le langage ciblé du runtime Functions. Obligatoire pour la version 2.x et ultérieure du runtime Functions. Ce paramètre est généré pour votre projet par Core Tools. Pour plus d’informations, consultez les informations de référence sur FUNCTIONS_WORKER_RUNTIME.
FUNCTIONS_WORKER_RUNTIME_VERSION ~7 Indique que PowerShell 7 doit être utilisé lors d’une exécution locale. S’il n’est pas défini, PowerShell Core 6 est utilisé. Ce paramètre est utilisé seulement lors d’une exécution locale. Lors d’une exécution dans Azure, la version du runtime PowerShell est déterminée par le paramètre de configuration du site powerShellVersion, qui peut être défini dans le portail.

Par défaut, ces paramètres ne sont pas migrés automatiquement lorsque le projet est publié dans Azure. Utilisez le commutateur --publish-local-settingslors de la publication pour vous assurer que ces paramètres sont ajoutés à l’application de fonction dans Azure. Notez que les valeurs dans ConnectionStrings ne sont jamais publiées.

Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour plus d’informations, consultez la section Variables d’environnement de ces rubriques de référence spécifiques à une langue :

Si aucune chaîne de connexion de stockage valide n’est définie pour [AzureWebJobsStorage] et que l’émulateur n’est pas utilisé, le message d’erreur suivant s’affiche :

Valeur manquante pour AzureWebJobsStorage dans local.settings.json. Cette valeur est nécessaire pour tous les déclencheurs autres que HTTP. Vous pouvez exécuter 'func azure functionapp fetch-app-settings <functionAppName>' ou spécifier une chaîne de connexion dans local.settings.json.

Obtenir vos chaînes de connexion de stockage

Même si vous utilisez l’Émulateur de stockage Microsoft Azure pour le développement, vous pouvez tester votre configuration avec une connexion de stockage réelle. Si vous avez déjà créé un compte de stockage, vous pouvez obtenir une chaîne de connexion de stockage valide de l’une des manières suivantes :

  • Dans le Azure portal, recherchez et sélectionnez Comptes de stockage. Sélectionner des comptes de stockage à partir du Portail Azure

    Sélectionnez votre compte de stockage, sélectionnez Clés d’accès dans Paramètres, puis copiez une des valeurs Chaîne de connexion. Copier une chaîne de connexion à partir du portail Azure

  • Utilisez l’Explorateur Stockage Azure pour vous connecter à votre compte Azure. Dans l’Explorateur, développez votre abonnement et Comptes de stockage, sélectionnez votre compte de stockage et copiez la chaîne de connexion principale ou secondaire.

    Copier une chaîne de connexion à partir de l’Explorateur Stockage Azure

  • Utilisez Core Tools à partir de la racine du projet pour télécharger la chaîne de connexion à partir d’Azure à l’aide d’une des commandes suivantes :

    • Téléchargez tous les paramètres à partir d’une application de fonction existante :

      func azure functionapp fetch-app-settings <FunctionAppName>
      
    • Obtenez la chaîne de connexion pour un compte de stockage spécifique :

      func azure storage fetch-connection-string <StorageAccountName>
      

      Si vous n’êtes pas encore connecté à Azure, vous êtes invité à le faire. Ces commandes remplacent les paramètres existants dans le fichier local.settings.json.

Créer une fonction

Exécutez la commande suivante pour créer une fonction :

func new

Dans la version 3.x/2.x, lorsque vous exécutez func new, vous êtes invité à choisir un modèle dans le langage par défaut de votre application de fonction, puis vous êtes également invité à choisir un nom pour votre fonction. Dans la version 1.x, vous êtes également invité à choisir le langage.

Select a language: Select a template:
Blob trigger
Cosmos DB trigger
Event Grid trigger
HTTP trigger
Queue trigger
SendGrid
Service Bus Queue trigger
Service Bus Topic trigger
Timer trigger

Le code de la fonction est généré dans un sous-dossier portant le nom que vous avez indiqué pour la fonction, comme vous pouvez le voir dans la sortie de déclencheur de file d’attente suivante :

Select a language: Select a template: Queue trigger
Function name: [QueueTriggerJS] MyQueueTrigger
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\index.js
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\readme.md
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\sample.dat
Writing C:\myfunctions\myMyFunctionProj\MyQueueTrigger\function.json

Vous pouvez également spécifier ces options dans la commande en utilisant les arguments suivants :

Argument Description
--csx (Version 2.x et versions ultérieures.) Génère les mêmes modèles de script C# (.csx) que ceux utilisés dans la version 1.x et dans le portail.
--language, -l Langage de programmation du modèle, tel que C#, F# ou JavaScript. Cette option est requise dans la version 1.x. Dans la version 2.x et les versions ultérieures, n’utilisez pas cette option ou choisissez un langage qui correspond au runtime worker.
--name, -n Nom de la fonction.
--template, -t Utilisez la commande func templates list pour afficher la liste complète des modèles disponibles pour chaque langage pris en charge.

Par exemple, pour créer un déclencheur HTTP JavaScript dans une seule commande, exécutez :

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

Pour créer une fonction de déclencheur par file d’attente, exécutez :

func new --template "Queue Trigger" --name QueueTriggerJS

Exécuter des fonctions localement

Pour exécuter un projet Functions, exécutez l’hôte Functions. L’hôte active les déclencheurs pour toutes les fonctions du projet. La commande de démarrage varie selon le langage de votre projet.

func start --build

Notes

La version 1. x du runtime Functions requiert la commande host, comme dans l’exemple suivant :

func host start

func start prend en charge les options suivantes :

Option Description
--no-build Ne générez pas le projet actif avant l’exécution. Pour les projets dotnet uniquement. La valeur par défaut est false. Non pris en charge pour la version 1.x.
--cors-credentials Autoriser les demandes authentifiées cross-origin (autrement dit, les cookies et l’en-tête d’authentification). Non pris en charge pour la version 1.x.
--cors Liste séparée par des virgules d’origines CORS, sans espaces.
--language-worker Arguments pour configurer le travailleur de langage. Par exemple, vous pouvez activer le débogage pour le rôle de travail du langage en fournissant un port de débogage et d’autres arguments requis. Non pris en charge pour la version 1.x.
--cert Le chemin d’accès vers un fichier .pfx qui contient une clé privée. Utilisé uniquement avec --useHttps. Non pris en charge pour la version 1.x.
--password Le mot de passe ou un fichier qui contient le mot de passe pour un fichier .pfx. Utilisé uniquement avec --cert. Non pris en charge pour la version 1.x.
--port, -p Port local à écouter. Valeur par défaut : 7071.
--pause-on-error Marquage d’une pause pour des entrées supplémentaires avant de quitter le processus. Uniquement utilisé lors du lancement des outils de base à partir d’un environnement de développement intégré (IDE).
--script-root, --prefix Utilisé pour spécifier le chemin d’accès à la racine de l’application de fonction qui doit être exécutée ou déployée. Il est utilisé pour les projets compilés qui génèrent des fichiers projet dans un sous-dossier. Par exemple, lorsque vous générez un projet de bibliothèque de classes C#, les host.json, local.settings.json et function.json sont générés dans un sous-dossier racine avec un chemin d’accès comme MyProject/bin/Debug/netstandard2.0. Dans ce cas, définissez le préfixe comme --script-root MyProject/bin/Debug/netstandard2.0. Il s’agit de la racine de l’application de fonction lors de l’exécution sur Azure.
--timeout, -t Délai d’expiration pour le démarrage de l’hôte Functions, en secondes. Valeur par défaut : 20 secondes.
--useHttps Liaison avec https://localhost:{port} plutôt que http://localhost:{port}. Par défaut, cette option crée un certificat de confiance sur votre ordinateur.

Quand l’hôte Functions démarre, il génère l’URL des fonctions déclenchées par HTTP :

Found the following functions:
Host.Functions.MyHttpTrigger

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

Important

Lors d’une exécution locale, l’autorisation n’est pas appliquée pour les points de terminaison HTTP. Cela signifie que toutes les demandes HTTP locales sont gérées de manière authLevel = "anonymous". Pour plus d’informations, consultez l’article sur la liaison HTTP.

Transmission de données de test à une fonction

Pour tester vos fonctions localement, vous démarrez l’hôte Functions et vous appelez des points de terminaison sur le serveur local avec des requêtes HTTP. Le point de terminaison que vous appelez varie selon le type de fonction.

Notes

Les exemples de cette rubrique utilisent l’outil cURL pour envoyer des requêtes HTTP à partir du terminal ou d’une invite de commandes. Vous pouvez utiliser un outil de votre choix pour envoyer les requêtes HTTP au serveur local. L’outil cURL est disponible par défaut sur les systèmes Linux et Windows 10 Build 17063 et versions ultérieures. Avec les anciennes versions de Windows, vous devez d’abord télécharger et installer l’outil cURL.

Pour des informations plus générales sur le test de fonctions, consultez Stratégies permettant de tester votre code dans Azure Functions.

Fonctions déclenchées par HTTP et par Webhook

Vous appelez le point de terminaison suivant pour exécuter localement des fonctions déclenchées par HTTP et par Webhook :

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

Vérifiez que vous utilisez le même nom de serveur et le même port que celui où l’hôte Functions écoute. Vous voyez cela dans la sortie générée lors du démarrage de l’hôte Functions. Vous pouvez appeler cette URL en utilisant n’importe quelle méthode HTTP prise en charge par le déclencheur.

La commande cURL suivante déclenche la fonction de démarrage rapide MyHttpTrigger à partir d’une demande GET avec le paramètre name passé dans la chaîne de requête.

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

L’exemple suivant est la même fonction appelée à partir d’une demande POST en passant name dans le corps de la demande :

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

Notez que vous pouvez passer des requêtes GET depuis un navigateur en passant des données dans la chaîne de requêtes. Pour toutes les autres méthodes HTTP, vous devez utiliser cURL, Fiddler, Postman ou un outil de test HTTP similaire.

Fonctions non déclenchées via HTTP

Pour tous les types de fonctions autres que les déclencheurs, les Webhooks HTTP et les déclencheurs Event Grid, vous pouvez tester vos fonctions localement en appelant un point de terminaison d’administration. L’appel de ce point de terminaison au moyen d’une requête HTTP POST sur le serveur local déclenche la fonction.

Pour tester des fonctions Event Grid déclenchées localement, consultez Tests locaux avec une application web de visionneuse.

Vous pouvez éventuellement passer des données de test à l’exécution dans le corps de la requête POST. Cette fonctionnalité est similaire à l’onglet Test dans le portail Azure.

Vous appelez le point de terminaison d’administrateur suivant pour déclencher des fonctions non-HTTP :

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

Pour passer des données de test au point de terminaison d’administrateur d’une fonction, vous devez fournir les données dans le corps d’un message de requête POST. Le corps du message doit avoir le format JSON suivant :

{
    "input": "<trigger_input>"
}

La valeur de <trigger_input> contient des données dans un format attendu par la fonction. L’exemple cURL suivant est une demande POST adressée à une fonction QueueTriggerJS. Dans ce cas, l’entrée est une chaîne qui est équivalente au message attendu dans la file d’attente.

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

Utilisation de la commande func run dans la (version 1.x uniquement)

Important

La commande func run est uniquement prise en charge dans la version 1.x des outils. Pour plus d’informations, consultez la rubrique Comment cibler des versions du runtime Azure Functions.

Dans la version 1.x, vous pouvez également appeler une fonction directement à l’aide de func run <FunctionName> et fournir des données d’entrée pour la fonction. Cette commande est similaire à l’exécution d’une fonction à l’aide de l’onglet Test dans le portail Azure.

func run prend en charge les options suivantes :

Option Description
--content, -c Contenu inclus.
--debug, -d Joindre un débogueur au processus hôte avant d’exécuter la fonction.
--timeout, -t Délai d’attente (en secondes) jusqu’à ce que l’hôte Functions local soit prêt.
--file, -f Nom du fichier à utiliser en tant que contenu.
--no-interactive Ne pas demander d’entrée. Utile pour les scénarios d’automatisation.

Par exemple, pour appeler une fonction déclenchée par HTTP et passer un corps de contenu, exécutez la commande suivante :

func run MyHttpTrigger -c '{\"name\": \"Azure\"}'

Publication dans Azure

Azure Functions Core Tools prend en charge deux types de déploiement : le déploiement des fichiers projet de fonction directement dans votre application de fonction via Zip Deploy, et le déploiement d’un conteneur Docker personnalisé. Vous devez avoir déjà créé une application de fonction dans votre abonnement Azure où vous prévoyez de déployer votre code. Les projets qui nécessitent une compilation doivent être générés pour favoriser le déploiements des fichiers binaires.

Important

L’interface de ligne de commande Azure ou Azure PowerShell doit être installé localement pour que vous puissiez publier sur Azure à partir de Core Tools.

Un dossier de projet peut contenir des fichiers et des répertoires spécifiques à une langue qui ne doivent pas être publiés. Les éléments exclus sont listés dans un fichier .funcignore situé dans le dossier racine du projet.

Déployer des fichiers de projet

Pour publier votre code local dans une application de fonction sur Azure, utilisez la commande publish :

func azure functionapp publish <FunctionAppName>

Important

Java utilise Maven pour publier votre projet local sur Azure. Utilisez la commande suivante pour publier sur Azure : mvn azure-functions:deploy. Les ressources Azure sont créées lors du déploiement initial.

Cette commande publie du contenu vers une application de fonction existante dans Azure. Vous obtiendrez une erreur si vous tentez de publier sur une application <FunctionAppName> qui n’existe pas dans votre abonnement. Pour découvrir comment créer une application de fonction à partir de l’invite de commandes ou d’une fenêtre de terminal à l’aide d’Azure CLI ou d’Azure PowerShell, consultez Créer une application de fonction pour une exécution serverless. Par défaut, cette commande utilise la build distante et déploie votre application pour une exécution à partir du package de déploiement. Pour désactiver ce mode de déploiement recommandé, utilisez l'option --nozip.

Important

Lorsque vous créez une application de fonction dans le portail Azure, elle utilise par défaut la version 3.x du runtime de Function. Pour que l’application de fonction utilise la version 1.x du runtime, suivez les instructions dans Exécution sur la version 1.x. Vous ne pouvez pas modifier la version du runtime pour une application de fonction qui possède des fonctions déjà existantes.

Les options de publication suivantes s’appliquent à toutes les versions :

Option Description
--publish-local-settings -i Publier dans Azure les paramètres figurant dans local.settings.json, avec demande de confirmation du remplacement si le paramètre existe déjà. Si vous utilisez l’Émulateur de stockage Microsoft Azure, commencez par changer le paramètre d’application en choisissant une connexion de stockage réelle.
--overwrite-settings -y Supprimer l’invite de remplacement des paramètres de l’application lorsque --publish-local-settings -i est utilisé.

Les options de publication suivantes sont uniquement prises en charge dans la version 2.x et les versions ultérieures :

Option Description
--publish-settings-only, -o Publiez les paramètres uniquement et ignorez le contenu. Par défaut, l’accord de l’utilisateur est sollicité.
--list-ignored-files Affiche une liste de fichiers ignorés lors de la publication basée sur le fichier .funcignore.
--list-included-files Affiche une liste de fichiers publiés basée sur le fichier .funcignore.
--nozip Désactive le mode par défaut Run-From-Package.
--build-native-deps Ignore la génération du dossier .wheels lors de la publication des applications de fonction Python.
--build, -b Exécute l’action de génération lors du déploiement dans une application de fonction Linux. Accepte : remote et local.
--additional-packages Liste des packages à installer lors de la création des dépendances natives. Par exemple : python3-dev libevent-dev.
--force Ignorez la vérification de prépublication dans certains scénarios.
--csx Publiez un projet de Script C# (.csx).
--no-build Le projet n’est pas généré lors de la publication. Pour Python, pip install n’intervient pas.
--dotnet-cli-params Si les fonctions C# (.csproj) sont compilées lors de la publication, Core Tools appelle « dotnet build --output bin/publish ». Tous les paramètres transmis seront ajoutés à la ligne de commande.

Déployer un conteneur personnalisé

Azure Functions vous permet de déployer un projet de fonction dans un conteneur Docker personnalisé. Pour plus d’informations, consultez Créer une fonction sur Linux en utilisant une image personnalisée. Les conteneurs personnalisés doivent contenir un fichier Dockerfile. Pour créer une application avec un fichier Dockerfile, utilisez l’option --dockerfile sur func init.

func deploy

Les options de déploiement de conteneur personnalisées suivantes sont disponibles :

Option Description
--registry Le nom d’un registre Docker auquel l’utilisateur actuel est connecté.
--platform Plateforme d’hébergement pour l’application de fonction. Les options valides sont kubernetes
--name Nom de l’application de fonction.
--max Le cas échéant, définit le nombre maximal d’instances d’application de fonction à déployer.
--min Le cas échéant, définit le nombre minimal d’instances d’application de fonction à déployer.
--config Définit un fichier de configuration de déploiement optionnel.

Surveillance des fonctions

Il est recommandé de superviser l’exécution de vos fonctions par l’intégration à Azure Application Insights. Vous pouvez également diffuser des journaux d’exécution sur votre ordinateur local. Pour en savoir plus, consultez Surveiller l’exécution des fonctions Azure.

Intégration d’Application Insights

L’intégration d’Application Insights doit être activée lorsque vous créez votre application de fonction dans Azure. Si, pour une raison quelconque, votre application de fonction n’est pas connectée à une instance Application Insights, il est facile d’effectuer cette intégration dans le portail Azure. Pour en savoir plus, consultez Activer l'intégration d'Application Insights.

Activer les journaux de diffusion en continu

Vous pouvez afficher un flux de fichiers journaux générés par vos fonctions dans une session de ligne de commande sur votre ordinateur local.

Streaming des journaux intégré

Utilisez l’option logstream pour commencer à recevoir les journaux de streaming d’une application de fonction s’exécutant dans Azure, comme dans l’exemple suivant :

func azure functionapp logstream <FunctionAppName>

Notes

Le streaming de journaux intégré n’est pas encore activé dans Core Tools pour les applications de fonction s’exécutant sur Linux dans le cadre d’un plan Consommation. Pour ces plans d’hébergement, vous devez utiliser Flux de métriques temps réel pour voir les journaux en quasi-temps réel.

Live Metrics Stream (Flux continu de mesures)

Vous pouvez voir le Flux de métriques temps réel de votre application de fonction dans une nouvelle fenêtre de navigateur en incluant l’option --browser, comme dans l’exemple suivant :

func azure functionapp logstream <FunctionAppName> --browser

Les journaux de diffusion en continu de ce type nécessitent que l’intégration d’Application Insights soit activée pour votre application de fonction.

Étapes suivantes

Découvrez comment développer, tester et publier des fonctions Azure en utilisant Azure Functions Core Tools module Microsoft Learn. Azure Functions Core Tools est open source et hébergé sur GitHub.
Pour enregistrer un bogue ou une demande de fonctionnalité, créez un problème GitHub.