Vue d’ensemble des versions du runtime Azure Functions

Azure Functions prend actuellement en charge plusieurs versions de l’hôte du runtime. Le tableau suivant détaille les versions disponibles, leur niveau de support et le moment où elles doivent être utilisées :

Version Niveau de support Description
4.x GA Version d’exécution recommandée pour les fonctions dans toutes les langues. Consultez les versions de langue prises en charge.
3.x GA Prend en charge tous les langages. Consultez les Versions de langage prises en charge.
2.x GA Prise en charge pour les applications héritées des versions 2.x. Cette version est en mode maintenance, et les améliorations ne seront apportées que dans les versions ultérieures.
1.x GA Recommandé uniquement pour les applications C# qui doivent utiliser .NET Framework ; ne prend en charge que le développement dans le portail Azure, le portail Azure Stack Hub ou localement sur les ordinateurs Windows. Cette version est en mode maintenance, et les améliorations ne seront apportées que dans les versions ultérieures.

Important

À compter du 3 décembre 2022, les applications de fonction exécutées sur les versions 2.x et 3.x du runtime d’Azure Functions ne seront plus prises en charge. Avant cette date, veuillez tester, vérifier et migrer vos applications de fonction vers la version 4.x du runtime d’Azure Functions. Pour plus d’informations, consultez Migrer des applications de Azure Functions version 3.x vers la version 4.x. Après l’échéance, les applications de fonction peuvent être créées et déployées, et les applications existantes continuent à s’exécuter. Toutefois, vos applications ne seront pas éligibles aux nouvelles fonctionnalités, aux correctifs de sécurité, aux optimisations des performances et au support tant que vous ne les aurez pas mises à niveau vers la version 4.x.

La fin de la prise en charge de ces versions du runtime est due à la fin de la prise en charge de .NET Core 3.1, qui est requis par celles-ci. Cette exigence concerne tous les langages du runtime d’Azure Functions.
La version 1.x d’Azure Functions reste prise en charge pour les applications de fonction C# qui ont besoin de .NET Framework. La prise en charge de la préversion est désormais disponible dans Azure Functions 4.x pour exécuter les fonctions C# sur .NET Framework 4.8.

Cet article détaille certaines des différences entre ces versions, la façon dont vous pouvez créer chaque version, et la manière de changer la version sur laquelle vos fonctions s’exécutent.

Niveaux de prise en charge

Il y a deux niveaux de prise en charge :

  • Disposition générale (GA) : entièrement pris en charge et approuvé pour la production.
  • Préversion : pas encore pris en charge, mais le statut de disponibilité générale est prévu à l’avenir.

Languages

Toutes les fonctions d’une application de fonction doivent partager le même langage. Vous avez choisi le langage des fonctions de votre application de fonction lors de la création de l’application. Le langage de votre application de fonction est conservé dans le paramètre FUNCTIONS_WORKER_RUNTIME et ne doit pas être modifié lorsque des fonctions existent.

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

Langage 1.x 2.x 3.x 4.x
C# GA (.NET Framework 4.8) GA (.NET Core 2.11) Disponibilité générale (.NET Core 3.1)
GA (.NET 6.0)
GA (.NET 7.0)
GA (.NET Framework 4.8)
JavaScript GA (Node.js 6) GA (Node.js 10 & 8) GA (Node.js 14, 12, & 10) GA (Node.js 14)
GA (Node.js 16)
Préversion (Node.js 18)
F# GA (.NET Framework 4.8) GA (.NET Core 2.11) Disponibilité générale (.NET Core 3.1) GA (.NET 6.0)
GA (.NET 7.0)
Java N/A Disponibilité générale (Java 8) GA (Java 11 & 8) GA (Java 11 & 8)
Préversion (Java 17)
PowerShell N/A N/A Disponibilité générale (PowerShell 7.0) Disponibilité générale (PowerShell 7.0, 7.2)
Python N/A GA (Python 3.7) GA (Python 3.9, 3.8, 3.7) GA (Python 3.9, 3.8, 3.7)
TypeScript2 N/A GA GA GA

1 Les applications de bibliothèque de classes .NET qui ciblent le runtime version 2.x s’exécutent 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

La version du runtime Functions utilisée par les applications publiées dans Azure dépend du paramètre d’application FUNCTIONS_EXTENSION_VERSION. Dans certains cas et pour certains langages, d’autres paramètres peuvent s’appliquer.

Par défaut, les applications de fonction créées dans le Portail Azure, par l’interface Azure CLI ou à partir des outils Visual Studio, sont configurées pour la version 4.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 déplacement vers une version ultérieure est autorisé même avec des applications qui ont des fonctions existantes.

Migration des applications de fonction existantes

Lorsque votre application a des fonctions existantes, vous devez prendre des précautions avant de passer à une version de runtime ultérieure. Les articles suivants détaillent les changements cassants entre les versions, y compris les changements cassants spécifiques au langage. Ils vous fournissent également des instructions pas à pas pour une migration réussie de votre application de fonction existante.

Changement de la version des applications dans Azure

Les valeurs des versions majeures du runtime suivantes sont prises en charge :

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

Important

Ne modifiez pas arbitrairement ce paramètre d’application, car d’autres modifications des paramètres de l’application et d’autres modifications du code dans vos fonctions peuvent être nécessaires. Vous devez plutôt modifier ce paramètre dans l’onglet Paramètres du runtime de fonction de la Configuration de l’application de fonction dans le portail Azure lorsque vous êtes prêt à effectuer une mise à niveau de version majeure. Pour les applications de fonction existantes, suivez les instructions de migration.

É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 temporairement é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.

Versions d’extension minimales

Il n’existe pas techniquement de corrélation entre les versions d’extension de liaison et la version du runtime Functions. Toutefois, à compter de la version 4.x, le runtime Functions applique une version minimale pour toutes les extensions de déclencheur et de liaison.

Si vous recevez un avertissement sur un package qui ne répond pas à une version minimale requise, vous devez mettre à jour ce package NuGet vers la version minimale comme vous le feriez normalement. La configuration minimale requise pour les extensions utilisées dans Functions v4.x est disponible dans le fichier de configuration lié.

Pour le script C#, mettez à jour la référence du pack d’extension dans host.json comme suit :

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

Il n’existe pas techniquement de corrélation entre les versions du pack d’extensions et la version du runtime Functions. Toutefois, à compter de la version 4.x, le runtime Functions applique une version minimale pour les packs d’extensions.

Si vous recevez un avertissement disant que la version de votre pack d’extensions n’est pas conforme à la version minimale requise, mettez à jour votre référence de pack d’extensions existante dans host.json comme suit :

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

Pour en savoir plus sur les packs d’extensions, consultez Packs d’extensions.

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 :

<TargetFramework>net6.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>

Vous pouvez également choisir net6.0,net7.0 ou net48 comme cadre de destination si vous utilisez des fonctions de processus Worker isolé .NET. La prise en charge de net7.0 et net48 est actuellement en préversion.

Notes

Azure Functions 4.x nécessite que l’extension Microsoft.NET.Sdk.Functions soit au moins à la version 4.0.0.

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 par rapport à la version 4.x, installez la version 4.x de Core Tools. Le développement vers la version 3.x nécessite la version 3.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

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
Azure SQL (préversion)
Dapr3
Event Grid
Hubs d'événements
HTTP 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 du délai d’expiration pour les fonctions d’une application de fonction est définie par la propriété functionTimeout dans le fichier projet host.json. Cette propriété s’applique spécifiquement aux exécutions de fonction. Une fois que le déclencheur démarre l’exécution d’une fonction, la fonction doit retourner/répondre dans la durée du délai d’expiration. Pour plus d’informations, consultez Améliorer les performances et la fiabilité d’Azure Functions.

Le tableau suivant indique les valeurs par défaut et maximales (en minutes) pour des plans spécifiques :

Plan Default Maximum1
Plan de consommation 5 10
Plan Premium 302 Illimité
Plan dédié 302 Illimité

1 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.
2 Le délai d’expiration par défaut pour la version 1.x du runtime Functions est illimité.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :