Guide du développeur Azure Functions

Dans Azure Functions, toutes les fonctions partagent certains concepts et composants techniques de base, quel que soit votre langage ou environnement de développement. Cet article est spécifique au langage. Sélectionnez votre langage de développement préféré en haut de l'article.

Cet article suppose que vous avez déjà lu la Présentation d’Azure Functions.

Projet de code

Au cœur d'Azure Functions se trouve un projet de code spécifique au langage qui implémente une ou plusieurs unités d'exécution de code appelées fonctions. Les fonctions sont simplement des méthodes qui s'exécutent dans le cloud Azure en fonction d'événements, en réponse à des requêtes HTTP ou selon une planification. Considérez votre projet de code Azure Functions comme un mécanisme d'organisation, de déploiement et de gestion collective de vos fonctions individuelles dans le projet lorsqu'elles s'exécutent dans Azure. Pour plus d'informations, reportez-vous à Organiser vos fonctions.

Toutes les fonctions doivent avoir un déclencheur, qui définit la façon dont la fonction démarre et peut fournir une entrée à la fonction. Vos fonctions peuvent éventuellement définir des liaisons d'entrée et de sortie. Ces liaisons simplifient les connexions à d'autres services sans que vous ayez à travailler avec des kits SDK clients. Pour plus d’informations, consultez Concepts des déclencheurs et liaisons Azure Functions.

Azure Functions fournit un ensemble de modèles de projets et de fonctions spécifiques au langage qui facilitent la création de projets de code et l'ajout de fonctions à votre projet. Vous pouvez utiliser n'importe quel outil qui prend en charge le développement Azure Functions pour générer de nouvelles applications et fonctions à l'aide de ces modèles.

Outils de développement

Les outils suivants assurent une expérience de développement et de publication intégrée pour Azure Functions dans votre langage préféré :

• Visual Studio Code

• Azure Functions Core Tools (invite de commandes)

Ces outils s'intègrent à Azure Functions Core Tools afin que vous puissiez exécuter et déboguer sur votre ordinateur local à l'aide du runtime Functions. Pour plus d’informations, consultez Coder et tester Azure Functions localement.

Déploiement

Lorsque vous publiez votre projet de code sur Azure, vous déployez essentiellement votre projet sur une ressource d'application de fonction existante. Une application de fonction fournit un contexte d’exécution dans Azure dans lequel vos fonctions s’exécutent. À ce titre, elle constitue l’unité de déploiement et de gestion de vos fonctions. Du point de vue des ressources Azure, une application de fonction équivaut à une ressource de site (Microsoft.Web/sites) dans Azure App Service, ce qui équivaut à une application Web.

Une application de fonction est constitué d’une ou de plusieurs des fonctions individuelles qui sont gérées, déployées et mises à l’échelle ensemble. Toutes les fonctions d'une application de fonction partagent le même plan de tarification, la même méthode de déploiement et la même version du runtime. Pour plus d'informations, reportez-vous à Comment gérer une application de fonction.

Lorsque l'application de fonction et toutes les autres ressources requises n'existent pas encore dans Azure, vous devez d'abord créer ces ressources avant de pouvoir déployer vos fichiers projet. Vous pouvez créer ces ressources de l'une des manières suivantes :

• Utilisation de Visual Studio Code

• Par programmation à l'aide d'Azure CLI, d'Azure PowerShell, de modèles ARM ou de modèles Bicep

• Dans le portail Azure :

En plus de la publication basée sur des outils, Functions prend en charge d'autres technologies pour le déploiement du code source sur une application de fonction existante. Pour plus d’informations, consultez Technologies de déploiement dans Azure Functions.

Se connecter aux services

Une exigence majeure de tout service de calcul basé sur le cloud est la lecture et l'écriture de données vers d'autres services cloud. Functions fournit un ensemble complet de liaisons qui vous permet de vous connecter plus facilement aux services sans avoir à travailler avec des kits SDK clients.

Que vous utilisiez les extensions de liaison fournies par Functions ou que vous utilisiez directement des kits SDK clients, vous stockez en toute sécurité les données de connexion et ne les incluez pas dans votre code. Pour plus d’informations, consultez Connexions.

Liaisons

Functions fournit des liaisons pour de nombreux services Azure et quelques services tiers, qui sont implémentés en tant qu'extensions. Pour plus d'informations, reportez-vous à la liste complète des liaisons prises en charge.

Les extensions de liaison peuvent prendre en charge les entrées et les sorties ; de nombreux déclencheurs font également office de liaisons d'entrée. Les liaisons vous permettent de configurer la connexion aux services afin que l'hôte Functions puisse gérer l'accès aux données à votre place. Pour plus d’informations, consultez Concepts des déclencheurs et liaisons Azure Functions.

Si vous rencontrez des problèmes avec des erreurs provenant de liaisons, reportez-vous à la documentation Codes d'erreur de liaison Azure Functions.

Kits de développement logiciel (SDK) client

Bien que Functions fournisse des liaisons pour simplifier l'accès aux données dans votre code de fonction, vous pouvez toujours utiliser un kit de développement logiciel (SDK) client dans votre projet pour accéder directement à un service donné, si vous préférez. Vous devrez peut-être utiliser directement les kits SDK clients si vos fonctions nécessitent une fonctionnalité du kit SDK sous-jacent qui n'est pas prise en charge par l'extension de liaison.

Lorsque vous utilisez des kits SDK clients, vous devez utiliser le même processus pour stocker et accéder aux chaînes de connexion que celui utilisé par les extensions de liaison.

Connexions

Une bonne pratique de sécurité Azure Functions consiste à tirer parti des fonctionnalités des paramètres d'application d'Azure App Service pour vous aider à stocker de manière plus sécurisée les chaînes, clés et autres jetons nécessaires pour vous connecter à d'autres services. Les paramètres d’application dans Azure sont stockés sous forme chiffrée et sont accessibles au moment de l’exécution par votre application en tant que paires de variables d’environnement name value. Pour les déclencheurs et les liaisons qui nécessitent une propriété de connexion, vous définissez le nom du paramètre d'application au lieu de la chaîne de connexion réelle. Vous ne pouvez pas configurer une liaison directement avec une chaîne de connexion ou une clé.

Par exemple, considérez une définition de déclencheur qui a une propriété connection. Au lieu de la chaîne de connexion, vous définissez connection comme le nom d'une variable d'environnement qui contient la chaîne de connexion. L'utilisation de cette stratégie d'accès aux secrets rend vos applications plus sécurisées et facilite la modification des connexions entre les environnements. Pour encore plus de sécurité, vous pouvez utiliser des connexions basées sur l'identité.

Le fournisseur de configuration par défaut utilise des variables d’environnement. Ces variables sont définies dans les paramètres d'application lors de l'exécution dans Azure et dans le fichier de paramètres locaux lors du développement local.

Valeurs de connexion

Quand le nom de la connexion correspond à une seule valeur exacte, le runtime identifie la valeur en tant que chaîne de connexion, qui comprend généralement un secret. Les détails d'une chaîne de connexion dépendent du service auquel vous souhaitez vous connecter.

Toutefois, un nom de connexion peut également faire référence à un ensemble de plusieurs éléments de configuration, utiles pour la configuration des connexions basées sur l’identité. Les variables d’environnement peuvent être traitées comme une collection à l’aide d’un préfixe partagé qui se termine par deux traits de soulignement __. Il est ensuite possible de référencer le groupe en définissant le nom de la connexion sur ce préfixe.

Par exemple, la propriété connection pour une définition de déclencheur de blobs Azure peut être Storage1. Tant qu’aucune valeur de chaîne unique n’est configurée par une variable d’environnement nommée Storage1, une variable d’environnement nommée Storage1__blobServiceUri peut être utilisée pour informer la propriété blobServiceUri de la connexion. Les propriétés de connexion sont différentes pour chaque service. Reportez-vous à la documentation du composant qui utilise la connexion.

Configurer une connexion basée sur une identité

Dans Azure Functions, certaines connexions peuvent être configurées pour utiliser une identité plutôt qu’un secret. La prise en charge dépend de la version du runtime et de l’extension qui utilise la connexion. Dans certains cas, une chaîne de connexion peut toujours être nécessaire dans Functions, même si le service auquel vous vous connectez prend en charge les connexions basées sur une identité. Pour obtenir un tutoriel sur la configuration de vos applications de fonction avec des identités managées, consultez le tutoriel sur la création d’une application de fonction avec des connexions basées sur l’identité.

Les connexions basées sur l’identité sont uniquement prises en charge sur Functions 4.x. Si vous utilisez la version 1.x, vous devez d’abord migrer vers la version 4.x.

Les composants suivants prennent en charge les connexions basées sur l’identité :

Quand elles sont hébergées dans le service Azure Functions, les connexions basées sur une identité utilisent une identité managée. L’identité attribuée par le système est utilisée par défaut, bien qu’une identité attribuée par l’utilisateur puisse être spécifiée avec les propriétés credential et clientID. Notez que la configuration d’une identité affectée par l’utilisateur avec un ID de ressource n’est pas prise en charge. Lors d’une exécution dans d’autres contextes, tels que le développement local, votre identité de développeur est utilisée à la place, même si cela peut être personnalisé. Consultez Développement local avec connexions basées sur une identité.

Accorder l’autorisation à l’identité

Quelle que soit l’identité utilisée, elle doit avoir les autorisations nécessaires pour effectuer les actions prévues. Pour la plupart des services Azure, cela signifie que vous devez attribuer un rôle dans Azure RBAC en utilisant des rôles intégrés ou personnalisés qui fournissent ces autorisations.

Choisissez l'un de ces onglets pour en savoir plus sur les autorisations pour chaque composant :

Propriétés courantes pour les connexions basées sur une identité

Une connexion basée sur une identité pour un service Azure accepte les propriétés courantes suivantes, où <CONNECTION_NAME_PREFIX> est la valeur de votre propriété connection dans la définition de déclencheur ou de liaison :

D'autres options peuvent être prises en charge pour un type de connexion donné. Reportez-vous à la documentation du composant qui effectue la connexion.

Variables d’environnement du kit Azure SDK

Les variables d’environnement associées à EnvironmentCredential du kit Azure SDK peuvent également être définies, mais elles ne sont pas traitées par le service Functions pour la mise à l’échelle dans les plans Consommation. Ces variables d’environnement ne sont pas spécifiques à une connexion et s’appliquent par défaut, sauf si une propriété correspondante n’est pas définie pour une connexion donnée. Par exemple, si AZURE_CLIENT_ID était défini, il serait utilisé comme si <CONNECTION_NAME_PREFIX>__clientId avait été configuré. La définition explicite de <CONNECTION_NAME_PREFIX>__clientId remplacerait cette valeur par défaut.

Développement local avec connexions basées sur une identité

Lorsque vous exécutez un projet de fonction localement, la configuration ci-dessus indique au runtime d’utiliser votre identité de développeur locale. La connexion tente d’obtenir un jeton à partir des emplacements suivants, dans l’ordre :

• Un cache local partagé entre les applications Microsoft
• Le contexte utilisateur actuel dans Visual Studio
• Le contexte utilisateur actuel dans Visual Studio Code
• Le contexte utilisateur actuel dans Azure CLI

Si aucune de ces options ne fonctionne, une erreur se produit.

Votre identité a peut-être déjà des attributions de rôles pour les ressources Azure utilisées pour le développement, mais ces rôles peuvent ne pas fournir l’accès aux données nécessaire. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Revérifiez quelles autorisations sont nécessaires pour les connexions de chaque composant et vérifiez qu’elles vous sont affectées.

Dans certains cas, vous souhaiterez peut-être spécifier l’utilisation d’une identité différente. Pour la connexion, vous pouvez ajouter des propriétés de configuration qui pointent vers l’identité de substitution en fonction d’un ID client et d’un secret client pour un principal de service Microsoft Entra. Cette option de configuration n’est pas prise en charge quand elle est hébergée dans le service Azure Functions. Pour utiliser un ID et un secret sur votre ordinateur local, définissez la connexion avec les propriétés extra suivantes :

Voici un exemple de propriétés local.settings.json obligatoires pour une connexion à des objets blob Azure basée sur l’identité :

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Connexion au stockage hôte avec une identité

L’hôte Azure Functions utilise l’ensemble de connexions au stockage dans AzureWebJobsStorage pour les comportements de base comme la coordination de l’exécution unique de déclencheurs de minuteur et du stockage de clés d’application par défaut. Cette connexion peut également être configurée pour utiliser une identité.

Pour utiliser une connexion basée sur l’identité pour AzureWebJobsStorage, configurez les paramètres d’application suivants :

Il est également possible de définir des propriétés courantes pour les connexions basées sur une identité.

Si vous configurez un compte de stockage AzureWebJobsStorage qui utilise le suffixe DNS et le nom de service par défaut pour Azure global, en respectant le format https://<accountName>.[blob|queue|file|table].core.windows.net, vous pouvez à la place définir AzureWebJobsStorage__accountName sur le nom de votre compte de stockage. Les points de terminaison de chaque service de stockage sont déduits pour ce compte. Cette inférence ne fonctionne quand le compte de stockage se trouve dans un cloud souverain ou s'il a un DNS (Domain Name System) personnalisé.

Vous devrez créer une attribution de rôle qui fournit l’accès au compte de stockage pour « AzureWebJobsStorage » au moment de l’exécution. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Le rôle Propriétaire des données Blob du stockage couvre les besoins de base du stockage d’hôtes de fonctions - L’accès en lecture et en écriture aux objets blob et la capacité à créer des conteneurs sont nécessaires pour l’exécution. Plusieurs extensions utilisent cette connexion comme emplacement par défaut pour les blobs, les files d’attente et les tables, et ces utilisations peuvent ajouter des exigences, comme indiqué dans le tableau ci-dessous. Vous pouvez avoir besoin d’autorisations supplémentaires si vous utilisez « AzureWebJobsStorage » à d’autres fins.

Problèmes liés aux rapports

Référentiels open source

Le code d'Azure Functions est open source ; vous pouvez trouver des composants clés dans ces référentiels GitHub :

• Azure Functions

• Hôte Azure Functions

• Portail Azure Functions

• Modèles Azure Functions

• Kit de développement logiciel Azure WebJobs

• Extensions du kit de développement logiciel Azure WebJobs

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :

• Scénarios Azure Functions
• Coder et tester Azure Functions localement
• Meilleures pratiques pour Azure Functions