Technologies de déploiement dans Azure Functions

Vous pouvez utiliser plusieurs technologies différentes pour déployer votre code de projet Azure Functions sur Azure. Cet article fournit une vue d’ensemble des méthodes de déploiement disponibles et des recommandations sur la meilleure méthode à utiliser dans différents scénarios. Il fournit également une liste complète des informations clés et détaillées sur les technologies de déploiement sous-jacentes.

Méthodes de déploiement

La technologie de déploiement que vous utilisez pour publier du code dans votre application de fonction dans Azure dépend de vos besoins spécifiques et du point dans le cycle de développement. Par exemple, pendant le développement et les tests, vous pouvez déployer directement à partir de votre outil de développement, tel que Visual Studio Code. Quand votre application est en production, vous êtes plus susceptible de publier en continu à partir du contrôle de code source ou en utilisant un pipeline de publication automatisé, qui peut comprendre une validation et des tests.

Le tableau suivant décrit les méthodes de déploiement disponibles pour votre projet de code.

Type de déploiement Méthodes Idéal pour…
Outils Service de contrôle d’accès Azure (CLI)
Visual Studio Code publish
Visual Studio publie
Publication de Core Tools		 Déploiements pendant le développement et autres déploiements improvisés. Déploiement de votre code à la demande à l’aide d’outils de développement locaux.
Géré par la plateforme Centre de déploiement (CI/CD)
Déploiements de conteneurs		 Déploiement continu (CI/CD) à partir du contrôle de code source ou d’un registre de conteneurs. La plateforme d’hébergement gère les déploiements.
Pipelines externes Azure Pipelines
GitHub Actions		 Pipelines de production qui incluent la validation, le test et d’autres actions qui doivent s’exécuter dans le cadre d’un déploiement automatisé. Le pipeline gère les déploiements.

Utilisez la meilleure technologie pour votre scénario spécifique. Pour les plans d’hébergement pris en charge, de nombreuses méthodes de déploiement utilisent le déploiement zip.

Disponibilité des technologies de déploiement

La méthode de déploiement dépend également du plan d’hébergement et du système d’exploitation sur lesquels vous exécutez votre application de fonction.

Actuellement, Functions offre cinq options pour l’hébergement de vos applications de fonction :

Chaque plan a des comportements différents. Les technologies de déploiement ne sont pas toutes disponibles pour chaque plan d’hébergement et système d’exploitation. Ce graphique fournit des informations sur les technologies de déploiement prises en charge :

Technologie de déploiement Consommation flexible Consommation Premium élastique Dédié Applications de conteneur
Déploiement du package Flex Consumption Supported Non pris en charge Non pris en charge Non pris en charge Non pris en charge
Déploiement ZIP Non pris en charge Supported Supported Supported Non pris en charge
URL du paquet externe1 Non pris en charge Supported Supported Supported Non pris en charge
Image du conteneur (Docker) Non pris en charge Linux uniquement Linux uniquement Linux uniquement Supported
Contrôle de code source Non pris en charge Windows uniquement Supported Supported Non pris en charge
Git local1 Non pris en charge Windows uniquement Supported Supported Non pris en charge
FTPS1 Non pris en charge Windows uniquement Supported Supported Non pris en charge
Modification dans le portail2 Non pris en charge Supported Supported Supported Non pris en charge
  1. Les technologies de déploiement qui nécessitent de synchroniser manuellement les déclencheurs ne sont pas recommandées.
  2. L’édition dans le portail est désactivée lorsque le code est déployé dans votre application fonctionnelle depuis l’extérieur du portail. Pour plus d’informations, y compris les détails de la prise en charge linguistique pour la modification dans le portail, consultez Détails de la prise en charge de la langue.

Sélectionnez votre plan d’hébergement en haut de cet article pour voir les technologies et comportements de déploiement applicables à votre application de fonction.

Concepts clés

Certains concepts clés sont essentiels pour comprendre le fonctionnement des déploiements dans Azure Functions.

Stockage de contenu d’application par forfait d’hébergement

L’emplacement du contenu déployé de l’application dépend du plan d’hébergement et de la technologie de déploiement :

Plan d’hébergement Stockage de contenu de l’application
Consommation flexible Un conteneur de déploiement d’objets blob que vous configurez pour l’application de fonction.
Consommation, Elastic Premium et dédié Le système de fichiers de l’application, un partage de contenu Azure Files, ou une URL de package externe, selon la technologie de déploiement.
Azure Container Apps (Applications de Conteneur Azure) Une image conteneur stockée dans un registre de conteneurs.

Synchronisation des déclencheurs

Lorsqu’un déploiement ajoute, supprime ou modifie une fonction ou sa configuration de déclenchement, l’infrastructure des fonctions doit mettre à jour les métadonnées du déclencheur pour l’application fonctionnaire. Cette synchronisation se fait automatiquement pour de nombreuses technologies de déploiement. Toutefois, dans certains cas, vous devez synchroniser manuellement les déclencheurs.

Vous devez toujours synchroniser manuellement les déclencheurs lors de l’utilisation de ces options de déploiement :

Vous pouvez synchroniser manuellement les déclencheurs de l’une des manières suivantes :

  • Redémarrez votre application de fonction dans le portail Azure. L’hôte Functions lance une synchronisation des déclencheurs en arrière-plan après le démarrage de l’application.

  • Utilisez la commande az rest pour envoyer une requête HTTP POST qui appelle l’API syncfunctiontriggers, comme dans cet exemple :

    az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

Gardez ces considérations à l’esprit pour l’opération de déclenchement de synchronisation :

  • Vous devez redémarrer manuellement votre application de fonction chaque fois que vous déployez une version mise à jour du package de déploiement à l’aide de la même URL de package externe.
  • Pour les applications s’exécutant dans un plan Consommation ou Elastic Premium, vous devez également synchroniser manuellement les déclencheurs dans les scénarios suivants :
    • Lorsque les déploiements utilisent une URL de package externe avec un déploiement basé sur Resource Manager à l’aide de modèles ARM ou de fichiers Bicep ou Terraform.
    • Lorsque vous mettez à jour le package de déploiement sur place en utilisant la même URL de package externe.
  • Lorsque vous ajoutez des restrictions réseau à une application de fonction existante, vous devez garantir la connectivité au compte de stockage hôte par défaut défini dans le AzureWebJobsStorage paramètre d’application. Pour plus d’informations, consultez Comment utiliser un compte de stockage sécurisé avec Azure Functions.

Build distante

Vous pouvez demander Azure Functions pour effectuer une build distante de votre projet de code pendant le déploiement. Dans ces scénarios, demandez une build distante plutôt que de le faire localement :

  • Vous déployez une application sur une application de fonction Linux que vous avez développée sur un ordinateur Windows. C'est souvent le cas pour le développement d'applications Python. Vous pouvez rencontrer des bibliothèques incorrectes lorsque vous générez le package de déploiement localement sur Windows.
  • Votre projet a des dépendances vis-à-vis d’un index de package personnalisé.
  • Vous voulez réduire la taille de votre package de déploiement.

La façon dont vous demandez une build distante dépend de l’exécution de votre application dans Azure sur Windows ou Linux.

Toutes les applications de fonctions fonctionnant sous Windows disposent d’un site de déploiement compagnon. Ce site gère une grande partie de la logique de déploiement et de génération pour Azure Functions.

Lorsque vous déployez une application sur Windows, le processus de déploiement exécute des commandes spécifiques au langage, comme dotnet restore (C#) ou npm install (JavaScript).

Les considérations suivantes s’appliquent lors de l’utilisation de builds distantes pendant un déploiement :

  • Les builds distantes sont prises en charge pour les applications de fonction s’exécutant sur Linux dans le plan Consommation. Cependant, les options de déploiement sont limitées pour ces applications car elles n’ont pas de site de déploiement compagnon.
  • Les applications fonctionnelles fonctionnant sous Linux dans un forfait Elastic Premium ou dans un forfait dédié (App Service) disposent d'un site de déploiement compagnon, mais il est limité comparé à Windows.
  • Ne définissez pas WEBSITE_RUN_FROM_PACKAGE lorsque vous demandez un build distant. Pour Linux Consumption, Elastic Premium et les applications de forfaits dédiés, activez plutôt la compilation à distance en utilisant les paramètres de déploiement décrits dans l’onglet Linux . Le processus de déploiement peut empaqueter la sortie de compilation et configurer l’application pour qu’elle s’exécute à partir de ce paquet.
  • Vous pouvez rencontrer des problèmes avec la génération à distance lorsque votre application a été créée avant la mise à disposition de la fonctionnalité (1er août 2019). Pour des applications plus anciennes, créez une application de fonction ou exécutez az functionapp update --resource-group <RESOURCE_GROUP_NAME> --name <APP_NAME> pour mettre à jour votre application de fonction. Cette commande peut nécessiter deux tentatives avant d’aboutir.

Build distante

Pour Flex Consumption, vous demandez un build à distance en transmettant un paramètre de build à distance lorsque vous démarrez le déploiement. On ne configure pas la compilation à distance en utilisant les paramètres de l’application. Pour Core Tools et Visual Studio Code, une compilation à distance est toujours demandée lors du déploiement d’une application Python. Pour plus d’informations, consultez Déploiement.

Stockage de contenu de l’application

Flex Consumption stocke le package actuel dans le conteneur de stockage de déploiement configuré. Par défaut, ce conteneur est dans le même compte que celui utilisé par AzureWebJobsStorage, mais vous pouvez configurer un compte de stockage de déploiement différent.

Important

Le compte de stockage permet de stocker les données importantes de l’application, dont parfois le code proprement dit de l’application. Vous devez limiter l’accès des autres applications et utilisateurs au compte de stockage.

Stockage de contenu de l’application

Selon la technologie de déploiement, le contenu de votre application peut être stocké sur le système de fichiers de l’application, un partage de contenu Azure Files, ou sur une URL externe de paquet. Consultez dans la section suivante où le contenu de l’application est stocké pour chaque technologie de déploiement.

Important

Le compte de stockage permet de stocker les données importantes de l’application, dont parfois le code proprement dit de l’application. Vous devez limiter l’accès des autres applications et utilisateurs au compte de stockage.

Réseaux virtuels sécurisés

Lorsque votre application de fonctions active les points de terminaison privés et que l’accès au réseau public est désactivé, le point de déploiement n’est pas accessible publiquement. Les outils de déploiement Push, y compris Core Tools, Visual Studio Code, Azure CLI, GitHub Actions et Azure Pipelines, envoient des paquets à ce point de terminaison. La machine, le runner ou l’agent qui effectue le déploiement doit disposer à la fois de la connectivité réseau et d’une résolution DNS pour le point de terminaison privé de déploiement.

Vous pouvez fournir cette connectivité de la manière suivante :

La ressource de déploiement peut se trouver dans le même réseau virtuel ou dans un réseau disposant d’une connectivité de routage et DNS vers le point de terminaison privé, comme un réseau virtuel par pairs.

Les déploiements de paquets basés sur Resource Manager ne poussent pas le paquet du client initiateur vers le point de terminaison de déploiement. À la place, le service de déploiement récupère le package à partir de l’URL fournie dans la ressource de déploiement. L’URL du package et le stockage de déploiement doivent être accessibles au service de déploiement. Pour la consommation flexible, voir Déployer en utilisant Bicep ou un modèle Azure Resource Manager.

Pour plus d’informations sur la configuration de votre application de fonction dans un réseau virtuel, consultez How to configure Azure Functions with a virtual network.

Stockage et réseau du contenu applicatif

Azure Functions sur Azure Container Apps déploie votre application comme une image conteneur. L’image est stockée dans un registre de conteneurs, et le réseau est géré par l’environnement Conteneur Applications. Pour plus d’informations, consultez Vue d’ensemble d’Azure Functions sur Azure Container Apps et Mise en réseau dans Azure Container Apps.

Comportement de déploiement par plan d’hébergement

Les méthodes de déploiement suivantes s’appliquent à votre plan d’hébergement choisi. Pour comparer les technologies sur tous les plans, consultez le tableau de disponibilité des technologies de déploiement .

Déploiement du package Flex Consumption

Le déploiement de paquets est la seule technologie de déploiement de code prise en charge pour les applications sur un forfait Flex Consumption. Le processus de déploiement stocke un paquet .zip prêt à s’exécuter dans le conteneur de déploiement de l’application, et l’application fonctionnelle s’exécute directement à partir de ce paquet.

Comment l'utiliser : Déployez en utilisant la fonction de publication de Visual Studio Code, ou à partir de la ligne de commande en utilisant Azure Functions Core Tools ou Azure CLI. La tâche Azure DevOps et l’action GitHub sélectionnent de la même manière le bon comportement de déploiement des paquets lorsqu’ils détectent une application Flex Consumption.

Lorsque vous créez une application Flex Consumption, vous devez spécifier un conteneur de stockage de déploiement (blob) ainsi qu’une méthode d’authentification pour celle-ci. Par défaut, le même compte de stockage que la connexion AzureWebJobsStorage est utilisé, avec un chaîne de connexion comme méthode d’authentification. Par conséquent, vos paramètres de déploiement sont configurés lors de la création de l’application sans que des paramètres d’application soient nécessaires.

Quand l’utiliser : Utilisez le déploiement de packages pour tous les déploiements de code Flex Consumption. Aucune autre technologie de déploiement de code n’est prise en charge.

Où le contenu de l’application est stocké : quand vous créez une application de fonction Consommation flexible, vous spécifiez un conteneur de stockage de déploiement. Le service de déploiement stocke dans ce conteneur le paquet traité, prêt à être exécuté. Les outils de déploiement push envoient d’abord le package source vers le point de déploiement de l’application ; ils ne téléchargent pas directement sur le conteneur de déploiement. Pour changer l’emplacement de stockage, ouvrez la page des paramètres de déploiement dans le portail Azure ou utilisez la clé de commande Azure CLI.

L’API sous-jacente de la plateforme est parfois identifiée comme OneDeploy. Les définitions d’infrastructure-as-code exposent cette implémentation à travers le nom littéral /onedeploy de la ressource. Vous n’avez pas besoin de sélectionner ou configurer cette API lors du déploiement en utilisant des outils de développement pris en charge ou des fournisseurs CI/CD.

Conseil / Astuce

Un outil de diagnostic Flex Consumption Deployment est disponible dans le portail Azure. Ouvrez votre application Flex Consumption, sélectionnez Diagnostiquer et résoudre les problèmes, puis recherchez Flex Consumption Deployment. Cet outil affiche des informations détaillées sur vos déploiements, notamment l’historique de déploiement, l’état du package et les recommandations de résolution des problèmes.

Déploiement ZIP

Le déploiement ZIP est la technologie de déploiement par défaut et recommandée pour les applications fonctionnelles des forfaits Consumption, Elastic Premium et Dedicated (App Service). Le résultat final est un package .zip prêt à l’exécution sur lequel votre application de fonction s’exécute. Il diffère de l’URL de package externe dans laquelle la plateforme est responsable de la création à distance et du stockage du contenu de votre application.

Comment l’utiliser : Déploie en utilisant ton outil client préféré : Visual Studio Code, Visual Studio, ou depuis la ligne de commande en utilisant Azure Functions Core Tools ou Azure CLI. La tâche Azure DevOps et GitHub Action utilisent de manière similaire le déploiement ZIP.

Lorsque vous utilisez le déploiement ZIP, vous pouvez configurer votre application pour qu’elle s’exécute à partir d’un package. Pour utiliser le mode Exécuter à partir du package, affectez au paramètre d’application WEBSITE_RUN_FROM_PACKAGE la valeur 1. Nous recommandons le déploiement de ZIP. Cela permet des temps de chargement plus rapides pour vos applications, et c'est la norme par défaut pour Visual Studio Code, Visual Studio et l'Azure CLI.

Quand l’utiliser : Le déploiement ZIP est la technologie de déploiement par défaut et recommandée pour les applications de fonction sur les plans Windows Consumption, Windows and Linux Elastic Premium, et Windows et Linux App Service (dédié).

Où le contenu de l’application est stocké : Le contenu d’une application issue d’un déploiement ZIP est stocké par défaut sur le système de fichiers, ce qu’Azure peut sauvegarder via Azure Files depuis le compte de stockage que vous spécifiez lors de la création de l’application de fonction. Dans un environnement Linux Consumption, le contenu de l'application est conservé sur un blob dans le compte de stockage spécifié par le paramètre d'application AzureWebJobsStorage, et le paramètre d'application WEBSITE_RUN_FROM_PACKAGE prend la valeur de l'URL du blob.

URL du package externe

Utilisez une URL de package externe lorsque vous souhaitez contrôler manuellement la façon dont les déploiements se déroulent. Vous êtes responsable de télécharger un paquet .zip prêt à s’exécuter contenant le contenu de votre application dans un stockage en blob et de référencer cette URL externe comme paramètre d’application sur votre application fonctionnelle. Chaque fois que votre application redémarre, elle récupère le paquet, le monte, puis s’exécute à partir du paquet.

Comment l’utiliser ? Ajoutez WEBSITE_RUN_FROM_PACKAGE à vos paramètres d’application. La valeur de ce paramètre doit être une URL d’objet blob pointant vers l’emplacement du package spécifique que votre application doit exécuter. Vous pouvez ajouter des paramètres dans le portail ou en utilisant l’Azure CLI.

Si vous utilisez Stockage Blob Azure, votre application de fonction peut accéder au conteneur soit en utilisant une connexion gérée basée sur l’identité, soit avec une signature d’accès partagée (SAS). L’option que vous choisissez affecte le type d’URL que vous utilisez comme valeur pour WEBSITE_RUN_FROM_PACKAGE. Une identité managée est recommandée pour la sécurité globale, car les jetons SAP expirent et doivent être gérés manuellement.

Chaque fois que vous déployez le fichier de package référencé par une application de fonction, vous devez synchroniser manuellement les déclencheurs, y compris le déploiement initial. Lorsque vous modifiez le contenu du fichier de package et non l’URL elle-même, vous devez également redémarrer votre application de fonction pour synchroniser les déclencheurs. Pour les étapes de configuration, voir Exécuter depuis une URL de package externe.

Quand l’utiliser : URL de package externe est la seule méthode de déploiement prise en charge pour les applications s’exécutant sur le plan Consommation Linux quand vous ne voulez pas qu’une build distante se produise. Cette méthode est également la technologie de déploiement recommandée lorsque vous créez votre application sans Azure Files. Pour les applications évolutives s’exécutant sur Linux, vous devez envisager à la place l’hébergement du plan Consommation flexible.

Où le contenu de l’application est stocké : cous êtes responsable du chargement du contenu de votre application dans le stockage d’objets blob. Vous pouvez utiliser n’importe quel compte de stockage blob, bien que Stockage Blob Azure soit recommandé.

Conteneur Docker

Vous pouvez déployer une application de fonction s’exécutant dans un conteneur Linux.

Comment l'utiliser :Créez vos fonctions dans un conteneur Linux puis déployez le conteneur vers un plan Premium ou Dédié dans Azure Functions ou un autre hôte de conteneur. Utilisez les Azure Functions Core Tools pour créer un fichier Dockerfile personnalisé pour votre projet que vous utilisez pour créer une application de fonction conteneurisée. Vous pouvez utiliser le conteneur dans les déploiements suivants :

Quand l’utiliser ? Utilisez l’option Conteneur Docker si vous voulez contrôler davantage l’environnement Linux dans lequel s’exécute votre application de fonction, et où le conteneur est hébergé. Cette technologie de déploiement est disponible uniquement quand Azure Functions est exécuté sur Linux.

Emplacement où le contenu de l’application est stocké : Vous stockez le contenu de l’application dans le registre de conteneurs spécifié dans le cadre de l’image.

Contrôle de code source

Vous pouvez activer l’intégration continue entre votre application de fonction et un référentiel de code source. Lorsque vous activez le contrôle de code source, une mise à jour du code dans le référentiel source connecté déclenche le déploiement du code le plus récent à partir du référentiel. Pour plus d’informations, consultez le Déploiement continu pour Azure Functions.

Comment l’utiliser : Le moyen le plus simple de configurer la publication à partir du contrôle de code source provient du Centre de déploiement dans la zone Functions du portail. Pour plus d’informations, consultez Déploiement continu pour Azure Functions.

Quand l’utiliser : l’utilisation du contrôle de code source est la méthode recommandée pour les équipes qui travaillent en collaboration sur leurs applications de fonction. Il s’agit d’une bonne option si vous avez des pipelines de déploiement plus complexes. En règle générale, le contrôle de source est activé sur un emplacement de staging, qui peut ensuite être échangé vers la production après validation des mises à jour issues du référentiel. Pour plus d'informations, veuillez consulter la section emplacements de déploiement Azure Functions.

Emplacement où le contenu de l’application est stocké : Le système de contrôle de code source stocke le contenu de l’application. Le système de fichiers de l’application conserve un formulaire de contenu d’application cloné et compilé localement, pouvant être sauvegardé par Azure Files à partir du compte de stockage défini lors de la création de l’application de fonction.

Git local

Utilisez Git local pour envoyer du code à partir de votre ordinateur local pour Azure Functions à l’aide de Git.

Comment l'utiliser : Suivez les instructions dans Déploiement Git local vers Azure App Service.

Quand l’utiliser : Pour réduire les risques d’erreurs, évitez d’utiliser des méthodes de déploiement qui nécessitent l’étape supplémentaire de synchronisation manuelle des déclencheurs. Utilisez un déploiement zip si possible.

Où le contenu de l’application est stocké : Le système de fichiers stocke le contenu de l’application. Le système de fichiers peut être soutenu par Azure Files depuis le compte de stockage que vous spécifiez lors de la création de l’application de fonctions.

FTPS

Vous pouvez utiliser FTPS pour transférer directement des fichiers vers Azure Functions, mais n'utilisez pas cette méthode de déploiement. Si vous ne prévoyez pas d’utiliser FTPS, désactivez-le. Pour apprendre à le configurer dans le portail Azure, consultez Appliquer FTPS.

Comment l’utiliser : Suivez les instructions des paramètres de déploiement FTPS pour obtenir l’URL et les informations d’identification que vous pouvez utiliser pour effectuer le déploiement sur votre application de fonction à l’aide de FTPS.

Quand l’utiliser : Pour réduire les risques d’erreurs, évitez d’utiliser des méthodes de déploiement qui nécessitent l’étape supplémentaire de synchronisation manuelle des déclencheurs. Utilisez un déploiement zip si possible.

Emplacement où le contenu de l’application est stocké : Le contenu de l’application est stocké sur le système de fichiers. Les déploiements FTP/FTPS échouent lorsque le système de fichiers de votre application est soutenu par Azure Files dans le compte de stockage hôte par défaut. FTP/FTPS échoue avec Azure Files en tant que stockage monté en raison des limitations de FTP.

Modification dans le portail

Dans l’éditeur du portail, vous pouvez modifier directement les fichiers dans votre application de fonction (en effectuant le déploiement essentiellement dès que vous enregistrez vos modifications).

Comment l'utiliser : Pour modifier vos fonctions dans le portail Azure, vous devez créer vos fonctions dans le portail. Pour garantir l’existence d’une seule source de confiance, l’utilisation d’une autre méthode de déploiement rend votre fonction accessible en lecture seule et empêche la poursuite de la modification dans le portail. Pour revenir à un état dans lequel vous pouvez modifier vos fichiers dans le portail Azure, vous pouvez réactiver manuellement le mode d’édition en Read/Write et supprimer tous les paramètres d’application liés au déploiement (comme WEBSITE_RUN_FROM_PACKAGE).

Quand l'utiliser : Le portail est un bon moyen de commencer avec Azure Functions. En raison des limitations de développement dans le portail Azure, vous devez utiliser l’un des outils clients suivants pour un travail de développement plus avancé :

Partout le contenu de l’application est stocké : le contenu de l’application est stocké sur le système de fichiers, qui peut être sauvegardé par Azure Files à partir du compte de stockage que vous spécifiez lors de la création de l’application de fonction.

Déploiement d’images de conteneur

Azure Functions sur Azure Container Apps déploie votre code sous forme d’image conteneur. Vous pouvez déployer depuis un projet de code en utilisant l’expérience gérée des Conteneurs Apps, ou déployer une image personnalisée lorsque vous avez besoin de contrôle sur le contenu de l’image. Pour plus d’informations, voir Créer une application de fonction sur Azure Container Apps using code et Azure Functions sur Azure Container Apps Overview.

Comportements de déploiement

Lorsque vous déployez des mises à jour de votre code d’application fonction, le comportement de déploiement dépend de votre plan d’hébergement.

Les fonctions en exécution actuelles s’arrêtent lorsque vous déployez du nouveau code. Après le déploiement, le nouveau code se charge et commence à traiter les requêtes. Ce comportement de suppression forcée est connu sous le nom de stratégie de recréation. Pour des déploiements avec un temps d’arrêt quasi nul, utilisez des slots de déploiement.

Passez en revue Améliorez les performances et la fiabilité d'Azure Functions pour apprendre à écrire des fonctions sans état et défensives.

Le comportement par défaut utilise la stratégie de recréation, qui arrête l’exécution de fonctions lors du déploiement. Flex Consumption prend en charge deux stratégies de mise à jour de site. Vous pouvez configurer les mises à jour propagées pour les déploiements sans temps d’arrêt.

Azure Container Apps gère les mises à jour des applications en utilisant des versions. Pour plus d’informations sur le contrôle de la manière dont les nouvelles versions reçoivent le trafic, voir Mettre à jour et déployer les changements dans Azure Container Apps.

Emplacements de déploiement

Flex Consumption ne prend pas en charge les emplacements de déploiement. Pour des déploiements sans interruption, configurez les mises à jour progressives.

Emplacements de déploiement

Lorsque vous déployez votre application de fonction sur Azure, vous pouvez le déployer sur un emplacement de déploiement distinct au lieu d’être directement en production. Le déploiement sur un emplacement de déploiement, puis l’échange en production après vérification est la méthode recommandée pour configurer déploiement continu.

La façon dont vous déployez sur un emplacement dépend de l’outil de déploiement spécifique que vous utilisez. Par exemple, lorsque vous utilisez Azure Functions Core Tools, incluez l’option --slot d’indiquer le nom d’un emplacement spécifique pour la func azure functionapp publish commande.

Pour plus d’informations sur les emplacements de déploiement, consultez la documentation Azure Functions Emplacements de déploiement.

Étapes suivantes

Lisez les articles suivants pour en savoir plus sur le déploiement de vos applications de fonction :

  • Last updated on