Vue d’ensemble des versions du runtime Azure Functions

Azure Functions prend en charge trois versions de l’hôte du runtime : 3.x, 2.x et 1.x. Les trois versions sont prises en charge pour les scénarios de production.

Important

La version 1.x est en mode maintenance et ne prend en charge que le développement dans le Portail Azure, dans le portail Azure Stack Hub ou localement sur des ordinateurs Windows. Les améliorations sont fournies uniquement dans les versions ultérieures.

Cet article explique en détail certaines différences existant entre les versions, comment vous pouvez créer chaque version et comment les modifier.

Languages

À compter de la version 2.x, le runtime utilise un modèle d’extensibilité de langage, et toutes les fonctions d’une application de fonction doivent partager le même langage. Le langage des fonctions d’une application de fonction est choisi au moment de la création de l’application, et est conservé dans le paramètre FUNCTIONS_WORKER_RUNTIME.

Le tableau suivant montre les langages de programmation actuellement pris en charge dans chaque version du runtime.

Langage 1.x 2.x 3.x
C# Disponibilité générale (.NET Framework 4.7) GA (.NET Core 2.21) Disponibilité générale (.NET Core 3.1)
Préversion (.NET 5.0)
JavaScript Disponibilité générale (Nœud 6) Disponibilité générale (Nœuds 10 et 8) Disponibilité générale (Nœuds 14, 12 et 10)
F# Disponibilité générale (.NET Framework 4.7) GA (.NET Core 2.21) Disponibilité générale (.NET Core 3.1)
Java N/A Disponibilité générale (Java 8) GA (Java 11 et 8)
PowerShell N/A GA (PowerShell Core 6) Disponibilité générale (PowerShell 7 et Core 6)
Python N/A Disponibilité générale (Python 3.7 et 3.6) Disponibilité générale (Python 3.8, 3.7 et 3.6)
Préversion (Python 3.9)
TypeScript N/A Disponibilité générale2 Disponibilité générale2

1 Les applications de bibliothèque de classes .NET qui ciblent le runtime version 2.x peuvent désormais être exécutées sur .NET Core 3.1 en mode de compatibilité .NET Core 2.x. Pour plus d’informations, consultez Considérations relatives à Functions v2.x.
2 Prise en charge via la transpilation vers JavaScript.

Pour plus d’informations sur les versions linguistiques prises en charge, consultez l’article du Guide du développeur spécifique à une langue.
Pour plus d’informations sur les modifications prévues sur la prise en charge des langages, consultez la Feuille de route Azure.

Exécuter sur une version spécifique

Par défaut, les applications de fonction créées dans le portail Azure et par l’interface Azure CLI sont configurées pour la version 3.x. Vous pouvez modifier cette version en fonction de vos besoins. Vous pouvez repasser à la version 1.x du runtime seulement après avoir créé votre application de fonction et avant d’ajouter des fonctions. Le passage de la version 2.x à la version 3.x est autorisé, même avec les applications qui contiennent déjà des fonctions. Avant de faire passer une application qui comprend des fonctions de la version 2.x à la version 3.x, tenez compte des changements cassants qui ont été effectués entre les versions 2.x et 3.x.

Avant d’apporter une modification à la version principale du runtime, vous devez d’abord tester votre code en le déployant sur une autre application de fonction qui s’exécute sur la dernière version principale. Ce test permet de vérifier que le code s’exécute correctement après la mise à niveau.

Le passage de la version v3.x à la version v2.x n’est pas pris en charge. Lorsque cela est possible, vous devez toujours exécuter vos applications sur la dernière version prise en charge du runtime Functions.

Changement de la version des applications dans Azure

La version du runtime Functions utilisée par les applications publiées dans Azure dépend du paramètre d’application FUNCTIONS_EXTENSION_VERSION. Les valeurs des versions majeures du runtime suivantes sont prises en charge :

Valeur Cible du runtime
~3 3.x
~2 2.x
~1 1.x

Important

Ne modifiez pas arbitrairement ce paramètre, car d’autres modifications des paramètres de l’application et d’autres modifications du code dans vos fonctions peuvent être nécessaires.

Pour en savoir plus, voir Comment cibler des versions du runtime Azure Functions.

Épinglage sur une version mineure spécifique

Pour résoudre les problèmes liés à l’exécution de votre application de fonction sur la version principale la plus récente, vous devez épingler votre application à une version mineure spécifique. Cela vous donne le temps de faire le nécessaire pour que votre application s’exécute correctement sur la dernière version majeure. La façon dont vous épinglez l’application à une version mineure n’est pas la même dans Windows et dans Linux. Pour en savoir plus, voir Comment cibler des versions du runtime Azure Functions.

Les versions mineures les plus anciennes sont régulièrement supprimées de Functions. Pour obtenir les dernières informations sur les versions Azure Functions, notamment sur la suppression des versions mineures les plus anciennes, surveillez les annonces Azure App Service.

Épinglage sur la version ~2.0

Les applications de fonction .NET qui sont exécutées sur la version 2.x (~2) sont automatiquement mises à niveau pour s’exécuter sur .NET Core 3.1, qui est une version de .NET Core 3 avec prise en charge à long terme. En exécutant vos fonctions .NET sur .NET Core 3.1, vous pouvez tirer parti des dernières mises à jour de sécurité et améliorations produit.

Les applications de fonction épinglées à ~2.0 continuent de s’exécuter sur .NET Core 2.2, qui ne reçoit plus de mises à jour de sécurité ni aucune autre mise à jour. Pour plus d’informations, consultez Considérations relatives à Functions v2.x.

Migration de 2.x vers 3.x

Azure Functions version 3.x offre une compatibilité descendante forte avec la version 2.x. De nombreuses applications doivent normalement être mise à niveau sans problème vers 3.x, sans aucune modification du code. Si le passage à 3. x est encouragé, veillez néanmoins à effectuer des tests intensifs avant de changer la version majeure dans les applications de production.

Changements cassants entre 2.x et 3.x

Voici les changements à prendre en considération avant de mettre à niveau une application 2.x vers 3.x.

JavaScript

  • Les liaisons de sortie affectées via context.done ou des valeurs de retour se comportent désormais de la même façon qu’une définition dans context.bindings.

  • L’objet de déclencheur de minuteur est en casse mixte au lieu de la casse Pascal

  • Les fonctions déclenchées par Event Hub avec un dataType binaire reçoivent un tableau de binary au lieu d’un tableau de string.

  • La charge utile des requêtes HTTP n’est plus accessible via context.bindingData.req. Elle néanmoins toujours accessible en tant que paramètre d’entrée, context.req, et dans context.bindings.

  • Node.js 8 n’est plus pris en charge et ne s’exécute pas dans les fonctions 3.x.

.NET Core

Lorsque vous exécutez des fonctions de la bibliothèque de classes .NET, la principale différence entre les versions se trouve au niveau du runtime .NET Core. Functions version 2.x est conçu pour s’exécuter sur .NET Core 2.2, et la version 3.x est conçue pour s’exécuter sur .NET Core 3.1.

Notes

En raison des problèmes de prise en charge de .NET Core 2.2, les applications de fonction épinglées à la version 2 (~2) s’exécutent essentiellement sur .NET Core 3.1. Pour plus d’informations, consultez Mode de compatibilité Functions v2.x.

Migration de la version 1.x vers les versions ultérieures

Vous pouvez choisir de migrer une application existante écrite pour utiliser la version 1.x du runtime pour qu’elle utilise à la place une version plus récente. La plupart des modifications que vous devez apporter sont liées au runtime du langage, par exemple des modifications de l’API C# entre .NET Framework 4.7 et .NET Core. Vous devez également vous assurer que le code et les bibliothèques sont compatibles avec le runtime de langage choisi. Enfin, veillez à noter toutes les modifications soulignées ci-après qui affectent les déclencheurs, liaisons et fonctionnalités. Pour une migration plus performante, vous devez créer une application de fonction dans une nouvelle version et porter le code de la fonction existante en version 1.x vers la nouvelle application.

Bien qu’il soit possible de procéder à une mise à niveau « sur place » en mettant à jour manuellement la configuration de l’application, passer de la version 1.x à une version ultérieure implique certains changements cassants. Par exemple, en C#, l’objet de débogage passe de TraceWriter à ILogger. Quand vous créez un projet en version 3.x, vous commencez par des fonctions mises à jour basées sur les modèles de version 3.x les plus récents.

Changements dans les déclencheurs et les liaisons après la version 1.x

À compter de la version 2.x, vous devez installer dans votre application les extensions pour les déclencheurs et les liaisons spécifiques utilisés par les fonctions. La seule exception concerne les déclencheurs HTTP et de la minuterie, qui ne nécessitent aucune extension. Pour plus d’informations, voir Inscrire et installer des extensions de liaison.

Il convient également de noter quelques modifications dans function.json ou dans les attributs de la fonction entre les versions. Par exemple, la propriété path d’Event Hub est désormais eventHubName. Consultez le tableau des liaisons existantes. Il contient des liens vers de la documentation sur chaque liaison.

Changements apportés aux fonctionnalités après la version 1.x

Quelques fonctionnalités ont été supprimées, mises à jour ou remplacées après la version 1.x. Cette section détaille les changements que vous voyez dans les versions ultérieures après avoir utilisé la version 1.x.

Les modifications suivantes ont été apportées à la version 2.x :

  • Les clés permettant d’appeler les points de terminaison HTTP sont toujours stockées et chiffrées dans le Stockage Blob Azure. Dans la version 1.x, les clés étaient stockées par défaut dans le Stockage Fichier Azure. Au moment de mettre à niveau une application de la version 1.x à la version 2.x, les secrets existants qui se trouvent dans le Stockage Fichier sont réinitialisés.

  • La version 2.x du runtime n’intègre aucune prise en charge des fournisseurs de webhooks. Cette modification a été apportée pour améliorer les performances. Vous pouvez continuer à utiliser des déclencheurs HTTP comme points de terminaison des webhooks.

  • Le fichier de configuration d’hôte (host.json) doit être vide ou contenir la chaîne "version": "2.0".

  • Pour améliorer la surveillance, le tableau de bord WebJobs se trouvant dans le portail, qui a utilisé le paramètre AzureWebJobsDashboard, est remplacé par Azure Application Insights, qui utilise le paramètre APPINSIGHTS_INSTRUMENTATIONKEY. Pour plus d’informations, consultez Surveiller l’exécution des fonctions Azure.

  • Toutes les fonctions d’une application de fonction doivent partager le même langage. Lorsque vous créez une application de fonction, vous devez choisir une pile d’exécution pour l’application. La pile d’exécution est spécifiée par la valeur FUNCTIONS_WORKER_RUNTIME dans les paramètres de l’application. Cette exigence a été ajoutée pour améliorer l’empreinte mémoire et le temps de démarrage. Lorsque vous développez en local, vous devez également inclure ce paramètre dans le fichier local.settings.json.

  • Le délai d’expiration par défaut pour les fonctions dans un plan App Service est de 30 minutes. Vous pouvez modifier ce délai d’expiration manuellement et l’indiquer à nouveau comme étant illimité en utilisant le paramètre functionTimeout dans host.json.

  • Les limitations d’accès concurrentiel HTTP sont implémentées par défaut pour les fonctions de plan Consommation, avec une valeur par défaut de 100 requêtes simultanées par instance. Vous pouvez configurer ces limitations dans le paramètre maxConcurrentRequests du fichier host.json.

  • En raison des limitations de .NET Core, la prise en charge des fonctions de script F# (.fsx) a été supprimée. Les fonctions F# compilées (.fs) restent prises en charge.

  • Le format d’URL des webhooks de déclencheur Event Grid a été remplacé par https://{app}/runtime/webhooks/{triggerName}.

Versions d’une application développée en local

Vous pouvez effectuer les mises à jour suivantes sur les applications de fonction afin de changer localement les versions ciblées.

Versions du runtime Visual Studio

Dans Visual Studio, vous sélectionnez la version du runtime au moment de créer un projet. Azure Functions Tools pour Visual Studio prend en charge les trois versions majeures du runtime. La version appropriée est utilisée au moment du débogage et de la publication, en fonction des paramètres de projet. Les paramètres de version sont définis dans le fichier .csproj, dans les propriétés suivantes :

Version 3.x
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

Notes

Azure Functions 3.x et .NET nécessitent que l’extension Microsoft.NET.Sdk.Functions soit au moins 3.0.0.

Version 2.x
<TargetFramework>netcoreapp2.1</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
Version 1.x
<TargetFramework>net472</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
Mise à jour des applications 2.x vers 3.x dans Visual Studio

Vous pouvez ouvrir une fonction existante ciblant 2.x et passer à 3.x en modifiant le fichier .csproj et en mettant à jour les valeurs ci-dessus. Visual Studio gère automatiquement pour vous les versions du runtime en fonction des métadonnées du projet. C’est néanmoins possible si vous n’ayez jamais créé d’application 3.x avant que Visual Studio ne dispose des modèles et du runtime pour 3.x sur votre machine. Ceci peut se présenter soi-même avec une erreur comme « Aucun runtime Functions disponible ne correspond à la version spécifiée dans le projet ». Pour récupérer les modèles et le runtime les plus récents, effectuez l’expérience de création d’un projet de fonction. Quand vous accédez à l’écran de sélection de la version et du modèle, attendez que Visual Studio termine la récupération des modèles les plus récents. Une fois les derniers modèles .NET Core 3 disponibles et affichés, vous pouvez exécuter et déboguer les projets configurés pour la version 3.x.

Important

Les fonctions en version 3.x peuvent être développées dans Visual Studio seulement si vous utilisez Visual Studio version 16.4 ou ultérieure.

VS Code et Azure Functions Core Tools

Azure Functions Core Tools est utilisé pour développer la ligne de commande, ainsi que par l’extension Azure Functions pour Visual Studio Code. Pour développer pour la version 3.x, installez la version 3.x de Core Tools. Le développement en version 2.x nécessite la version 2.x de Core Tools, etc. Pour plus d’informations, voir Installer Azure Functions Core Tools.

Pour un développement avec Visual Studio Code, vous devrez peut-être également mettre à jour le paramètre utilisateur pour azureFunctions.projectRuntime afin qu’il corresponde à la version des outils installés. Ce paramètre met également à jour les modèles et les langages utilisés lors de la création de l’application de fonction. Pour créer des applications dans ~3, vous devez mettre à jour le paramètre utilisateur azureFunctions.projectRuntime sur ~3.

Paramètre de runtime de l’extension Azure Functions

Applications Maven et Java

Vous pouvez migrer des applications Java de la version 2.x vers la version 3.x en installant la version 3.x de Core Tools nécessaire pour une exécution locale. Après avoir vérifié que votre application fonctionne correctement en local sur la version 3.x, mettez à jour le fichier POM.xml de l’application en changeant le paramètre FUNCTIONS_EXTENSION_VERSION en ~3, comme dans l’exemple suivant :

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

Liaisons

À compter de la version 2.x, le runtime utilise un nouveau modèle d’extensibilité de liaison qui présente les avantages suivants :

  • Prise en charge pour les extensions de liaison de tiers.

  • Découplage du runtime et des liaisons. Cela permet de gérer les versions des extensions de liaison et leur publication de façon indépendante. Vous pouvez, par exemple, choisir de mettre à niveau vers une version d’une extension qui s’appuie sur une version plus récente d’un kit de développement logiciel (SDK) sous-jacent.

  • Un environnement d’exécution plus léger, où seules les liaisons en cours d’utilisation sont connues et chargées par le runtime.

À l’exception des déclencheurs HTTP et de la minuterie, toutes les liaisons doivent être explicitement ajoutées au projet d’application de fonction, ou enregistrées dans le portail. Pour plus d’informations, voir Inscrire des extensions de liaison.

Le tableau suivant indique les liaisons prises en charge dans chaque version du runtime.

Ce tableau présente les liaisons qui sont prises en charge dans les versions majeures du runtime Azure Functions :

Type 1.x 2.x et ultérieures1 Déclencheur Entrée Output
Stockage Blob
Azure Cosmos DB
Dapr3
Event Grid
Hubs d'événements
HTTP et Webhooks
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Stockage File d’attente
RabbitMQ2
SendGrid
Service Bus
SignalR
Stockage Table
Minuteur
Twilio

1 À compter du runtime de la version 2.x, toutes les liaisons à l’exception de HTTP et du minuteur doivent être inscrites. Consultez Inscrire des extensions de liaison.

2 Les déclencheurs ne sont pas pris en charge dans le plan Consommation. Nécessite des déclencheurs basés sur le runtime.

3 Pris en charge uniquement dans Kubernetes, IoT Edge et d’autres modes autohébergés uniquement.

Durée du délai d’expiration du conteneur de fonctions

La durée d’expiration d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet host.json. Le tableau suivant présente les valeurs par défaut et les valeurs maximales en minutes pour les deux plans et dans les différentes versions du runtime :

Plan Version du runtime Default Maximale
Consommation 1.x 5 10
Consommation 2.x 5 10
Consommation 3.x 5 10
Premium 1.x Illimité Illimité
Premium 2.x 30 Illimité
Premium 3.x 30 Illimité
App Service 1.x Illimité Illimité
App Service 2.x 30 Illimité
App Service 3.x 30 Illimité

Notes

Quel que soit le paramètre de délai d’expiration du conteneur de fonctions, 230 secondes est le temps maximum que peut prendre une fonction déclenchée via HTTP pour répondre à une demande. Cela est dû au délai d’inactivité par défaut d’Azure Load Balancer. Pour des temps de traitement plus longs, pensez à utiliser un modèle asynchrone Durable Functions ou différez le travail actuel et renvoyez une réponse immédiate.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :