Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous planifiez et développez vos fonctions individuelles pour qu’elles s’exécutent dans Azure Functions, concentrez-vous sur le code lui-même. Azure Functions facilite le déploiement de votre projet de code dans une application de fonction dans Azure. Lorsque vous déployez votre projet sur une application de fonctions Linux, votre code s’exécute dans un conteneur qu’Azure Functions crée automatiquement pour vous. Ce conteneur s’intègre parfaitement aux outils de gestion des fonctions.
Functions prend également en charge les déploiements d’applications de fonction conteneurisées. Dans un déploiement conteneurisé, vous créez votre propre instance d’application de fonctions dans un conteneur Docker local à partir d’une image de base prise en charge. Vous pouvez ensuite déployer cette application de fonction conteneurisée dans un environnement d’hébergement dans Azure. La création de votre propre conteneur d’application de fonction vous permet de personnaliser ou de contrôler l’environnement d’exécution immédiat de votre code de fonction.
Important
Lorsque vous créez vos propres conteneurs, vous devez conserver l’image de base de votre conteneur mise à jour vers la dernière image de base prise en charge. Les images de base prises en charge pour Azure Functions sont spécifiques au langage. Consultez les dépôts d’images de base Azure Functions.
L’équipe Functions s’engage à publier des mises à jour mensuelles pour ces images de base. Les mises à jour régulières incluent les dernières mises à jour de version mineure et les correctifs de sécurité pour le runtime et les langages Functions. Vous devez régulièrement mettre à jour votre conteneur à partir de la dernière image de base et redéployer la version mise à jour de votre conteneur. Pour plus d’informations, consultez Gestion des conteneurs personnalisés.
Options d’hébergement de conteneur
Tip
Pour la plupart des charges de travail conteneurisées, hébergez vos applications de fonction dans Azure Container Apps. Container Apps offre un environnement entièrement géré, sans server, basé sur Kubernetes, avec une mise à l’échelle événementielle intégrée, un système de mise à l’échelle à zéro et un support GPU. Pour commencer, consultez Azure Functions on Azure Container Apps.
Vous disposez de plusieurs options pour héberger vos applications de fonctions conteneurisées dans Azure :
| Option d’hébergement | Benefits |
|---|---|
| Azure Container Apps (Recommended) | Azure Container Apps héberge et gère nativement vos conteneurs d’applications de fonctions en utilisant le fournisseur de Microsoft.App ressources. Faites tourner vos fonctions dans un environnement entièrement géré, serverless, basé sur Kubernetes, avec un support intégré pour la surveillance open source, mTLS, Dapr et KEDA. Prend en charge la facturation à l’échelle nulle, sans serveur payante-pour-ce que vous utilisez, le matériel dédié et les GPU via des profils de charge de travail. Vous bénéficiez du même modèle de programmation Fonctions et des mêmes déclencheurs tout en bénéficiant de l’ensemble des fonctionnalités des applications Container.
Option d’hébergement recommandée pour les applications de fonctions conteneurisées dans Azure. |
| Azure Container Apps (legacy) | Azure Functions offre un support intégré pour le déploiement d’applications de fonctions conteneurisées dans un environnement Conteneur Apps en utilisant le fournisseur de Microsoft.Web ressources. Bien que actuellement prise en charge, cette option est prévue pour une dépréciation future. Pour les nouvelles charges de travail, utilisez plutôt l’option recommandée d’hébergement des applications conteneures. |
| Azure Functions | Vous pouvez héberger vos applications de fonction conteneurisées dans Azure Functions en exécutant le conteneur dans un plan Elastic Premium ou App Service (dédié). L’hébergement de plan Premium vous offre les avantages de la mise à l’échelle dynamique. Vous pouvez utiliser l’hébergement de plan dédié pour tirer parti des ressources existantes du plan App Service inutilisées. |
| Kubernetes | Étant donné que le runtime Azure Functions offre une flexibilité en matière d’hébergement où et comment vous le souhaitez, vous pouvez héberger et gérer vos conteneurs d’applications de fonction directement dans des clusters Kubernetes. KEDA (mise à l’échelle automatique pilotée par des événements et basée sur Kubernetes) s’intègre de manière transparente avec le runtime et les outils Azure Functions pour fournir une mise à l’échelle pilotée par les événements dans Kubernetes. Important: L’hébergement Kubernetes de vos applications de fonction conteneurisées, à l’aide de KEDA ou par déploiement direct, est un effort open source que vous pouvez utiliser gratuitement. La prise en charge optimale de ce scénario d’hébergement est fournie uniquement par les contributeurs et par la communauté. Vous êtes responsable de la maintenance de vos propres conteneurs d’applications de fonction dans un cluster, même lors du déploiement sur Azure Kubernetes Service (AKS). |
Comparaison des fonctionnalités
Le degré auquel différentes fonctionnalités et comportements d’Azure Functions sont pris en charge lors de l’exécution de votre application de fonction dans un conteneur dépend de l’option d’hébergement de conteneur que vous choisissez.
| Feature/behavior | Conteneurs Apps (recommandé) | Conteneurs Apps (hérités)1 | Plan Premium | Plan dédié | Kubernetes |
|---|---|---|---|---|---|
| Prise en charge des produits | Yes | Yes | Yes | Yes | No |
| Intégration par portail des fonctions | Yes | No | Yes | Yes | No |
| Mise à l’échelle pilotée par les événements | Oui (règles d’échelle) | Yes5 | Yes | No | No |
| Échelle maximale (instances) | 10002 | 10002 | 1003 | 10-304 | Varie selon le groupe |
| Instances de mise à l’échelle jusqu'au zéro | Yes | Yes | No | No | KEDA |
| Limite de temps d’exécution | Unbounded6 | Unbounded6 | Unbounded7 | Unbounded8 | None |
| Déploiement de Core Tools | No | No | No | No | func kubernetes |
| Revisions | Yes | Yes | No | No | No |
| Emplacements de déploiement | No | No | Yes | Yes | No |
| Journaux de streaming | Yes | Yes | Yes | Yes | No |
| Accès à la console | Yes | Yes | Oui (en utilisant le Kudu) | Oui (en utilisant le Kudu) | Oui (dans les pods à l’aide de kubectl) |
| Atténuation du démarrage à froid | Règles de mise à l’échelle | Réplicas minimales | Instances toujours prêtes/préchauffées | n/a | n/a |
| Authentification App Service | Yes | Yes | Yes | Yes | No |
| Noms de domaines personnalisés | Yes | Yes | Yes | Yes | No |
| Certificats de clé privée | Yes | Yes | Yes | Yes | No |
| Réseaux virtuels | Yes | Yes | Yes | Yes | Yes |
| Zones de disponibilité | Yes | Yes | Yes | Yes | Yes |
| Diagnostics | Yes | Yes | Yes | Yes | No |
| Matériel dédié | Oui (profils de charge de travail) | Oui (profils de charge de travail) | No | Yes | Yes |
| GPU dédiés | Oui (profils de charge de travail) | Oui (profils de charge de travail) | No | No | Yes |
| Nombre de mémoire/processeur configurables | Yes | Yes | No | No | Yes |
| Option « subvention gratuite » | Yes | Yes | No | No | No |
| Détails de la tarification | Facturation Container Apps | Facturation Container Apps | Facturation du plan Premium | Facturation d’un plan dédié | Tarification AKS |
| Configuration requise du nom du service | 2-32 caractères : limités aux lettres minuscules, aux chiffres et aux traits d'union. Doit commencer par une lettre et terminiez par un caractère alphanumérique. | 2-32 caractères : limités aux lettres minuscules, aux chiffres et aux traits d'union. Doit commencer par une lettre et terminiez par un caractère alphanumérique. | Moins de 64 caractères : limité aux caractères alphanumériques et traits d’union. Ne peut pas commencer par ou se terminer par un trait d’union. | Moins de 64 caractères : limité aux caractères alphanumériques et traits d’union. Ne peut pas commencer par ou se terminer par un trait d’union. | Moins de 253 caractères : limité aux caractères alphanumériques et traits d’union. Doit commencer et se terminer avec un caractère alphanumérique. |
- Prévu pour une dépréciation future. Utilisez plutôt un hébergement natif d’applications conteneur.
- Sur Container Apps, la valeur par défaut est de 10 instances, mais vous pouvez définir le nombre maximal de réplicas, qui a un maximum global de 1 000. Ce paramètre est respecté tant qu’il y a suffisamment de quota de cœurs disponibles. Quand vous créez votre application de fonction depuis le portail Azure, vous êtes limité à 300 instances.
- Dans certaines régions, les applications Linux sur un plan Premium peuvent être mises à l’échelle sur 100 instances. Pour plus d’informations, consultez l’article sur le plan Premium.
- Pour connaître des limites spécifiques pour les différentes options de plan App Service, consultez les limites du plan App Service.
- Nécessite KEDA ; pris en charge par la plupart des déclencheurs. Pour savoir quels déclencheurs prennent en charge la mise à l’échelle pilotée par les événements, consultez Considérations relatives à l’hébergement de Container Apps.
- Lorsque le nombre minimal de réplicas est défini sur zéro, le délai d’expiration par défaut dépend des déclencheurs spécifiques utilisés dans l’application.
- Il n’existe aucun délai maximal d’expiration d’exécution appliqué. Toutefois, le délai de grâce accordé à l'exécution d'une fonction est de 60 minutes lors de la mise à l'échelle, et un délai de grâce de 10 minutes est accordé lors des mises à jour de la plateforme.
- Nécessite que le plan App Service soit défini sur Always On. Une période de grâce de 10 minutes est donnée pendant les mises à jour de la plateforme.
Gestion des conteneurs personnalisés
Lorsque vous créez vos propres conteneurs, gardez l’image de base de votre conteneur à jour avec la dernière image de base prise en charge. Les images de base prises en charge pour Azure Functions sont spécifiques au langage et se trouvent dans le référentiel d’images de base Azure Functions.
L’équipe Functions s’engage à publier des mises à jour mensuelles pour ces images de base. Les mises à jour régulières incluent les dernières mises à jour de version mineure et les correctifs de sécurité pour le runtime et les langages Functions. Mettez régulièrement à jour votre conteneur à partir de la dernière image de base et redéployez la version mise à jour de votre conteneur.
Choisissez votre image de base en fonction de la pile de langues que vous utilisez dans votre application de fonction. Le tableau suivant fournit des exemples pour chaque pile. En général, l’identifiant commence par 4- indiquer l’exécution des fonctions V4. Lorsque de nouvelles versions mineures sont publiées, ce tag est mis à jour pour indiquer la nouvelle version. Au fur et à mesure que vous reconstruisez périodiquement votre image personnalisée, vous transférez les nouvelles versions via ce même tag, afin que votre application ait les mêmes mises à jour. N’utilisez pas de balises qui spécifient des versions mineures à l’exécution, car ces tags ne reçoivent pas de mises à jour. Votre application peut potentiellement rester sur une version non patchée, peu importe la fréquence à laquelle vous reconstruisez votre image personnalisée.
| Pile de langues | Exemple de balises d’image de base recommandées |
|---|---|
| .NET (modèle Worker isolé) |
mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0 oumcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated8.0-appservice(Ces exemples ciblent .NET 8. Sélectionnez l’image appropriée pour la version .NET dont vous avez besoin.) |
| .NET (modèle in-process hérité) |
mcr.microsoft.com/azure-functions/dotnet:4-dotnet8.0 oumcr.microsoft.com/azure-functions/dotnet:4-dotnet8.0-appservice(Le support du modèle en cours prend fin le 10 novembre 2026. Migrez vers le modèle de travailleur isolé dès que possible.) |
| Java |
mcr.microsoft.com/azure-functions/java:4-java21 oumcr.microsoft.com/azure-functions/java:4-java21-appservice(Ces exemples ciblent Java 21. Sélectionnez l’image appropriée pour la version Java dont vous avez besoin.) |
| Node.js (JavaScript ou TypeScript) |
mcr.microsoft.com/azure-functions/node:4-node22 oumcr.microsoft.com/azure-functions/node:4-node22-appservice(Ces exemples ciblent Node.js 22. Sélectionnez l’image appropriée pour la version Node.js dont vous avez besoin.) |
| PowerShell |
mcr.microsoft.com/azure-functions/powershell:4-powershell7.4 oumcr.microsoft.com/azure-functions/powershell:4-powershell7.4-appservice(Ces exemples ciblent PowerShell 7.4. Sélectionnez l’image appropriée pour la version de PowerShell dont vous avez besoin.) |
| Python |
mcr.microsoft.com/azure-functions/python:4-python3.12 oumcr.microsoft.com/azure-functions/python:4-python3.12-appservice(Ces exemples ciblent Python 3.12. Sélectionnez l’image appropriée pour la version de Python dont vous avez besoin.) |
| Gestionnaires personnalisés/autres |
mcr.microsoft.com/azure-functions/base:4 oumcr.microsoft.com/azure-functions/base:4-appservice |
Les images de base se terminant par -appservice permettent l'activation de SSH et le débogage à distance depuis la plateforme. À moins que vous n’ayez besoin de ces fonctionnalités, utilisez les images de base sans suffixe -appservice .
Important
Il ne suffit pas d’avoir simplement l’un des tags précédents dans votre fichier Docker. Vous devez extraire régulièrement l’image la plus récente de cette balise afin que votre image personnalisée puisse être reconstruite pour inclure les dernières mises à jour. Si vous ne récupérez pas la dernière image et ne reconstruisez pas, votre application continue de fonctionner sur l’ancienne image de base.
Lorsque vous créez ou déployez votre propre application conteneurisée en utilisant une image personnalisée, vous êtes responsable de vous assurer que votre image personnalisée reste up-todate avec les images de base publiées. Outre les nouvelles fonctionnalités et améliorations, ces mises à jour d’images de base peuvent également inclure des mises à jour de sécurité critiques pour votre application. Pour vous assurer que votre application est protégée, vérifiez que vous restez à jour. Extrais régulièrement la dernière version de l’image de base, reconstruis ton image conteneur personnalisée, puis redéploye ton application pour l’utiliser.
Dans certains cas, Microsoft est tenu d’apporter des modifications au niveau de la plateforme qui pourraient signifier qu’une application dans un conteneur personnalisé utilisant une ancienne image de base pourrait cesser de fonctionner correctement. Pour de tels changements majeurs, Microsoft déploie des images mises à jour bien à l'avance afin que les applications qui reçoivent des mises à jour régulières ne soient pas affectées négativement. Pour éviter les problèmes potentiels liés à vos applications s’exécutant dans des conteneurs personnalisés, veillez à ne pas tomber trop loin derrière la dernière version mineure publiée. Lors d'un cas de support, si Microsoft détermine que votre application rencontre des problèmes parce qu'elle est sur une version plus ancienne ou non prise en charge, Microsoft vous demande de mettre à jour votre conteneur vers la dernière version de l'image de base avant de poursuivre le support.
Mise en route
Utilisez ces liens pour commencer à utiliser Azure Functions dans des conteneurs Linux :
| Je souhaite... | Consultez l’article : |
|---|---|
| Deploy functions to Azure Container Apps (recommandé) | Créer vos premières fonctions conteneurisée sur Azure Container Apps |
| Créer mes premières fonctions conteneurisées localement | Créer une application de fonction dans un conteneur Linux local |
| Déploiez des fonctions conteneurisées dans un plan Premium ou dédié | Créer votre première fonction Azure Functions conteneurisée |