Partage via

Options de mise en réseau d’Azure Functions

  • Article

Cet article décrit les fonctionnalités de mise en réseau disponibles dans les options d’hébergement pour Azure Functions. Toutes les options de mise en réseau suivantes vous permettent d’accéder à des ressources sans utiliser d’adresses routables sur Internet, ou de restreindre l’accès à Internet à une application de fonction.

Les modèles d’hébergement offrent différents niveaux d’isolement réseau. Le choix de l’option appropriée vous aide à répondre à vos besoins d’isolement réseau.

Fonctionnalité Plan Consommation Plan de consommation flexible Plan Premium Plan dédié/ASE Applications de conteneur*
Restrictions d’adresse IP entrantes ✅Oui ✅Oui ✅Oui ✅Oui ✅Oui
Points de terminaison privés entrants ❌Non ✅Oui ✅Oui ✅Oui ❌Non
Intégration du réseau virtuel ❌Non ✅Oui (Zones géographiques) ✅Oui (Zones géographiques) ✅Oui (Zones géographiques et Passerelle) ✅Oui
Déclencheurs de réseau virtuel (non HTTP) ❌Non ✅Oui ✅Oui ✅Oui ✅Oui
Connexions hybrides (Windows uniquement) ❌Non ❌ Non ✅Oui ✅Oui ❌Non
Restrictions d’adresse IP sortantes ❌Non ✅Oui ✅Oui ✅Oui ✅Oui

*Pour plus d’informations, consultez Mise en réseau dans un environnement Azure Container Apps.

Ressources de démarrage rapide

Utilisez les ressources suivantes pour commencer rapidement à utiliser les scénarios de mise en réseau Azure Functions. Ces ressources sont référencées dans l’article.

Fonctionnalités réseau entrantes

Les fonctionnalités suivantes vous permettent de filtrer les demandes entrantes vers votre application de fonction.

Restrictions d’accès entrant

Vous pouvez utiliser des restrictions d’accès pour définir la liste des adresses IP classées par ordre de priorité qui sont autorisées ou non à accéder à votre application. La liste peut inclure des adresses IPv4 et IPv6 ou des sous-réseaux spécifiques de réseau virtuel utilisant des points de terminaison de service. Lorsqu’il y a une ou plusieurs entrées, une règle implicite « Tout refuser » se trouve à la fin de la liste. Les restrictions d’adresse IP fonctionnent avec toutes les options d’hébergement de fonction.

Les restrictions d’accès sont disponibles dans le plan Consommation flexible, Premium élastique, consommationet App Service.

Remarque

Une fois les restrictions réseau en place, vous pouvez uniquement déployer à partir de votre réseau virtuel ou après avoir ajouté l’adresse IP de la machine que vous utilisez pour accéder au portail Azure sur la liste des destinataires approuvés. Toutefois, vous pouvez toujours gérer la fonction à l’aide du portail.

Pour en savoir plus, consultez Restrictions d’accès statique Azure App Service.

Instances Private Endpoint

Le point de terminaison privé Azure est une interface réseau qui vous connecte de manière privée et sécurisée à un service s’appuyant sur Azure Private Link. Le point de terminaison privé utilise une adresse IP privée de votre réseau virtuel pour apporter le service à votre réseau virtuel de façon effective.

Vous pouvez utiliser un point de terminaison privé pour vos fonctions hébergées dans les plans Premium et App Service.

Si vous souhaitez effectuer des appels vers des points de terminaison privés, vous devez vous assurer que vos recherches DNS seront résolues sur le point de terminaison privé. Vous pouvez appliquer ce comportement de l’une des façons suivantes :

  • Intégrer à des zones privées Azure DNS Lorsque votre réseau virtuel n’a pas de serveur DNS personnalisé, cette opération est effectuée automatiquement.
  • Gérer le point de terminaison privé dans le serveur DNS utilisé par votre application. Pour ce faire, vous devez connaître l’adresse du point de terminaison privé, puis pointer le point de terminaison que vous essayez d’atteindre vers cette adresse à l’aide d’un enregistrement A.
  • Configurez votre propre serveur DNS pour le transfert vers des zones privées Azure DNS.

Pour plus d’informations, consultez Utilisation de points de terminaison privés pour Web Apps.

Pour appeler d’autres services qui disposent d’une connexion de point de terminaison privé, par exemple Stockage ou Service Bus, veillez à configurer votre application pour effectuer des appels sortants vers des points de terminaison privés. Pour plus d’informations sur l’utilisation de points de terminaison privés avec le compte de stockage de votre application de fonction, consultez restreindre votre compte de stockage à un réseau virtuel.

Points de terminaison de service

À l’aide de points de terminaison de service, vous pouvez limiter de nombreux services Azure à des sous-réseaux de réseau virtuel sélectionnés pour fournir un niveau de sécurité plus élevé. L’intégration au réseau virtuel régional permet à votre application de fonction d’atteindre les services Azure sécurisés avec les points de terminaison de service. Cette configuration est prise en charge sur tous les plans qui prennent en charge l’intégration du réseau virtuel. Pour accéder à un service sécurisé par point de terminaison de service, vous devez effectuer les opérations suivantes :

  1. Configurez l’intégration de réseau virtuel régional avec votre application de fonction pour vous connecter à un sous-réseau spécifique.
  2. Accédez au service de destination et configurez des points de terminaison de service sur le sous-réseau d’intégration.

Pour plus d’informations, consultez Points de terminaison de service de réseau virtuel.

Utiliser des points de terminaison de service

Pour restreindre l’accès à un sous-réseau spécifique, créez une règle de restriction avec le type Réseau virtuel. Vous pouvez ensuite sélectionner l’abonnement, le réseau virtuel et le sous-réseau auxquels vous souhaitez accorder ou refuser l’accès.

Si les points de terminaison de service ne sont pas déjà activés avec Microsoft.Web pour le sous-réseau que vous avez sélectionné, ils sont activés, sauf si vous cochez la case Ignorer les points de terminaison de service Microsoft.Web manquants. Le scénario dans lequel vous voudriez activer des points de terminaison de service sur l’application, mais pas sur le sous-réseau, dépend principalement du fait que vous disposiez ou non des autorisations pour les activer sur le sous-réseau.

Si vous avez besoin que quelqu’un d’autre active les points de terminaison de service sur le sous-réseau, cochez la case Ignorer les points de terminaison de service Microsoft.Web manquants. Votre application est configurée pour les points de terminaison de service en prévision de leur activation ultérieure sur le sous-réseau.

Capture d’écran du volet « Ajouter une restriction d’adresse IP » avec le type Réseau virtuel sélectionné.

Vous ne pouvez pas utiliser des points de terminaison de service pour restreindre l’accès aux applications qui s’exécutent dans un environnement App Service Environment. Si votre application se trouve dans un environnement App Service Environment, vous pouvez contrôler l’accès à celle-ci avec des règles d’accès IP.

Pour apprendre à configurer des points de terminaison de service, consultez Établir l’accès privé aux sites avec Azure Functions.

Intégration du réseau virtuel

L’intégration de réseau virtuel permet à votre Function App d’accéder aux ressources au sein d’un réseau virtuel. Azure Functions prend en charge deux types d’intégration de réseau virtuel :

  • Les niveaux tarifaires de calcul dédiés, y compris les niveaux Basic, Standard, Premium, Premium v2 et Premium v3.
  • App Service Environment qui se déploie directement dans votre réseau virtuel avec une infrastructure de prise en charge dédiée et utilise les niveaux tarifaires Isolated et v2.

La fonctionnalité d’intégration au réseau virtuel est utilisée dans les niveaux tarifaires de calcul dédiés Azure App Service. Si votre application se trouve dans Azure App Service Environment, elle est déjà dans un réseau virtuel et ne nécessite pas l’utilisation de la fonctionnalité d’intégration au réseau virtuel pour accéder aux ressources du même réseau virtuel. Pour plus d’informations sur toutes les fonctionnalités de mise en réseau, consultez Fonctionnalités de mise en réseau App Service.

L’intégration au réseau virtuel permet à votre application d’accéder aux ressources de votre réseau virtuel, mais sans pour autant accorder d’accès privé entrant à votre application à partir du réseau virtuel. L’accès aux sites privés fait référence au fait de rendre une application accessible uniquement à partir d’un réseau privé, par exemple à partir d’un réseau virtuel Azure. La fonctionnalité Intégration du réseau virtuel sert uniquement à passer des appels sortants de votre application vers votre réseau virtuel. La fonctionnalité Intégration du réseau virtuel se comporte différemment selon qu’elle est utilisée avec des réseaux virtuels de la même région ou avec des réseaux virtuels d’autres régions. Elle inclut deux variantes :

  • Intégration du réseau virtuel régional : quand vous vous connectez à des réseaux virtuels dans la même région, vous devez disposer d’un sous-réseau dédié dans le réseau virtuel avec lequel vous vous intégrez.
  • Intégration au réseau virtuel avec passerelle obligatoire :lors de la connexion directe à des réseaux virtuels dans d’autres régions ou à un réseau virtuel classique dans la même région, vous avez besoin d’une passerelle de réseau virtuel Azure créée dans le réseau virtuel cible.

La fonctionnalité d’intégration au réseau virtuel :

  • Nécessite un plan tarifaire De base ou Standard pris en charge, Premium, Premium v2, Premium v3 ou Elastic Premium App Service.
  • Prend en charge les protocoles TCP et UDP.
  • Fonctionne avec les applications App Service et les applications de fonction.

L’intégration au réseau virtuel ne prend pas en charge certaines choses, notamment :

  • Montage d’un lecteur.
  • Jointure de domaine Windows Server Active Directory.
  • NetBIOS.

L’intégration au réseau virtuel avec passerelle obligatoire fournit un accès aux ressources uniquement dans le réseau virtuel cible ou dans des réseaux connectés au réseau virtuel cible par Peering ou VPN. L’intégration au réseau virtuel avec passerelle obligatoire n’autorise pas l’accès aux ressources disponibles sur les connexions Azure ExpressRoute ni ne fonctionne avec des points de terminaison de service.

Quelle que soit la version utilisée, l’intégration au réseau virtuel permet à votre application d’accéder aux ressources de votre réseau virtuel, mais sans pour autant accorder d’accès privé entrant à votre application à partir du réseau virtuel. L’accès aux sites privés fait référence au fait de rendre votre application accessible uniquement à partir d’un réseau privé, par exemple à partir d’un réseau virtuel Azure. L'intégration au réseau virtuel sert uniquement à passer des appels sortants de votre application vers votre réseau virtuel.

Dans Azure Functions, l'intégration au réseau virtuel utilise une infrastructure partagée avec les applications Web App Service. Pour en savoir plus sur les deux types d'intégration au réseau virtuel, consultez :

Pour savoir comment configurer l’intégration d’un réseau virtuel, consultez Activer l’intégration d’un réseau virtuel.

Activer l’intégration du réseau virtuel Azure

  1. Dans votre application de fonction dans le Portail Azure, sélectionnez Réseau, puis sous Intégration à VNet, sélectionnez Cliquez ici pour configurer.

  2. Sélectionnez Ajouter un réseau virtuel.

    Sélectionner l’intégration au réseau virtuel

  3. La liste déroulante contient tous les réseaux virtuels Azure Resource Manager de votre abonnement dans la même région. Sélectionnez le réseau virtuel que vous voulez intégrer.

    Sélectionner le réseau virtuel

    • Les plans Consommation flexible Functions et Premium élastique prennent uniquement en charge l’intégration du réseau virtuel régional. Si le réseau virtuel se trouve dans la même région, créez un sous-réseau ou sélectionnez un sous-réseau préexistant vide.

    • Pour sélectionner un réseau virtuel dans une autre région, vous devez disposer d’une passerelle de réseau virtuel provisionnée dont l’option Point à site est activée. L’intégration du réseau virtuel entre les régions est uniquement prise en charge pour les plans dédiés, mais les peerings mondiaux fonctionnent avec l’intégration du réseau virtuel régional.

Lors de l’intégration, votre application est redémarrée. Une fois l’intégration terminée, vous pourrez voir des informations sur le réseau virtuel auquel vous êtes intégré. Par défaut, l’option Tout router est activée, et tout le trafic est routé vers votre réseau virtuel.

Si vous souhaitez que seul votre trafic privé (trafic RFC1918) soit routé, suivez les étapes fournies dans la documentation d’App Service.

Intégration du réseau virtuel régional

L’utilisation de l’intégration au réseau virtuel régional permet à votre application d’accéder aux :

  • Ressources dans le même réseau virtuel que votre application.
  • Ressources dans les réseaux virtuels appairés au réseau virtuel auquel votre application est intégrée.
  • Services sécurisés des points de terminaison de service.
  • Ressources sur des connexions Azure ExpressRoute.
  • Ressources sur des connexions appairées, notamment des connexions Azure ExpressRoute.
  • Instances Private Endpoint

Lorsque vous utilisez l’Intégration au réseau virtuel régional, vous pouvez utiliser les fonctionnalités de mise en réseau Azure suivantes :

  • Groupes de sécurité réseau (NSG) : Vous pouvez bloquer le trafic sortant avec un groupe de sécurité réseau placé sur votre sous-réseau d’intégration. Les règles de trafic entrant ne s’appliquent pas, car vous ne pouvez pas utiliser l’intégration au réseau virtuel pour fournir un accès entrant à votre application.
  • Tables de routage (Routes définies par l’utilisateur) : Vous pouvez placer une table de routage sur le sous-réseau d’intégration pour envoyer le trafic sortant où vous voulez.

Notes

Lorsque vous routez tout le trafic sortant vers votre réseau virtuel, il est soumis aux groupes de sécurité réseau et aux routes définies par l’utilisateur appliqués à votre sous-réseau d’intégration. Lorsque le réseau virtuel est intégré, le trafic sortant de votre application de fonction vers des adresses IP publiques est toujours envoyé à partir des adresses listées dans les propriétés de votre application, sauf si vous fournissez des routes qui dirigent le trafic ailleurs.

L’intégration au réseau virtuel régional ne peut pas utiliser le port 25.

Pour le plan Consommation flexible :

  1. Vérifiez que le fournisseur de ressources Azure Microsoft.App est activé pour votre abonnement en suivant ces instructions. La délégation de sous-réseau nécessaire pour les applications Consommation flexible est Microsoft.App/environments.
  2. La délégation de sous-réseau nécessaire pour les applications Consommation flexible est Microsoft.App/environments. Il s’agit d’une modification de Premium élastique et d’App Service qui ont une exigence de délégation différente.
  3. Vous pouvez planifier l’utilisation de 40 adresses IP au maximum pour une application de fonction, même si l’application est mise à l’échelle au-delà de 40. Par exemple, si vous avez quinze applications de fonction Consommation flexible qui seront intégrées au réseau VNet dans le même sous-réseau, vous pouvez planifier l’utilisation de 15 x 40 = 600 adresses IP au maximum. Cette limite est sujette à modification et n’est pas appliquée.
  4. Le sous-réseau ne peut pas déjà être utilisé à d’autres fins (par exemple, des points de terminaison privés ou de service, ou délégués à tout autre plan ou service d’hébergement). Bien que vous puissiez partager le même sous-réseau avec plusieurs applications Consommation flexible, les ressources réseau seront partagées entre ces applications de fonction, ce qui peut avoir un impact sur les performances des autres applications de fonction sur le même sous-réseau.

Il existe certaines limitations concernant l’utilisation du réseau virtuel :

  • La fonctionnalité est disponible sur Consommation flexible, Premium élastique et App Service Premium V2 et Premium V3. Elle est également disponible au niveau Standard, mais uniquement pour les déploiements App Service les plus récents. Si vous utilisez un déploiement plus ancien, vous ne pourrez utiliser la fonctionnalité qu’à partir d’un plan App Service Premium V2. Si vous souhaitez vous assurer de pouvoir utiliser la fonctionnalité dans un plan App Service Standard, créez votre application dans un plan App Service Premium v3. Ces plans ne sont pris en charge que sur les déploiements les plus récents. Vous pouvez effectuer un scale-down par la suite si vous le souhaitez.
  • Le sous-réseau d’intégration peut être utilisé par un seul plan App Service.
  • La fonctionnalité ne peut pas être utilisée par des applications de plan Isolé qui se trouvent dans un environnement App Service.
  • La fonctionnalité nécessite un sous-réseau inutilisé /28 ou d’une taille supérieure dans un réseau virtuel Azure Resource Manager.
  • L’application et le réseau virtuel doivent se trouver dans la même région.
  • Vous ne pouvez pas supprimer un réseau virtuel avec une application intégrée. Supprimez l’intégration avant de supprimer le réseau virtuel.
  • Vous pouvez disposer de jusqu’à deux intégrations au réseau virtuel régional par plan App Service. Plusieurs applications d’un même plan App Service peuvent utiliser le même sous-réseau d’intégration.
  • Vous ne pouvez pas changer l’abonnement d’une application ou d’un plan quand une application utilise l’intégration au réseau virtuel régional.

Sous-réseaux

L’intégration au réseau virtuel dépend d’un sous-réseau dédié. Lorsque vous approvisionnez un sous-réseau, le sous-réseau Azure perd cinq adresses IP dès le début. Pour les plans Premium élastique et App Service, une adresse est utilisée à partir du sous-réseau d’intégration pour chaque instance de plan. Lorsque vous définissez l’échelle de votre application sur quatre instances, quatre adresses sont utilisées. Pour Consommation flexible, cela ne s’applique pas et les instances partagent les adresses IP.

Lorsque vous en augmentez ou diminuez la taille, l’espace d’adressage requis est doublé pendant une brève période de temps. Cela affecte les instances prises en charge réelles et disponibles pour une taille de sous-réseau donnée. Le tableau suivant indique à la fois le nombre maximal d’adresses disponibles par bloc CIDR et l’effet sur la mise à l’échelle horizontale :

Taille de bloc CIDR Nombre maximal d’adresses disponibles Mise à l’échelle horizontale maximale (instances)*
/28 11 5
/27 27 13
/26 59 29

*Supposez que vous deviez effectuer un scale-up ou un scale-down en taille ou en SKU à un moment donné.

Comme la taille du sous-réseau ne peut pas être modifiée après l’affectation, utilisez un sous-réseau suffisamment grand pour s’adapter à l’échelle que votre application est susceptible d’atteindre. Pour éviter tout problème de capacité de sous-réseau pour les plans Premium élastique Functions, vous devez utiliser un /24 avec 256 adresses pour Windows et un /26 avec 64 adresses pour Linux. Lors de la création de sous-réseaux dans le Portail Azure dans le cadre de l’intégration au réseau virtuel, une taille minimale de /24 pour Windows et /26 pour Linux est requise.

Lorsque vous voulez que les applications d’un autre plan atteignent un réseau virtuel auquel sont déjà connectées des applications d’un autre plan, sélectionnez un sous-réseau différent de celui utilisé par l’intégration au réseau virtuel préexistante.

La fonctionnalité est entièrement prise en charge pour les applications Windows et Linux, notamment les conteneurs personnalisés. Tous les comportements sont identiques entre les applications Windows et les applications Linux.

Groupes de sécurité réseau

Vous pouvez utiliser des groupes de sécurité réseau pour bloquer le trafic entrant et sortant vers des ressources d’un réseau virtuel. Une application utilisant l’intégration au réseau virtuel régional peut utiliser un groupe de sécurité réseau pour bloquer le trafic sortant vers des ressources dans votre réseau virtuel ou sur Internet. Pour bloquer le trafic vers des adresses publiques, vous devez disposer de l’intégration de réseau virtuel avec l’option Tout router activée. Les règles de trafic entrant dans un groupe de sécurité réseau ne s’appliquent pas à votre application, car l’intégration au réseau virtuel n’a d’incidence que sur le trafic sortant depuis votre application.

Pour contrôler le trafic entrant vers votre application, utilisez la fonctionnalité Restrictions d’accès. Un groupe de sécurité réseau appliqué à votre sous-réseau d’intégration est actif quelles que soient les routes appliquées à votre sous-réseau d’intégration. Si votre application de fonction est intégrée à un réseau virtuel avec l’option Tout router activée, et que vous n’avez aucune route affectant le trafic des adresses publiques sur votre sous-réseau d’intégration, l’ensemble du trafic sortant est toujours soumis aux groupes de sécurité réseau affectés à votre sous-réseau d’intégration. Lorsque l’option Tout router n’est pas activée, les groupes de sécurité réseau sont appliqués uniquement au trafic RFC1918.

Itinéraires

Vous pouvez utiliser des tables de routage pour router le trafic sortant depuis votre application vers où vous voulez. Par défaut, les tables de routage affectent seulement votre trafic de destination RFC1918. Lorsque l’option Tout router est activée, tous vos appels sortants sont affectés. Lorsque Tout router est désactivé, seul le trafic privé (RFC1918) est concerné par vos tables de routage. Les routes définies sur votre sous-réseau d’intégration n’affectent pas les réponses aux requêtes d’application entrantes. Les destinations courantes peuvent inclure des pare-feu ou des passerelles.

Si vous souhaitez router tout le trafic sortant localement, vous pouvez utiliser une table de route pour envoyer l’intégralité du trafic sortant vers votre passerelle ExpressRoute. Si vous choisissez de router le trafic vers une passerelle, veillez à définir des routes dans le réseau externe pour renvoyer des réponses.

Les routes BGP (Border Gateway Protocol) affectent également le trafic de votre application. Si vous avez des routes BGP provenant par exemple d’une passerelle ExpressRoute, le trafic sortant de votre application est affecté. Par défaut, les routes BGP affectent seulement votre trafic de destination RFC1918. Lorsque votre application de fonction est intégrée à un réseau virtuel avec l’option Tout router activée, tout le trafic sortant peut être affecté par vos routes BGP.

Zones privées Azure DNS

Une fois que votre application s’intègre à votre réseau virtuel, elle utilise le serveur DNS avec lequel votre réseau virtuel est configuré et fonctionne avec les zones privées Azure DNS liées au réseau virtuel.

Restreindre votre compte de stockage à un réseau virtuel

Notes

Pour déployer rapidement une application de fonction avec des points de terminaison privés activés sur le compte de stockage, reportez-vous au modèle suivant : Application de fonction avec points de terminaison privés du Stockage Azure.

Quand vous créez une application de fonction, vous devez créer un compte de stockage Azure à usage général qui prend en charge le stockage Blob, File d’attente et Table, ou établir un lien vers un compte de ce type. Vous pouvez remplacer ce compte de stockage par un compte sécurisé avec des points de terminaison de service ou privés.

Cette fonctionnalité est prise en charge pour toutes les références SKU prises en charge par le réseau virtuel Windows et Linux dans le plan Dédié (App Service) et pour les plans Premium élastique, ainsi que pour le plan Consommation flexible. Le plan Consommation n’est pas pris en charge. Pour savoir comment configurer une fonction avec un compte de stockage limité à un réseau privé, consultez Restreindre votre compte de stockage à un réseau virtuel.

Utiliser des références Key Vault

Vous pouvez utiliser des références Azure Key Vault pour utiliser des secrets d’Azure Key Vault dans votre application Azure Functions, sans avoir à modifier le code. Azure Key Vault est un service qui fournit une gestion centralisée des secrets, avec un contrôle total sur les stratégies d’accès et l’historique d’audit.

Si l’intégration de réseau virtuel est configurée pour l’application, des références Key Vault peuvent être utilisées pour récupérer des secrets d’un coffre avec restrictions de réseau.

Déclencheurs de réseau virtuel (non HTTP)

Vous pouvez utiliser des fonctions de déclencheur non-HTTP à partir d’un réseau virtuel de deux manières :

  • Exécutez votre application de fonction dans un Plan Premium élastique, et activez la prise en charge des déclencheurs de réseau virtuel.
  • Exécutez votre application de fonction dans un plan Consommation flexible un plan App Service ou un environnement App Service.

Plan Premium élastique avec déclencheurs de réseau virtuel

Le plan Premium élastique vous permet de créer des fonctions déclenchées par des services à l’intérieur d’un réseau virtuel. Ces déclencheurs non HTTP sont appelés déclencheurs de réseau virtuel.

Par défaut, les déclencheurs de réseau virtuel n’entraînent pas la mise à l’échelle de votre application de fonction au-delà de leur nombre d’instances préchauffées. Toutefois, certaines extensions prennent en charge des déclencheurs de réseau virtuel qui entraînent la mise à l’échelle dynamique de votre application de fonction. Vous pouvez activer cette surveillance à l’échelle dynamique dans votre application de fonction pour les extensions prises en charge de l’une des manières suivantes :

  1. Sur le portail Azure, accédez à votre application de fonction.

  2. Sous Paramètres, sélectionnez Configuration, puis dans l’onglet Paramètres d’exécution de la fonction définissez la Supervision de l'échelle de runtime sur Activée.

  3. Sélectionnez Enregistrer pour mettre à jour la configuration de l’application de fonction et redémarrer l’application.

VNETToggle

Conseil

L’activation de l’analyse des déclencheurs de réseau virtuel peut avoir un impact sur les performances de votre application, bien que cet impact soit probablement très faible.

La prise en charge de la surveillance dynamique des déclencheurs de réseau virtuel n’est pas disponible dans la version 1.x du runtime Fonctions.

Les extensions de cette table prennent en charge la surveillance dynamique de l’échelle des déclencheurs de réseau virtuel. Pour obtenir les meilleures performances de mise à l’échelle, vous devez effectuer une mise à niveau vers des versions qui prennent également en charge la mise à l’échelle basée sur des cibles.

Extension (version minimale) Surveillance de l’échelle du runtime uniquement Avec mise à l’échelle basée sur des cibles
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 n/a
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Uniquement avec le stockage de file d'attente.

Important

Lorsque vous activez la surveillance des déclencheurs de réseau virtuel, seuls les déclencheurs pour ces extensions peuvent entraîner la mise à l’échelle dynamique de votre application. Vous pouvez toujours utiliser les déclencheurs qui ne figurent pas dans le tableau, mais ils ne sont pas mis à l’échelle au-delà de leur nombre d’instances préchauffées. Pour obtenir la liste complète de toutes les extensions de déclencheur et de liaison, consultez Déclencheurs et liaisons.

Plan App Service et App Service Environment avec déclencheurs de réseau virtuel

Lorsque votre application de fonction s’exécute dans un plan App Service ou un App Service Environment, vous pouvez utiliser des fonctions de déclencheur non-HTTP. Pour le bon déclenchement de vos fonctions, vous devez être connecté à un réseau virtuel, avec accès à la ressource définie dans la connexion de déclenchement.

Supposons, par exemple, que vous souhaitiez configurer Azure Cosmos DB pour accepter le trafic uniquement à partir d’un réseau virtuel. Dans ce cas, vous devez déployer votre application de fonction dans un plan App Service fournissant une intégration de réseau virtuel à ce réseau virtuel. L’intégration permet donc qu’une fonction soit déclenchée par cette ressource Azure Cosmos DB.

les connexions hybrides

Connexions hybrides est une fonctionnalité d’Azure Relay que vous pouvez utiliser pour accéder aux ressources d’application dans d’autres réseaux. Elles permettent d’accéder depuis votre application à un point de terminaison d’application. Vous ne pouvez pas l’utiliser pour accéder à votre application. La fonctionnalité Connexions hybrides est disponible pour les fonctions exécutées sur Windows dans tous les plans, sauf le plan Consommation.

Utilisée dans Azure Functions, chaque connexion hybride correspond à une combinaison d’hôte et de port TCP unique. Cela signifie que le point de terminaison de connexion hybride peut se trouver sur un quelconque système d’exploitation et toute application tant que vous accédez à un port d’écoute TCP. La fonctionnalité Connexions hybrides ne détecte pas et ne prend pas en compte le protocole d’application ou les ressources auxquels vous accédez. Elle fournit simplement un accès réseau.

Pour plus d’informations, consultez la documentation App Service pour les connexions hybrides. Ces mêmes étapes de configuration prennent en charge Azure Functions.

Important

Les connexions hybrides sont uniquement prises en charge dans les plans Windows. Linux n’est pas pris en charge.

Restrictions d’adresse IP sortantes

Les restrictions d’adresse IP sortante sont disponibles dans un plan Consommation flexible, un plan Premium élastique, un plan App Service ou un environnement App Service. Vous pouvez configurer des restrictions sortantes pour le réseau virtuel sur lequel votre Azure App Service Environment est déployé.

Lorsque vous intégrez une application de fonction à un réseau virtuel dans le cadre d’un plan Premium élastique ou App Service, l’application est toujours en mesure de passer des appels sortants vers Internet par défaut. En intégrant votre application de fonction à un réseau virtuel avec l’option Tout router activée, vous forcez l’envoi de tout le trafic sortant vers votre réseau virtuel, où des règles de groupe de sécurité réseau peuvent être utilisées pour restreindre le trafic. Pour Consommation flexible, tout le trafic est déjà routé via le réseau virtuel et Router tout n’est pas nécessaire.

Pour savoir comment contrôler l’adresse IP sortante à l’aide d’un réseau virtuel, consultez Tutoriel : Contrôler l’adresse IP sortante Azure Functions avec une passerelle NAT de réseau virtuel Azure.

Automatisation

Les API suivantes vous permettent de gérer par programmation les intégrations de réseaux virtuels régionaux :

Considérations relatives aux tests

Lorsque vous testez des fonctions dans une application de fonction avec des points de terminaison privés, vous devez effectuer vos tests à partir du même réseau virtuel, par exemple sur une machine virtuelle de ce réseau. Pour utiliser l’option Code + Test dans le portail à partir de cette machine virtuelle, vous devez ajouter les origines CORS suivantes à votre application de fonction :

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

Si vous avez restreint l’accès à votre application de fonction avec des points de terminaison privés ou toute autre restriction d’accès, vous devez également ajouter l’étiquette de service AzureCloud à la liste verte. Pour mettre à jour la liste verte :

  1. Accédez à l’application de votre fonction et sélectionnez Paramètres>Mise en réseau, puis sélectionnez Configuration de l’accès entrant>Accès réseau public.

  2. Vérifiez que Accès au réseau public est défini sur Activé à partir de la sélection des réseaux virtuels et des adresses IP.

  3. Ajouter une règle sous Accès au site et règles :

    1. Sélectionnez Service Tag en tant que Typede paramètres source et AzureCloud comme Balise de service.

    2. Vérifiez que l’action est Autoriser, puis définissez le nom et la priorité souhaités.

Dépannage

Cette fonctionnalité est facile à configurer, mais il est possible que vous rencontriez des problèmes. Si vous rencontrez des difficultés pour accéder au point de terminaison souhaité, certains utilitaires vous permettent de tester la connectivité à partir de la console de l’application. Vous pouvez utiliser deux consoles : la console Kudu et la console du Portail Azure. Pour accéder à la console Kudu à partir de votre application, accédez à Outils>Kudu. Vous pouvez également accéder à la console Kudo via le site [nom du site].scm.azurewebsites.net. Une fois le site chargé, accédez à l’onglet Console de débogage. Pour accéder à la console hébergée par le Portail Azure à partir de votre application, accédez à Outils>Console.

Outils

Dans les applications Windows natives, les outils ping, nslookup et tracert ne fonctionnent pas dans la console en raison de contraintes de sécurité (ils fonctionnent dans des conteneurs Windows personnalisés). Deux outils distincts ont été ajoutés pour les remplacer. Pour tester les fonctionnalités DNS, nous avons ajouté un outil nommé nameresolver.exe. La syntaxe est :

nameresolver.exe hostname [optional: DNS Server]

Vous pouvez utiliser nameresolver pour vérifier les noms d’hôte dont dépend votre application. De cette façon, vous pouvez tester si des éléments de votre serveur DNS sont mal configurés ou si vous n’avez pas accès à votre serveur DNS. Vous pouvez identifier le serveur DNS qu’utilise votre application dans la console en examinant les variables d’environnement WEBSITE_DNS_SERVER et WEBSITE_DNS_ALT_SERVER.

Notes

L’outil nameresolver.exe ne fonctionne pas actuellement dans les conteneurs Windows personnalisés.

Vous pouvez utiliser l’outil suivant pour tester la connectivité TCP avec une combinaison hôte-port. Il s’agit de l’outil tcpping, dont la syntaxe est la suivante :

tcpping.exe hostname [optional: port]

L’utilitaire tcpping vous indique si vous pouvez atteindre un hôte et un port spécifiques. Il ne peut réussir que si une application écoute au niveau de la combinaison hôte-port et si l’accès réseau de votre application à l’hôte et au port spécifiés est disponible.

Déboguer l’accès aux ressources hébergées sur un réseau virtuel

Plusieurs choses peuvent empêcher votre application d’atteindre un hôte et un port spécifiques. La plupart du temps, il s’agit de l’une des trois raisons suivantes :

  • Un pare-feu se trouve sur le trajet. Si vous utilisez un pare-feu sur le trajet, vous dépassez le délai d’expiration TCP. Dans ce cas, il est de 21 secondes. Utilisez l’outil tcpping pour tester la connectivité. Les délais d’expiration TCP peuvent avoir de nombreuses autres origines, mais commencez par vérifier ce point.
  • DNS n’est pas accessible. Le délai d’expiration DNS est de 3 secondes par serveur DNS. Si vous avez deux serveurs DNS, le délai d’expiration est de 6 secondes. Utilisez nameresolver pour vérifier que le DNS fonctionne correctement. Vous ne pouvez pas utiliser nslookup, car il n’utilise pas le DNS avec lequel votre réseau virtuel est configuré. S’il n’est pas accessible, il se peut qu’un pare-feu ou un groupe de sécurité réseau (NSG) bloque l’accès au DNS ou que celui-ci est inopérant.

Si ces éléments ne suffisent pas à résoudre vos problèmes, commencez par vous poser les questions suivantes :

Intégration du réseau virtuel régional

  • Votre destination est-elle une adresse non RFC1918 sans l’Itinéraire activé ?
  • Y a-t-il un groupe de sécurité réseau qui bloque la sortie de votre sous-réseau d’intégration ?
  • Si elle transite par Azure ExpressRoute ou un VPN, votre passerelle locale est-elle configurée pour réacheminer le trafic vers Azure ? Si vous pouvez accéder à des points de terminaison dans votre réseau virtuel, mais pas en local, vérifiez vos routes.
  • Disposez-vous d’autorisations suffisantes pour définir la délégation sur le sous-réseau d’intégration ? Durant la configuration de l’intégration au réseau virtuel régional, votre sous-réseau d’intégration est délégué à Microsoft.Web/serverFarms. L’interface utilisateur de l’intégration au réseau virtuel délègue automatiquement le sous-réseau à Microsoft.Web/serverFarms. Si votre compte ne dispose pas d’autorisations de mise en réseau suffisantes pour définir la délégation, vous devez demander à une personne autorisée de configurer les attributs de votre sous-réseau d’intégration de manière à déléguer celui-ci. Pour déléguer manuellement le sous-réseau d’intégration, accédez à l’interface utilisateur du sous-réseau de Réseau virtuel Microsoft Azure et définissez la délégation sur Microsoft.Web/serverFarms.

Intégration au réseau virtuel avec passerelle obligatoire

  • La plage d’adresses de point à site se trouve-t-elle dans les plages RFC 1918 (10.0.0.0 à 10.255.255.255, 172.16.0.0 à 172.31.255.255 ou 192.168.0.0 à 192.168.255.255) ?
  • Le portail indique-t-il que la passerelle fonctionne ? Si votre passerelle est en panne, rétablissez-la.
  • Les certificats apparaissent-ils comme étant synchronisés ou soupçonnez-vous une modification de la configuration réseau ? Si vos certificats ne sont pas synchronisés ou si vous pensez qu’une modification apportée à la configuration de votre réseau virtuel n’a pas été synchronisée avec vos ASP, sélectionnez Synchroniser le réseau.
  • Si vous utilisez un VPN, la passerelle locale est-elle configurée pour réacheminer le trafic vers Azure ? Si vous pouvez accéder à des points de terminaison dans votre réseau virtuel, mais pas en local, vérifiez vos routes.
  • Essayez-vous d’utiliser une passerelle de coexistence qui prend en charge à la fois la connectivité point à site et la connectivité ExpressRoute ? Les passerelles de coexistence ne sont pas prises en charge avec l’intégration au réseau virtuel.

Le débogage des problèmes de mise en réseau constitue un défi, car cette opération ne vous permet pas de voir ce qui bloque l’accès à une combinaison hôte-port spécifique. Les causes peuvent inclure :

  • Un pare-feu activé sur l’hôte empêche l’accès au port de l’application à partir de votre plage d’adresses IP de point à site. Des sous-réseaux croisés requièrent souvent un accès public.
  • Votre hôte cible est hors-service.
  • Votre application est arrêtée.
  • L’IP ou le nom d’hôte sont incorrects.
  • Votre application est à l’écoute sur un port autre que celui auquel vous vous attendiez. Vous pouvez faire correspondre votre ID de processus avec le port d’écoute en utilisant « netstat -aon » sur l’hôte du point de terminaison.
  • Vos groupes de sécurité réseau sont configurés de telle sorte qu’ils empêchent l’accès à l’hôte et au port de votre application à partir de votre plage d’adresses IP de point à site.

Vous ne savez pas quelle adresse votre application utilise réellement. Cela peut être n’importe quelle adresse de la plage d’adresses de sous-réseau d’intégration ou de point à site. De ce fait, vous devez autoriser l’accès depuis toutes les adresses de la plage.

Voici d’autres étapes de débogage :

  • Connectez-vous à une machine virtuelle de votre réseau virtuel et essayez d’atteindre la combinaison hôte-port de vos ressources. Pour tester l’accès à TCP, utilisez la commande PowerShell Test-NetConnection. La syntaxe est :
Test-NetConnection hostname [optional: -Port]
  • Démarrez une application sur une machine virtuelle, puis testez l’accès à ces hôte et port à partir de la console de votre application en utilisant l’outil tcpping.

Ressources locales

Si votre application ne peut pas accéder à une ressource locale, vérifiez si vous pouvez atteindre la ressource à partir de votre réseau virtuel. Utilisez la commande PowerShell Test-NetConnection pour vérifier l’accès à TCP. Si votre machine virtuelle ne peut pas accéder à votre ressource locale, votre connexion VPN ou ExpressRoute n’est peut-être pas configurée correctement.

Si votre machine virtuelle hébergée sur le réseau virtuel peut atteindre votre système local, mais que votre application ne le peut pas, la raison en est probablement l’une des suivantes :

  • Vos routes ne sont pas configurés avec vos plages d’adresses de sous-réseau ou de point à site dans votre passerelle locale.
  • Vos groupes de sécurité réseau bloquent l’accès de votre plage d’adresses IP de point à site.
  • Vos pare-feu locaux bloquent le trafic provenant de votre plage d’adresses IP de point à site.
  • Vous tentez d’atteindre une adresse non RFC 1918 en utilisant la fonctionnalité d’intégration au réseau virtuel régional.

Suppression du plan App Service ou de l’application web avant la déconnexion de l’intégration au réseau virtuel

Si vous supprimez l’application web ou le plan App Service sans déconnecter l’intégration au réseau virtuel au préalable, vous ne pourrez pas effectuer d’opérations de mise à jour/suppression sur le réseau virtuel ou le sous-réseau utilisé pour l’intégration avec la ressource supprimée. Une délégation de sous-réseau « Microsoft.Web/serverFarms » restera attribuée à votre sous-réseau et empêchera les opérations de mise à jour/suppression.

Afin de mettre à jour/supprimer à nouveau le sous-réseau ou le réseau virtuel, vous devez recréer l’intégration au réseau virtuel et la déconnecter :

  1. Recréez le plan App Service et l’application web (il est obligatoire d’utiliser le même nom d’application web que précédemment).
  2. Accédez au panneau « Mise en réseau » de l’application web et configurez l’intégration au réseau virtuel.
  3. Une fois l’intégration au réseau virtuel configurée, sélectionnez le bouton « Déconnexion ».
  4. Supprimez le plan App Service ou l’application web.
  5. Mettez à jour/supprimez le sous-réseau ou le réseau virtuel.

Si vous rencontrez toujours des problèmes avec l’intégration au réseau virtuel après avoir effectué les étapes ci-dessus, contactez Support Microsoft.

Utilitaire de résolution des problèmes réseau

Vous pouvez également utiliser l’utilitaire de résolution des problèmes réseau pour résoudre les problèmes de connexion. Pour ouvrir l’utilitaire de résolution des problèmes réseau, accédez à l’application dans le portail Azure. Sélectionnez Diagnostiquer et résoudre le problème, puis recherchez Utilitaire de résolution des problèmes réseau.

Problèmes de connexion : il vérifie l’état de l’intégration du réseau virtuel, notamment si l’adresse IP privée a été affectée à toutes les instances du plan et les paramètres DNS. Si un DNS personnalisé n’est pas configuré, Azure DNS par défaut est appliqué. L’utilitaire de résolution des problèmes vérifie également les dépendances courantes de l’application de fonction, notamment la connectivité pour Stockage Azure et d’autres dépendances de liaison.

Capture d’écran montrant l’utilitaire de résolution des problèmes au travail sur des problèmes de connexion.

Problèmes de configuration : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau est valide pour l’intégration de réseau virtuel.

Capture d’écran montrant l’utilitaire de résolution des problèmes au travail sur des problèmes de configuration.

Problème de suppression de sous-réseau/réseau virtuel : cet utilitaire de résolution des problèmes vérifie si votre sous-réseau a des verrous et s’il a des liens d’association de service inutilisés qui peuvent bloquer la suppression du réseau virtuel/sous-réseau.

Étapes suivantes

Pour en savoir plus sur la mise en réseau et Azure Functions :