Technologies de déploiement dans Azure Functions
Vous pouvez utiliser plusieurs technologies différentes pour déployer le code de votre 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 exhaustive et des détails clés 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 sur 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 procéder à un déploiement 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 | • Publication Visual Studio Code • Publication Visual Studio • Publication Core Tools |
Déploiements pendant le développement et autres déploiements improvisés. Déploiement de votre code à la demande en utilisant des outils de développement locaux. |
| Géré par App Service | • Centre de déploiement (CI/CD) • Déploiements de conteneur |
Déploiement continu (CI/CD) à partir du contrôle de code source ou d’un registre de conteneurs. Les déploiements sont gérés par la plateforme App Service (Kudu). |
| Pipelines externes | • Azure Pipelines • GitHub Actions |
Pipelines de production qui comprennent une validation, des tests et d’autres actions devant être exécutées dans le cadre d’un déploiement automatisé. Les déploiements sont gérés par le pipeline. |
Les déploiements spécifiques doivent utiliser la meilleure technologie pour chaque scénario spécifique. La plupart des méthodes de déploiement sont basées sur un déploiement zip, qui est recommandé pour le déploiement.
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 :
- Plan Consommation flexible
- Consommation
- Plan Élastique Premium
- Plan dédié (App Service)
- Azure Container Apps
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 | Plan Consommation | Consommation | Premium élastique | Dédié | Applications de conteneur |
|---|---|---|---|---|---|
| OneDeploy | ✔ | ||||
| Déployer zip | ✔ | ✔ | ✔ | ||
| URL du package externe1 | ✔ | ✔ | ✔ | ||
| Conteneur Docker | Linux uniquement | Linux uniquement | Linux uniquement | ✔ | |
| Contrôle de code source | Windows uniquement | ✔ | ✔ | ||
| Git local1 | Windows uniquement | ✔ | ✔ | ||
| FTPS1 | Windows uniquement | ✔ | ✔ | ||
| Modification dans le portail2 | ✔ | ✔ | ✔ |
1 Les technologies de déploiement qui nécessitent la synchronisation manuelle des 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 de fonction 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.
Concepts clés
Certains concepts clés sont essentiels pour comprendre le fonctionnement des déploiements dans Azure Functions.
Synchronisation des déclencheurs
Quand vous changez l’un de vos déclencheurs, l’infrastructure Functions doit en être informée. La synchronisation s’effectue automatiquement pour la plupart des technologies de déploiement. Toutefois, dans certains cas, vous devez synchroniser manuellement les déclencheurs.
Vous devez synchroniser manuellement les déclencheurs lors de l’utilisation de ces options de déploiement :
Vous pouvez synchroniser des déclencheurs de l’une des manières suivantes :
Redémarrez votre application de fonction dans le portail Azure.
Utilisez la commande
az restpour envoyer une requête HTTP POST qui appelle l’APIsyncfunctiontriggers, 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
Lorsque vous déployez une version mise à jour du package de déploiement et que vous conservez la même URL de package externe, vous devez redémarrer manuellement votre application fonctionnelle. Cela indique à l’hôte qu’il doit synchroniser et redéployer vos mises à jour à partir de la même URL de package. Après le démarrage de l’application, l’hôte Functions effectue également une synchronisation de déclencheur en arrière-plan. Cependant, pour les plans d’hébergement Consommation et Premium élastique, vous devez également synchroniser manuellement les déclencheurs dans ces scénarios :
- Déploiements à l’aide d’une URL de package externe avec des modèles ARM ou Terraform.
- Lors de la mise à jour du package de déploiement à la même URL de package externe.
Build distante
Vous pouvez demander à Azure Functions d’effectuer une build distante de votre projet de code lors du déploiement. Dans ces scénarios, vous devez demander une build distante au lieu de générer localement :
- Vous déployez une application sur une application de fonction Linux qui a été développée sur un ordinateur Windows. C’est généralement le cas pour le développement des applications Python. Il peut arriver que des bibliothèques incorrectes soient utilisées quand la génération du package de déploiement est effectuée 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 ce que votre application s’exécute dans Azure sur Windows ou sur Linux.
Toutes les applications de fonction exécutées sur Windows ont une petite application de gestion, le site scm fourni par Kudu. Ce site gère une grande partie du déploiement et de la logique de build pour Azure Functions.
Quand une application est déployée sur Windows, les commandes spécifiques au langage, comme dotnet restore (C#) ou npm install (JavaScript), sont exécutées.
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. Toutefois, les options de déploiement sont limitées pour ces applications, car elles n’ont pas de site
scm(Kudu). - Les applications de fonction s’exécutant sur Linux dans un plan Premium ou dans un plan dédié (App Service) ont un site
scm(Kudu), mais il est limité par rapport à Windows. - Les builds distantes ne sont pas effectuées lorsqu’une application utilise d’exécution à partir d’un package. Pour savoir comment utiliser un build distante dans ces cas, consultez Zip Deploy.
- Il est possible que vous rencontriez des problèmes avec la build distante 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.
Stockage de contenu de l’application
Les méthodes de déploiement basées sur un package stockent le package dans le compte de stockage associé à l’application de fonction, qui est définie dans le paramètre AzureWebJobsStorage. Quand elles sont disponibles, les applications d’un plan Consommation et Élastique Premium essaient d’utiliser le partage de contenu Azure Files de ce compte, mais vous pouvez également conserver le package à un autre emplacement. Les applications d’un plan Consommation flexible utilisent à la place un conteneur de stockage dans un compte de stockage par défaut, sauf si vous configurez un compte de stockage différent à utiliser pour le déploiement. Pour plus d’informations, consultez, passez en revue les informations détaillées figurant dans Emplacement de stockage du contenu de l’application pour chaque technologie de déploiement abordée dans la section suivante.
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.
Description des technologies de déploiement
Les méthodes de déploiement décrites ci-après sont disponibles dans Azure Functions.
OneDeploy
OneDeploy est la seule technologie de déploiement prise en charge pour les applications sur le plan Consommation flexible. Le résultat final est un package .zip prêt à l’exécution sur lequel votre application de fonction s’exécute.
Comment l’utiliser : Déployer avec la fonctionnalité de publication de Visual Studio Code ou depuis la ligne de commande en utilisant Azure Functions Core Tools ou Azure CLI. Notre tâche Azure Dev Ops et GitHub Action tirent également parti de OneDeploy quand ils détectent qu’une application Consommation flexible y est déployée.
Quand vous créez une application Consommation flexible, vous devez spécifier un conteneur (blob) de stockage de déploiement ainsi qu’une méthode d’authentification. Par défaut, le même compte de stockage que la connexion
AzureWebJobsStorageest utilisé, avec une 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 : OneDeploy est la seule technologie de déploiement disponible pour les applications de fonction s’exécutant sur le plan Consommation flexible.
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. Il s’agit d’un conteneur d’objets blob où la plateforme va charger le contenu de l’application que vous avez déployée. Pour changer d’emplacement, vous pouvez consulter le panneau Paramètres de déploiement dans le portail Azure ou utiliser Azure CLI.
Déployer zip
ZipDeploy est la technologie de déploiement par défaut et qui est recommandée pour les applications de fonction sur les plans Consommation, Élastique Premium et App Service (dédié). 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 en ceci que notre plateforme est responsable de la génération à distance et du stockage du contenu de votre application.
Comment l’utiliser : Déployez en utilisant votre outil client habituel : Visual Studio Code, Visual Studio ou depuis la ligne de commande en utilisant Azure Functions Core Tools ou Azure CLI. Notre tâche Azure Dev Ops et GitHub Action tirent parti de façon similaire de ZipDeploy.
Quand vous effectuez le déploiement à l’aide de Zip Deploy, vous pouvez définir votre application pour qu’elle s’exécute en mode Exécuter à partir du package. Pour utiliser le mode Exécuter à partir du package, affectez au paramètre d’application
WEBSITE_RUN_FROM_PACKAGEla valeur1. Nous vous recommandons le déploiement zip. Il accélère les temps de chargement de vos applications, et il s’agit de la méthode par défaut pour VS Code, Visual Studio et Azure CLI.
Quand l’utiliser : ZipDeploy est la technologie de déploiement par défaut et qui est recommandée pour les applications de fonction sur les plans Consommation Windows, Élastique Premium Windows et Linux, et App Service (dédié) Windows et Linux.
Emplacement de stockage du contenu de l’application : par défaut, le contenu de l’application d’un déploiement zip est stocké sur le système de fichiers, qui peut être sauvegardé par Azure Files à partir du compte de stockage spécifié lors de la création de l’application de fonction. Dans Consommation Linux, le contenu de l’application est conservé sur un blob dans le compte de stockage spécifié par le paramètre d’application
AzureWebJobsStorageet le paramètre d’applicationWEBSITE_RUN_FROM_PACKAGEprend la valeur de l’URL du blob.
URL de package externe
URL de package externe est une option si vous voulez contrôler manuellement la façon dont les déploiements sont effectués. Vous avez la responsabilité du chargement d’un package .zip prêt à l’exécution contenant votre contenu d’application généré dans le stockage d’objets blob et du référencement de cette URL externe en tant que paramètre d’application sur votre application de fonction. Chaque fois que votre application redémarre, elle extrait le package, le monte et s’exécute en mode Exécuter à partir du package.
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 soit dans le portail, soit à l’aide d’Azure CLI.Si vous utilisez Stockage Blob Azure, votre application de fonction peut accéder au conteneur en utilisant une connexion basée sur une identité managée ou avec une signature d’accès partagé (SAP). 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. Reportez-vous à notre guide pratique sur la configuration de cette technologie de déploiement.
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 quand 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 d’objets 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 sur un plan Premium ou Dédié dans Azure Functions ou un autre hôte de conteneur. Utilisez Azure Functions Core Tools afin de créer un fichier Dockerfile personnalisé pour votre projet que vous utilisez pour la création une application de fonction conteneurisée. Vous pouvez utiliser le conteneur dans les déploiements suivants :
- Déployez sur les ressources Azure Functions que vous créez dans le Portail Azure. Si vous souhaitez obtenir plus d’informations, consultez Fonction de création du Portail Azure en utilisant des conteneurs.
- Déployez sur les ressources Azure Functions que vous créez à partir de la ligne de commande. Nécessite un plan Premium ou dédié (App Service). Pour savoir comment procéder, consultez Créer votre première fonction Azure Functions conteneurisée.
- Déployer vers Azure Container Apps. Pour savoir comment procéder, consultez Créer votre première fonction Azure Functions conteneurisée sur Azure Container Apps.
- Déployer sur Azure Arc (préversion). Pour savoir comment procéder, consultez Créer votre première fonction Azure Functions conteneurisée sur Azure Arc (préversion).
- Déployer sur un cluster Kubernetes. Vous pouvez déployer sur un cluster à l’aide d’Azure Functions Core Tools. Utilisez la commande
func kubernetes deploy.
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 de stockage du contenu de l’application : le contenu de l’application est stocké 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. Avec le contrôle de code source activé, 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. Le contrôle de code source est généralement activé sur un emplacement intermédiaire, qui peut être échangé en production après la validation des mises à jour à partir du référentiel. Pour plus d’informations, consultez l’article Emplacements de déploiement Azure Functions.
Emplacement de stockage du contenu de l’application : le contenu de l’application se trouve dans le système de contrôle de code source. Toutefois, un contenu d’application cloné et créé localement est stocké sur le système de fichiers de l’application, qui peut être sauvegardé par Azure Files à partir du compte de stockage spécifié lors de la création de l’application de fonction.
Git local
Vous pouvez utiliser Git local pour envoyer (push) le code de votre ordinateur local vers 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 le risque d’erreurs, vous devez éviter 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 de stockage du contenu de l’application : 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 spécifié lors de la création de l’application de fonction.
FTP/S
Vous pouvez utiliser FTP/S pour transférer directement des fichiers à Azure Functions, bien que cette méthode de déploiement ne soit pas recommandée. Si vous n’avez pas l’intention d’utiliser FTP, vous devez le désactiver. Si vous choisissez d’utiliser le protocole FTP, vous devez renforcer les protocoles FTPS. Pour savoir comment procéder dans le portail Azure, consultez Appliquer FTPS.
Comment l’utiliser : suivez les instructions de Paramètres de déploiement FTPS pour obtenir l’URL et les informations d’identification que vous pouvez utiliser pour déployer votre application de fonction avec FTPS.
Quand l’utiliser : pour réduire le risque d’erreurs, vous devez éviter 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 de stockage du contenu de l’application : 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 spécifié lors de la création de l’application de fonction.
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 avoir la possibilité de modifier vos fonctions dans le portail Microsoft Azure, vous devez avoir créé les 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 où vous pouvez modifier vos fichiers dans le portail Azure, vous pouvez rétablir manuellement le mode d’édition à
Read/Writeet supprimer tous les paramètres d’application relatifs au déploiement (commeWEBSITE_RUN_FROM_PACKAGE).
Quand l’utiliser ? Le portail est un excellent moyen de vous familiariser avec Azure Functions. Pour des travaux de développement plus avancés, nous vous recommandons d'utiliser l'un des outils clients suivants :
Emplacement de stockage du contenu de l’application : 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 spécifié lors de la création de l’application de fonction.
Le tableau suivant présente les systèmes d'exploitation et les langues qui prennent en charge l'édition dans le portail :
| Langage | Consommation Windows | Windows Premium | Dédié (Windows) | Consommation Linux | Linux Premium | Dédié (Linux) |
|---|---|---|---|---|---|---|
| C#1 | ||||||
| Java | ||||||
| JavaScript (Node.js) | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Python2 | ✔ | ✔ | ✔ | |||
| PowerShell | ✔ | ✔ | ✔ | |||
| TypeScript (Node.js) |
1 modification dans le portail n’est prise en charge que pour les fichiers de script C#, qui s’exécutent en cours avec l’hôte. Pour plus d’informations, consultez la référence du développeur Azure Functions script C# (.csx).
2 L'édition dans le portail n'est prise en charge que pour le modèle de programmation Python v1.
Comportements de déploiement
Lorsque vous déployez des mises à jour du code de vos applications de fonction, les fonctions en cours d’exécution sont arrêtées. Une fois le déploiement terminé, le nouveau code est chargé pour commencer à traiter les requêtes. Consultez Améliorer les performances et la fiabilité d’Azure Functions pour savoir comment écrire des fonctions sans état et défensives.
Si vous avez besoin de davantage de contrôle sur cette transition, vous devez utiliser des emplacements de déploiement.
Emplacements de déploiement
Quand vous déployez votre application de fonction sur Azure, vous pouvez choisir un autre emplacement de déploiement que directement l’emplacement de 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, vous incluez l’option--slot pour indiquer le nom d’un emplacement spécifique pour la commande func azure functionapp publish .
Pour plus d’informations sur les emplacements de déploiement, consultez la documentation sur les emplacements de déploiement Azure Functions.
Étapes suivantes
Lisez les articles suivants pour en savoir plus sur le déploiement de vos applications de fonction :