Options de mise en réseau d’Azure Functions

Cet article décrit les fonctionnalités de mise en réseau disponibles dans les options d’hébergement pour Azure Functions. Les options de mise en réseau suivantes peuvent être catégorisées en tant que fonctionnalités de mise en réseau entrantes et sortantes. Les fonctionnalités entrantes vous permettent de restreindre l’accès à votre application, alors que les fonctionnalités sortantes vous permettent de connecter votre application à des ressources sécurisées par un réseau virtuel, et de contrôler le routage du trafic sortant.

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.

1. Pour plus d’informations, consultez Réseaux dans un environnement Azure Container Apps.
2. Il existe des points particuliers à prendre en compte quand vous utilisez des déclencheurs de réseau virtuel.
3. Seul le plan Dédié/ASE prend en charge l’intégration au réseau virtuel nécessitant une passerelle.

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.

• Modèles ARM, fichiers Bicep et modèles Terraform :
  • Application de fonction privée déclenchée par HTTP
  • Application de fonction privée déclenchée par Event Hubs
• Modèles ARM uniquement :
  • Application de fonction avec points de terminaison privés du Stockage Azure.
  • Application de fonction Azure avec intégration du réseau virtuel.
• Tutoriels :
  • Intégrer Azure Functions à un réseau virtuel Azure à l’aide de points de terminaison privés
  • Restreindre votre compte de stockage à un réseau virtuel.
  • Contrôler l’adresse IP sortante Azure Functions avec une passerelle NAT de réseau virtuel Azure.

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.

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 Consommation flexible, Élastique Premium et Dédié (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 gérer un point de terminaison privé, vous devez connaître l’adresse du point de terminaison, et utiliser un enregistrement A pour référencer le point de terminaison que vous tentez d’atteindre.
• 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. Suivez ces étapes pour accéder à un point de terminaison de service sécurisé :

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, que vous activez plus tard sur le sous-réseau.

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.

Fonctionnalités de mise en réseau sortantes

Vous pouvez utiliser les fonctionnalités de cette section pour gérer les connexions sortantes établies par votre application.

Intégration du réseau virtuel

Cette section détaille les fonctionnalités prises en charge par Functions pour contrôler les données sortantes de votre application.

L’intégration au réseau virtuel permet à votre application de fonction d’accéder aux ressources de votre réseau virtuel. Une fois intégrée, votre application route le trafic sortant via le réseau virtuel. Cela permet à votre application d’accéder à des ressources ou des points de terminaison privés avec des règles autorisant le trafic provenant uniquement de sous-réseaux sélectionnés. Quand la destination est une adresse IP en dehors du réseau virtuel, l’IP source est toujours envoyée à partir de l’une des adresses listées dans les propriétés de votre application, sauf si vous avez configuré une passerelle NAT Gateway.

Azure Functions prend en charge deux types d’intégration de réseau virtuel :

• Intégration au réseau virtuel régional pour les applications s’exécutant sur les plans d’hébergement Consommation flexible, Élastique Premium, Dédié (App Service) et Container Apps (recommandé)
• Intégration au réseau virtuel nécessitant une passerelle pour les applications s’exécutant sur le plan d’hébergement Dédié (App Service)

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

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.

Considérations relatives au plan Consommation flexible :

• Vérifiez que le fournisseur de ressources Azure Microsoft.App est activé pour votre abonnement en suivant ces instructions. Cela est nécessaire pour la délégation de sous-réseau.
• La délégation de sous-réseau nécessaire en cas d’exécution dans un plan Consommation flexible est Microsoft.App/environments. Cela diffère des plans Élastique Premium et Dédié (App Service), qui ont une autre exigence de délégation.
• 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 15 applications de fonction Consommation flexible intégrées au même sous-réseau, vous devez planifier 15 x 40 = 600 adresses IP utilisées au maximum. Cette limite est sujette à modification et n’est pas appliquée.
• 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 sont partagées entre ces applications de fonction, ce qui peut donner lieu à une situation où une application impacte les performances des autres applications sur le même sous-réseau.

Considérations relatives aux plans Élastique Premium, Dédié (App Service) et Container Apps :

• La fonctionnalité est disponible pour Élastique Premium ainsi que pour 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.
• La fonctionnalité ne peut pas être utilisée par des applications de plan Isolé qui se trouvent dans un environnement App Service.
• L’application et le réseau virtuel doivent se trouver dans la même région.
• La fonctionnalité nécessite un sous-réseau inutilisé /28 ou d’une taille supérieure dans un réseau virtuel Azure Resource Manager.
• Le sous-réseau d’intégration peut être utilisé par un seul plan App Service.
• 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 supprimer un réseau virtuel avec une application intégrée. Supprimez l’intégration avant de supprimer le réseau virtuel.
• 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.

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.

   

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.

   

   • Les plans d’hébergement Consommation flexible et Élastique Premium prennent uniquement en charge l’intégration au 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 vide préexistant.

   • 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 préférez uniquement router votre trafic privé (trafic RFC1918), suivez les étapes décrites dans cet article sur App Service.

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 le plan Consommation flexible, cela ne s’applique pas. Les instances partagent les adresses IP.

Dans les plans Élastique Premium et Dédié (App Service), l’espace d’adressage nécessaire est doublé pendant une courte période quand vous effectuez un scale-up ou un scale-down de la taille de l’instance. 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 :

^*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.

Le plan Consommation flexible permet à plusieurs applications s’exécutant dans le plan Consommation flexible de s’intégrer au même sous-réseau. Cela n’est pas le cas pour les plans d’hébergement Élastique Premium et Dédié (App Service). Ces plans permettent uniquement de connecter deux réseaux virtuels dans chaque plan App Service. Plusieurs applications d’un même plan App Service peuvent rejoindre le même sous-réseau, mais les applications d’un autre plan ne peuvent pas utiliser ce sous-réseau.

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 contrôler le trafic entre les ressources de votre réseau virtuel. Par exemple, vous pouvez créer une règle de sécurité qui empêche le trafic sortant de votre application d’atteindre une ressource de votre réseau virtuel, ou de quitter le réseau. Ces règles de sécurité s’appliquent aux applications pour lesquelles l’intégration au réseau virtuel a été configurée. Pour bloquer le trafic vers les adresses publiques, l’intégration au réseau virtuel et l’option Router tout doivent être activées. 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 Router tout activée, et si vous n’avez aucune route qui affecte le trafic des adresses publiques sur votre sous-réseau d’intégration, l’ensemble de votre trafic sortant est toujours soumis aux groupes NSG 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. Quand l’option Router tout 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.

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 le plan Consommation flexible, l’ensemble du 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.

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.

Automation

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

• Azure CLI : Utilisez les commandes az functionapp vnet-integration pour ajouter, lister ou supprimer des intégrations de réseaux virtuels régionaux.
• Modèles ARM : l’intégration d’un réseau virtuel régional peut être activée à l’aide d’un modèle Azure Resource Manager. Pour un exemple complet, consultez ce modèle de démarrage rapide de Functions.

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.

Connexion aux services Azure via un réseau virtuel

L’intégration au réseau virtuel permet à votre application de fonction d’accéder aux ressources d’un réseau virtuel. Cette section présente une vue d’ensemble des éléments à prendre en compte quand vous tentez de connecter votre application à certains services.

Restreindre votre compte de stockage à un réseau virtuel

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.

Vous pouvez utiliser un compte de stockage ayant des restrictions d’accès réseau avec des applications de fonction dans les plans Consommation flexible, Élastique Premium et Dédié (App Service). Le plan Consommation n’est pas pris en charge. Pour les plans Élastique Premium et Dédié, vous devez vérifier que le routage du partage de contenu privé est configuré. Pour découvrir comment configurer votre application de fonction avec un compte de stockage sécurisé avec un réseau virtuel, 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)

Votre charge de travail peut nécessiter le déclenchement de votre application à partir d’une source d’événement protégée par un réseau virtuel. Deux options s’offrent à vous si vous souhaitez que votre application fasse l’objet d’une mise à l’échelle dynamique en fonction du nombre d’événements reçus en provenance de sources de déclencheurs non HTTP :

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

Les applications de fonction s’exécutant sur les plans Dédié (App Service) ne font pas l’objet d’une mise à l’échelle dynamique en fonction des événements. À la place, le scale-out est dicté par les règles de mise à l’échelle automatique que vous définissez.

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

Le plan Élastique Premium vous permet de créer des fonctions déclenchées par des services sécurisés par 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 de 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 :

az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.functionsRuntimeScaleMonitoringEnabled=1 --resource-type Microsoft.Web/sites

$Resource = Get-AzResource -ResourceGroupName <resource_group> -ResourceName <function_app_name>/config/web -ResourceType Microsoft.Web/sites
$Resource.Properties.functionsRuntimeScaleMonitoringEnabled = $true
$Resource | Set-AzResource -Force

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.

^* Uniquement avec le stockage de file d'attente.

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

Quand votre application de fonction s’exécute dans un plan App Service ou App Service Environment, vous pouvez écrire des fonctions déclenchées par des ressources sécurisées par un réseau virtuel. Pour que vos fonctions se déclenchent correctement, votre application doit être connectée à un réseau virtuel ayant accès à la ressource définie dans la connexion du déclencheur.

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.

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.

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.

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.

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 :

• Tutoriel pour bien démarrer avec l’intégration de réseau virtuel
• Lire les questions fréquentes (FAQ) sur la mise en réseau de Functions
• En savoir plus sur l’intégration de réseau virtuel avec App Service/Functions
• En savoir plus sur les réseaux virtuels dans Azure
• Activer davantage de fonctionnalités de réseau et plus de contrôle avec Azure App Service Environment
• Se connecter à des ressources locales sans modifier le pare-feu à l’aide des connexions hybrides