Comment cibler des versions du runtime Azure Functions

Une application de fonction s’exécute sur une version spécifique du runtime Azure Functions. Par défaut, vous créez des applications de fonction dans la dernière version 4.x du runtime Functions. Vos applications de fonction ne sont prises en charge que lorsqu’elles s’exécutent sur une version majeure prise en charge. Cet article détaille la configuration d’une application de fonction dans Azure afin de cibler ou d’épingler une version précise du runtime Functions, lorsque cela s’avère nécessaire.

Considérations

Gardez ces considérations à l’esprit lors du ciblage d’une version d’exécution spécifique :

Le plan Flex Consumption s’exécute uniquement sur la version 4.x du runtime. Étant donné que le plan Flex Consumption ne prend pas en charge le FUNCTIONS_EXTENSION_VERSION paramètre d’application, votre application ne peut pas cibler une version d’exécution spécifique lors de l’exécution dans ce plan.
La façon de cibler une version spécifique varie selon le système d’exploitation Windows ou Linux exécuté.
Cet article est spécifique à Windows ou Linux. Choisissez votre système d’exploitation en haut de l’article.
Si possible, exécutez toujours votre application sur la dernière version du runtime prise en charge. Épinglez votre application à une version spécifique uniquement si vous êtes invité à le faire en raison d’un problème avec la dernière version. Passez toujours à la dernière version du runtime dès que vos fonctions peuvent s’exécuter correctement.
Pendant le développement local, votre version installée d’Azure Functions Core Tools doit correspondre à la version principale du runtime utilisée par l’application de fonction dans Azure. Pour plus d’informations, consultez Versions de Core Tools.

Mettre à jour votre version du runtime

Si possible, exécutez toujours vos applications de fonction sur la dernière version prise en charge du runtime Azure Functions. Si votre application de fonction s’exécute actuellement sur une version antérieure du runtime, migrez votre application vers la version 4.x.

Lorsque votre application comporte des fonctions existantes, vous devez prendre des précautions avant de passer à une version majeure plus récente du runtime. Les articles suivants détaillent les changements cassants entre les versions majeures, notamment les changements cassants spécifiques à un langage. On vous fournit également des instructions pas à pas pour une migration réussie de votre application de fonction existante.

Pour déterminer votre version actuelle du runtime, consultez Afficher la version actuelle du runtime.

Afficher la version actuelle du runtime

Vous pouvez afficher la version actuelle du runtime de votre application de fonction de l’une des manières suivantes :

Pour afficher et mettre à jour la version du runtime actuellement utilisée par une application de fonction, procédez comme suit :

Dans le portail Azure, accédez à une application de fonction.
Développez Paramètres, puis sélectionnez Configuration.
Dans l’onglet Paramètres du runtime de fonction, notez la Version du runtime. Dans cet exemple, la version est définie sur ~4.

Vous pouvez afficher le paramètre d’application FUNCTIONS_EXTENSION_VERSION à partir d’Azure CLI.

À l’aide d’Azure CLI, affichez la version actuelle du runtime avec la commande az functionapp config appsettings list :

az functionapp config appsettings list --name <function_app> \
--resource-group <my_resource_group>

Dans ce code, remplacez <function_app> par le nom de votre application de fonction. Remplacez également <my_resource_group> par le nom du groupe de ressources de votre application de fonction.

La sortie partielle suivante s’affiche FUNCTIONS_EXTENSION_VERSION :

[
  {
    "name": "FUNCTIONS_EXTENSION_VERSION",
    "slotSetting": false,
    "value": "~4"
  },
  {
    "name": "FUNCTIONS_WORKER_RUNTIME",
    "slotSetting": false,
    "value": "dotnet"
  },
  
  ...
]

Sélectionnez Open Cloud Shell dans l’exemple de code précédent pour exécuter la commande dans Azure Cloud Shell. Vous pouvez également exécuter Azure CLI localement pour exécuter cette commande. Pour une exécution locale, vous devez d’abord exécuter az login pour vous connecter.

Pour vérifier le runtime Azure Functions, utilisez l’applet de commande suivante :

Get-AzFunctionAppSetting -Name "<FUNCTION_APP>" -ResourceGroupName "<RESOURCE_GROUP>"

Remplacez <FUNCTION_APP> par le nom de votre application de fonction et <RESOURCE_GROUP>. La valeur actuelle du paramètre FUNCTIONS_EXTENSION_VERSION est retournée dans la table de hachage.

Épingler à une version spécifique

Azure Functions vous permet d’utiliser le paramètre d’application FUNCTIONS_EXTENSION_VERSION pour cibler la version du runtime utilisée par une application de fonction donnée. Si vous spécifiez uniquement la version principale (~4), l’application de fonction est automatiquement mise à jour vers de nouvelles versions mineures du runtime dès qu’elles deviennent disponibles. Les mises à jour de versions mineures sont automatiques, car les nouvelles versions mineures ne sont pas susceptibles d’introduire des modifications qui interrompent vos fonctions.

Les applications Linux utilisent le paramètre de site linuxFxVersion avec FUNCTIONS_EXTENSION_VERSION pour déterminer l’image de base Linux appropriée dans laquelle exécuter vos fonctions. Lorsque vous créez une nouvelle application de fonction sur Linux, le runtime choisit automatiquement l’image de base appropriée pour vos besoins en fonction de la version du runtime de votre pile de langages.

L’épinglage à une version d’exécution spécifique redémarre votre application de fonctions.

Lorsque vous spécifiez une version mineure spécifique (par exemple 4.0.12345) dans FUNCTIONS_EXTENSION_VERSION, vous épinglez l’application de fonction à cette version spécifique du runtime jusqu’à ce que vous choisissiez explicitement de revenir aux mises à jour automatiques de version. Épinglez uniquement une version mineure spécifique pour la durée strictement nécessaire à la résolution des problèmes de votre application de fonction empêchant le ciblage de la version majeure. Les anciennes versions mineures sont régulièrement supprimées de l’environnement de production. Lorsque votre application de fonction est épinglée à une version mineure qui est supprimée ultérieurement, votre application de fonction s’exécute sur la version existante la plus proche au lieu de la version définie dans FUNCTIONS_EXTENSION_VERSION. Les annonces App Service annoncent les suppressions de versions mineures.

Remarque

Lorsque vous essayez de publier à partir de Visual Studio sur une application épinglée à une version mineure spécifique du runtime, une boîte de dialogue vous invite à effectuer une mise à jour vers la dernière version ou à annuler la publication. Pour éviter cette vérification lorsque vous devez utiliser une version mineure spécifique, ajoutez la propriété <DisableFunctionExtensionVersionUpdate>true</DisableFunctionExtensionVersionUpdate> dans votre fichier .csproj.

Utilisez l’une de ces méthodes pour épingler temporairement votre application à une version spécifique du runtime :

Pour afficher et mettre à jour la version du runtime actuellement utilisée par une application de fonction, procédez comme suit :

Dans le portail Azure, accédez à une application de fonction.
Développez Paramètres, puis sélectionnez Configuration.
Dans l’onglet Paramètres du runtime de fonction, notez la Version du runtime. Dans cet exemple, la version est définie sur ~4.

Pour épingler votre application à une version mineure spécifique, dans le volet gauche, développez Paramètres, puis sélectionnez Variables d’environnement.
Sous l’onglet Paramètres de l’application, sélectionnez FUNCTIONS_EXTENSION_VERSION, remplacez la valeurpar votre version mineure requise, puis sélectionnez Appliquer.
Sélectionnez Appliquer, puis cliquez sur Confirmez pour appliquer les modifications et redémarrez l’application.

Mettez à jour le paramètre d’application FUNCTIONS_EXTENSION_VERSION dans l’application de fonction à l’aide de la commande az functionapp config appsettings set.

az functionapp config appsettings set --name <FUNCTION_APP> \
--resource-group <RESOURCE_GROUP> \
--settings FUNCTIONS_EXTENSION_VERSION=<VERSION>

Utilisez ce script pour épingler le runtime Functions :

Update-AzFunctionAppSetting -Name "<FUNCTION_APP>" -ResourceGroupName "<RESOURCE_GROUP>" -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "<VERSION>"} -Force

Remplacez <FUNCTION_APP> par le nom de votre application de fonction et <RESOURCE_GROUP> par le nom du groupe de ressources de votre application de fonction. Remplacez également <VERSION> par la version mineure spécifique que vous devez cibler temporairement. Vous pouvez vérifier la valeur mise à jour du paramètre FUNCTIONS_EXTENSION_VERSION dans la table de hachage retournée.

L’application de fonction redémarre une fois que la modification a été apportée au paramètre d’application.

Pour épingler votre application de fonctions à une version d'environnement d'exécution spécifique sur Linux, définissez une URL d'image de base spécifique à la version dans le paramètre de linuxFxVersion site au format DOCKER|<PINNED_VERSION_IMAGE_URI>.

Important

Les applications de fonction épinglées sur Linux ne reçoivent pas de mises à jour régulières de la sécurité et des fonctionnalités de l’hôte. Sauf si c’est recommandé par un professionnel du support technique, utilisez le paramètre FUNCTIONS_EXTENSION_VERSION et une valeur linuxFxVersion standard pour votre langage et votre version, comme Python|3.12. Pour les valeurs valides, consultez l’article de référence sur linuxFxVersion.

L'épinglage à durée d'exécution spécifique n'est actuellement pas pris en charge pour les applications Linux exécutés dans le cadre de la consommation.

L’exemple suivant montre la linuxFxVersion valeur requise pour épingler une application de fonction Node.js 22 à une version d’exécution spécifique de la version 4.14.0.3 :

DOCKER|mcr.microsoft.com/azure-functions/node:4.14.0.3-node22

Si nécessaire, un professionnel du support peut vous fournir un URI d’image de base valide pour votre application.

Utilisez les commandes Azure CLI suivantes pour voir et définir linuxFxVersion. Vous ne pouvez actuellement pas définir linuxFxVersion dans le portail ou en utilisant Azure PowerShell :

Pour afficher la version du runtime actuelle, utilisez la commande az functionapp config show :
```
az functionapp config show --name <function_app> \
--resource-group <my_resource_group> --query 'linuxFxVersion' -o tsv
```
Dans ce code, remplacez <function_app> par le nom de votre application de fonction. Remplacez également <my_resource_group> par le nom du groupe de ressources de votre application de fonction. La valeur actuelle de linuxFxVersion est retournée.
Pour mettre à jour le paramètre linuxFxVersion dans l’application de fonction, utilisez la commande az functionapp config set :
```
az functionapp config set --name <FUNCTION_APP> \
--resource-group <RESOURCE_GROUP> \
--linux-fx-version <LINUX_FX_VERSION>
```
Remplacez <FUNCTION_APP> par le nom de votre application de fonction. Remplacez également <RESOURCE_GROUP> par le nom du groupe de ressources de votre application de fonction. Enfin, remplacez <LINUX_FX_VERSION> par la valeur d’une image spécifique fournie par un professionnel du support.

Vous pouvez exécuter ces commandes à partir de Azure Cloud Shell en choisissant Ouvrir Cloud Shell dans les exemples de code précédents. Vous pouvez également utiliser Azure CLI en local pour exécuter cette commande après avoir lancé la commande az login pour vous connecter.

L’application de fonction redémarre une fois la modification apportée à la configuration du site.

Mettre à jour l’image Linux gérée

Cette section s’applique uniquement aux applications Python 3.11 et Java 8, 11 ou 17 existantes sur les forfaits Linux Elastic Premium ou dédié (App Service) qui utilisent une image gérée par Debian Bullseye. Si votre application ne remplit pas toutes ces conditions, vous n’avez pas besoin de suivre cette procédure.

La nouvelle image gérée offre un chemin temporaire pour qu’une application affectée reste sur sa version actuelle de la langue tout en passant à une distribution Linux prise en charge. Cette procédure ne s’applique pas à Flex Consumption ni aux applications de conteneurs personnalisés. Pour une application sous le plan Linux Consumption, migrez vers le plan Flex Consumption.

Cette mise à jour sélectionne la distribution Linux pour la version linguistique existante en utilisant une valeur en trois parties linuxFxVersion . Il n’épingle pas l’hôte Fonctions à une image spécifique DOCKER|<IMAGE_URI> .

Choisissez une valeur Bookworm ou Noble `linuxFxVersion`

D’abord, déterminez si vous pouvez mettre à jour la version de la langue ou si vous devez conserver la version actuelle et sélectionnez une distribution Linux plus récente.

Envisagez de mettre à jour l’application vers une version linguistique plus récente prise en charge. Après une mise à jour de langue, l’application utilise l’image gérée par défaut actuelle pour cette version linguistique.

Si l’application doit rester sur sa version linguistique actuelle, choisissez la valeur d’image plus récente correspondante :

Version linguistique	Valeur de Debian Bullseye	Distribution plus récente	Valeur d’image plus récente
Python 3.11	`Python\\|3.11\\|2.0`	Debian Bookworm	`Python\\|3.11\\|3.0`
Java 8	`Java\\|8\\|2.0`	Ubuntu Noble	`Java\\|8\\|4.0`
Java 11	`Java\\|11\\|2.0`	Ubuntu Noble	`Java\\|11\\|4.0`
Java 17	`Java\\|17\\|2.0`	Ubuntu Noble	`Java\\|17\\|4.0`

Ces valeurs à trois éléments sélectionnent explicitement l’image Linux gérée pour ces images de la génération Bullseye. Ils ne sont pas renvoyés par la az functionapp list-runtimes commande.

Testez la nouvelle image Linux gérée

Testez votre application et ses dépendances à la nouvelle image avant de mettre à jour l’application de production.

Créez une application de test séparée ou créez un slot de déploiement.
Déploie le même code et la même configuration que ton application de production sur l’application ou le slot de test.
Définissez la nouvelle valeur d’image en suivant les étapes de Mettre à jour la valeur de l’image. Lorsque vous utilisez un emplacement, incluez --slot <SLOT_NAME> dans chaque commande Azure CLI.
Invoquez chaque fonction et vérifiez que l’application démarre correctement, que les déclenchements s’exécutent comme prévu, et que les dépendances natives ou du système d’exploitation se chargent correctement.

Mettre à jour la valeur de l’image

Changer la valeur de l’image redémarre l’application de fonctions. Mettez à jour la production pendant une fenêtre de maintenance, ou utilisez un slot de déploiement.

Voir la valeur actuelle linuxFxVersion :
```
az functionapp config show --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query linuxFxVersion --output tsv
```
Cette commande renvoie la valeur stockée dans la configuration du site. La valeur retournée peut contenir uniquement la langue et la version linguistique, telles que Python|3.11, plutôt que la valeur en trois parties qui identifie la distribution Linux. Si la valeur n’inclut pas la version de l’image, suivez les étapes de Vérifier la distribution Linux pour confirmer que l’application utilise actuellement Debian Bullseye.
Réglez linuxFxVersion sur la nouvelle valeur d’image :
```
az functionapp config set --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --linux-fx-version "<LANGUAGE|VERSION|IMAGE_VERSION>"
```
Pour Python 3.11 sur Debian Bookworm, utilisez Python|3.11|3.0. Pour Java sur Ubuntu Noble, utilisez Java|8|4.0, Java|11|4.0, ou Java|17|4.0.
Attendez que l’application redémarre.

Vérifier la distribution Linux

Vérifiez à la fois la valeur configurée et la distribution Linux qui fait tourner votre application.

Confirmez la valeur mise à jour linuxFxVersion :
```
az functionapp config show --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query linuxFxVersion --output tsv
```
Parce que vous avez explicitement défini une valeur en trois parties, cette commande retourne exactement la valeur Rat de bibliothèque ou Noble que vous avez sélectionnée.
Ouvrez le site Kudu de l’application à https://<APP_NAME>.scm.azurewebsites.net.
Sélectionnez « Environnement » et vérifiez KUDU_ENV, ou ouvrez une session SSH et exécutez :
```
cat /etc/os-release
```
Confirmez que la sortie identifie Debian Bookworm pour Python 3.11 ou Ubuntu Noble pour Java 8, 11 ou 17.
Invoquez chaque fonction et confirmez que les déclencheurs et dépendances continuent de fonctionner comme prévu.

Annuler la mise à jour d’image Linux gérée

Si l’image mise à jour cause un problème de compatibilité, restaurez temporairement la valeur précédente linuxFxVersion pendant que vous corrigez le problème.

Warning

Debian Bullseye n’est plus pris en charge après sa date de fin de vie et ne reçoit plus de mises à jour de sécurité. Utilisez le retour en arrière uniquement comme atténuation temporaire, et revenez à une image prise en charge dès que possible.

Dans le tableau de Choisir une valeur Bookworm ou NoblelinuxFxVersion, trouvez la valeur Debian Bullseye pour votre version linguistique.

Définir linuxFxVersion sur cette valeur « Bullseye » :

az functionapp config set --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --linux-fx-version "<BULLSEYE_LINUX_FX_VERSION>"

Attendez que l’application redémarre, puis répétez les vérifications dans Verify the Linux distribution.

Étapes suivantes

Consulter les notes de publication pour les versions du runtime

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-09-17