Partager via

Coder et tester Azure Functions localement

  • Article

Bien qu’il soit possible de développer et tester Azure Functions dans le Azure portal, de nombreux développeurs préfèrent une expérience de développement local. Lorsque vous utilisez Functions, il devient plus facile d’utiliser votre éditeur de code et vos outils de développement préférés pour développer et tester des fonctions sur votre ordinateur local. Vos fonctions locales peuvent être connectées aux services Azure actifs, et vous pouvez les déboguer sur votre ordinateur local à l’aide du runtime Functions complet.

Cet article fournit des liens vers des environnements de développement spécifiques pour votre langage par défaut. Il fournit également des conseils partagés pour le développement local, comme l’utilisation du fichier local.settings.json.

Environnements de développement local

La façon dont vous développez des fonctions sur votre ordinateur local dépend de votre langage et de vos préférences d’outils. Les environnements du tableau suivant prennent en charge le développement local :

Environnement Languages Description
Visual Studio Code C# (in-process)
C# (processus Worker isolé)
JavaScript
PowerShell
Python		 L’extension Azure Functions pour VS Code ajoute la prise en charge de Functions à VS Code. Requiert les outils de base. Prend en charge le développement sur Linux, macOS et Windows, lorsque vous utilisez la version 2.x des outils de base. Pour en savoir plus, voir Créer votre première fonction à l’aide de Visual Studio Code.
Invite de commandes terminal C# (in-process)
C# (processus Worker isolé)
JavaScript
PowerShell
Python		 Azure Functions Core Tools fournit le runtime et les modèles principaux de création de fonctions, ce qui permet le développement local. La version 2.x prend en charge le développement sur Linux, macOS et Windows. Tous les environnements s’appuient sur les outils de base pour le runtime Functions local.
Visual Studio C# (in-process)
C# (processus Worker isolé)		 Les outils Azure Functions sont inclus dans la charge de travail de développement Azure de Visual Studio, à partir de Visual Studio 2019. Vous permet de compiler les fonctions dans une bibliothèque de classes et de publier le fichier .dll dans Azure. Inclut les principaux outils pour effectuer des test en local. Pour en savoir plus, voir Développer Azure Functions à l’aide de Visual Studio.
Maven (divers) Java L’archétype Maven prend en charge les outils de base pour permettre le développement de fonctions Java. La version 2.x prend en charge le développement sur Linux, macOS et Windows. Pour en savoir plus, consultez Créer votre première fonction dans Azure avec Java et Maven. Prend également en charge le développement à l’aide d’Eclipse et d’IntelliJ IDEA.

Remarque

En raison des limitations liées à la modification du code de fonction dans le portail Azure, vous devez développer vos fonctions localement et publier votre projet de code dans une application de fonction dans Azure. Pour plus d’informations, consultez la section Limitations de développement dans le portail Azure.

Chacun de ces environnements de développement local vous permet de créer des projets d’application de fonction et d’utiliser des modèles de fonctions prédéfinis pour créer de nouvelles fonctions. Ils intègrent les outils principaux afin que vous puissiez tester et déboguer vos fonctions selon le runtime Functions réel sur votre propre ordinateur comme vous le feriez pour toute autre application. Vous pouvez également publier votre projet d’application de fonction à partir d’un de ces environnements sur Azure.

Fichiers projet locaux

Un répertoire de projet Functions contient les fichiers suivants dans le dossier racine du projet, quel que soit le langage :

Nom de fichier Description
host.json Pour plus d’informations, consultez la référence host.json.
local.settings.json Paramètres utilisé par les outils de base lors de l’exécution locale, y compris les paramètres de l’application. Pour plus d’informations, consultez le fichier de paramètres locaux.
.gitignore Empêche la publication accidentelle du fichier local.settings.json dans un référentiel Git. Pour plus d’informations, consultez le fichier de paramètres locaux.
.vscode\extensions.json Fichier de paramètres utilisé lors de l’ouverture du dossier du projet dans Visual Studio Code.

Les autres fichiers du projet dépendent de votre langage et des fonctions spécifiques. Pour plus d’informations, consultez le guide du développeur pour votre langage.

Fichier de paramètres locaux

Le fichier local.settings.json stocke des paramètres d’application 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écutez votre projet localement. Lorsque vous publiez votre projet sur Azure, veillez également à ajouter tous les paramètres requis aux paramètres de l’application pour l’application de fonction.

Important

Étant donné que le fichier local.settings.json peut contenir des secrets, comme des chaînes de connexion, vous ne devez jamais le stocker dans un référentiel à distance. Les outils qui prennent en charge Functions permettent de synchroniser les paramètres du fichier local.settings.json avec les paramètres d’application dans l’application de fonction où votre projet est déployé.

Le fichier de paramètres locaux possède la structure suivante :

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

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 Collection de paramètres d’application utilisés lorsqu’un projet est exécuté localement. 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 Connection. 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 des paramètres ne peuvent pas contenir de trait de soulignement double (__) ou de signe deux points (:). 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. Elle autorise les demandes 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 ConnectionStrings. 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 SqlConnection 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 Azurite localement et définissez AzureWebJobsStorage sur UseDevelopmentStorage=true, Core Tools utilise l’émulateur. Pour plus d’informations, consultez Émulateur de stockage local.
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
dotnet-isolated
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 qu’il faut utiliser PowerShell 7 lors de l’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. La version du runtime PowerShell est déterminée par le paramètre de configuration du site powerShellVersion, en cas d’exécution dans Azure, qui peut être défini dans le portail.

Synchroniser les paramètres

Lorsque vous développez vos fonctions localement, tous les paramètres locaux requis par votre application doivent également être présents dans les paramètres d’application de l’application de fonction sur laquelle votre code est déployé. Vous devrez peut-être également télécharger les paramètres actuels à partir de l’application de fonction dans votre projet local. Bien que vous puissiez configurer manuellement les paramètres d’application dans le portail Azure, les outils suivants vous permettent également de synchroniser les paramètres d’application avec les paramètres locaux de votre projet :

Déclencheurs et liaisons

Lorsque vous développez vos fonctions localement, vous devez prendre en compte les comportements de déclenchement et de liaison. Pour des déclencheurs HTTP, vous pouvez simplement appeler le point de terminaison HTTP sur l’ordinateur local à l’aide de http://localhost/. Pour les fonctions non déclenchées par HTTP, de nombreuses options à exécuter localement existent :

  • Le moyen le plus simple de tester des liaisons pendant le développement local consiste à utiliser des chaînes de connexion qui ciblent les services Azure en direct. Vous pouvez cibler les services en direct en ajoutant les paramètres de chaîne de connexion appropriés dans le tableau Values du fichier local.settings.json. Dans ce cas, les exécutions locales effectuées pendant les tests impacteront les données du service en direct. Pour cette raison, nous vous conseillons de configurer des services distincts pour le développement et pour les tests, puis de basculer vers d’autres services pendant la production.
  • Pour les déclencheurs basés sur le stockage, vous pouvez utiliser un émulateur de stockage local.
  • Vous pouvez exécuter manuellement des fonctions de déclencheur non HTTP au moyen de points de terminaison spéciaux d’administrateur. Pour plus d’informations, consultez Exécuter manuellement une fonction non déclenchée par HTTP.

Pendant les tests locaux, vous devez exécuter localement l’hôte fourni par Core Tools (func.exe). Pour plus d’informations, consultez Azure Functions Core Tools.

Outils de test HTTP

Pendant le développement, il est facile d’appeler l’un de vos points de terminaison de fonction depuis un navigateur web quand ils prennent en charge la méthode HTTP GET. Cependant, pour d’autres méthodes HTTP qui prennent en charge des charges utiles, comme POST ou PUT, vous devez utiliser un outil de test HTTP pour créer et envoyer ces requêtes HTTP à vos points de terminaison de fonction.

Attention

Pour les scénarios où vos requêtes doivent inclure des données sensibles, veillez à utiliser un outil qui protège vos données et réduit le risque d’exposition des données sensibles au public. Les données sensibles que vous devez protéger peuvent inclure les informations d’identification, les secrets, les jetons d’accès, les clés API, les données de géolocalisation et même les informations d’identification personnelle (PII).

Vous pouvez sécuriser vos données en choisissant un outil de test HTTP qui fonctionne hors connexion ou localement, ne synchronise pas vos données sur le cloud et ne nécessite pas de vous connecter à un compte en ligne. Certains outils peuvent également protéger vos données contre une exposition accidentelle en implémentant des fonctionnalités de sécurité spécifiques.

Évitez d’utiliser des outils qui stockent de façon centralisée votre historique des requêtes HTTP (y compris les informations sensibles), qui ne respectent pas les meilleures pratiques de sécurité ou qui ne respectent pas les impératifs de confidentialité des données.

Envisagez d’utiliser un de ces outils pour envoyer de façon sécurisée des requêtes HTTP à vos points de terminaison de fonction :

Émulateur de stockage local

Pendant le développement local, vous pouvez utiliser l’émulateur Azurite local pour tester les fonctions avec des liaisons du Stockage Azure (Stockage File d’attente, Stockage Blob et Stockage Table), sans avoir à vous connecter aux services de stockage distants. Azurite s’intègre à Visual Studio Code et Visual Studio. Vous pouvez également l’exécuter à partir de l’invite de commandes, à l’aide de npm. Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Le paramètre suivant de la collection Values du fichier local.settings.json indique à l’hôte Functions local d’utiliser Azurite pour la connexion AzureWebJobsStorage par défaut :

"AzureWebJobsStorage": "UseDevelopmentStorage=true"

Avec cette valeur de paramètre, tous les déclencheurs et les liaisons du Stockage Azure qui utilisent AzureWebJobsStorage comme connexion se connecteront à Azurite lors de l’exécution locale. Gardez les considérations ci-dessous à l’esprit lors de l’utilisation de l’émulation de stockage pendant l’exécution locale :

  • Azurite doit être installé et en cours d’exécution.
  • Vous devez effectuer un test avec une connexion de stockage réelle aux services Azure avant de publier sur Azure.
  • Lorsque vous publiez votre projet, ne publiez pas le paramètre AzureWebJobsStorage en tant que UseDevelopmentStorage=true. Dans Azure, le paramètre AzureWebJobsStorage doit toujours être la chaîne de connexion du compte de stockage utilisé par votre application de fonction. Pour plus d’informations, consultez AzureWebJobsStorage.

Étapes suivantes