Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Lorsque vous planifiez et développez vos fonctions individuelles pour qu’elles s’exécutent dans Azure Functions, vous êtes généralement concentré 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 fonction Linux, votre code s’exécute dans un conteneur qui est créé pour vous automatiquement et s’intègre en toute transparence aux outils de gestion Functions.
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 fonction dans un conteneur Docker local à partir d’une image basée sur 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
Il existe plusieurs options pour héberger vos applications de fonction conteneurisées dans Azure :
| Option d’hébergement | Benefits |
|---|---|
| Azure Container Apps | Azure Functions fournit une prise en charge intégrée pour le développement, le déploiement et la gestion d’applications de fonction conteneurisées sur Azure Container Apps. Cette intégration vous permet de gérer vos applications à l’aide des mêmes outils et pages Functions dans le portail Azure. Utilisez Azure Container Apps pour héberger votre conteneur d’applications de fonction dans le même environnement que d’autres microservices, API, sites web, flux de travail ou autres programmes hébergés par conteneur. L’hébergement Container Apps vous permet d’exécuter vos fonctions dans un environnement Kubernetes avec prise en charge intégrée de la surveillance open source, mTLS, Dapr et KEDA. Prend en charge la mise à l’échelle à zéro et fournit un modèle d’hébergement payant serverless. Vous pouvez également demander du matériel dédié, même des GPU, à l’aide de profils de charge de travail. Option d’hébergement recommandée pour les applications de fonction conteneurisées n Azure. |
| Clusters Kubernetes avec Azure Arc, utilisez (préversion). | Vous pouvez héberger vos applications de fonction sur des clusters Kubernetes avec Azure Arc en tant que déploiement en code uniquement ou dans un conteneur Linux personnalisé. Azure Arc vous permet d’attacher des clusters Kubernetes afin de pouvoir les gérer et les configurer dans Azure. L’hébergement de conteneurs Azure Functions sur des clusters Kubernetes avec Azure Arc est actuellement en préversion. Pour plus d’informations, consultez Utilisation des conteneurs et d’Azure Functions. |
| 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é). Utilisez l’hébergement Container Apps pour bénéficier d’une prise en charge enrichie des conteneurs à partir de Container Apps. 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 | Container Apps (intégré) | Container Apps (direct) | Plan Premium | Plan dédié | Kubernetes |
|---|---|---|---|---|---|
| Prise en charge des produits | Yes | No | Yes | Yes | No |
| Intégration du portail des fonctions | No | No | Yes | Yes | No |
| Mise à l’échelle pilotée par les événements | Yes5 | Oui (règles d’échelle) | Yes | No | No |
| Échelle maximale (instances) | 10001 | 10001 | 1002 | 10-303 | Varie selon le cluster |
| Instances de mise à l’échelle jusqu'au zéro | Yes | Yes | No | No | KEDA |
| Délai 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 (à l’aide de Kudu) | Oui (à l’aide de Kudu) | Oui (dans les pods à l’aide de kubectl) |
| Atténuation du démarrage à froid | Réplicas minimales | Règles de mise à l’échelle | 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 « octroi gratuit » | 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. |
- 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
Lors de la création de 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 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. 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.
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, la balise doit commencer 4- par indiquer le runtime V4 Functions. Lorsque de nouvelles versions mineures sont publiées, cette balise est mise à jour pour pointer vers la nouvelle version. Lorsque vous régénérez régulièrement votre image personnalisée, vous allez extraire les nouvelles versions via cette même balise, ce qui permet à votre application d’avoir les mêmes mises à jour. Vous ne devez pas utiliser de balises qui spécifient des versions d’exécution mineures, car elles ne recevront pas de mises à jour, et votre application restera potentiellement sur une version non corrigé, quelle que soit la fréquence à laquelle vous régénérez 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 prendra fin pour le modèle in-process le 10 novembre 2026. Vous devez migrer vers le modèle 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. Sauf si vous avez besoin de ces fonctionnalités, vous pouvez utiliser les images de base sans le -appservice suffixe.
Important
Il n’est pas suffisant d’avoir simplement l’une des balises ci-dessus dans votre fichier Dockerfile. 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 n’extrayez pas la dernière image et régénérez, votre application continuera à s’exécuter sur l’ancienne image de base.
Quand vous créez ou que vous déployez votre propre application conteneurisée en utilisant une image personnalisée, vous devez vous assurer que votre image personnalisée reste à jour avec nos 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. Vous devez extraire régulièrement la dernière version de l’image de base, reconstruire votre image conteneur personnalisée et redéployer votre application pour l’utiliser.
Dans certains cas, nous devons apporter des modifications au niveau de la plateforme, ce qui peut signifier qu’une application dans un conteneur personnalisé à l’aide d’une ancienne image de base peut cesser de fonctionner correctement. Pour ces changements majeurs, nous déployons des images mises à jour bien à l’avance afin que les applications qui prennent 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. Dans un cas de support, si nous déterminons que votre application rencontre des problèmes, car elle se trouve sur une version antérieure ou non prise en charge, nous vous demandons de mettre à jour votre conteneur vers la dernière version de l’image de base avant de poursuivre la prise en charge.
Mise en route
Utilisez ces liens pour commencer à utiliser Azure Functions dans des conteneurs Linux :
| Je souhaite... | Consultez l’article : |
|---|---|
| Créer mes premières fonctions conteneurisées | Créer une application de fonction dans un conteneur Linux local |
| Créer et déployer des fonctions sur Azure Container Apps | Créer vos premières fonctions conteneurisée sur Azure Container Apps |
| Créer et déployer des fonctions conteneurisées sur Azure Functions | Créer votre première fonction Azure Functions conteneurisée |