Intégrer votre application à un réseau virtuel Azure

Remarque

Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.

Exemple : myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour les ressources App Service.

Cet article décrit la fonctionnalité d’intégration au réseau virtuel d’Azure App Service et explique comment la configurer avec des applications dans App Service. Les réseaux virtuels Azure vous permettent de placer un grand nombre de vos ressources Azure dans un réseau routable non Internet. La fonctionnalité d’intégration au réseau virtuel d’App Service permet à vos applications d’accéder à des ressources dans ou via un réseau virtuel.

Notes

Les informations sur l’intégration de réseau virtuel requise par la passerelle ont été déplacées vers un nouvel emplacement.

App Service propose deux variantes :

• 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 un App Service Environment, elle est déjà intégrée à un réseau virtuel et il n'est pas nécessaire de configurer la fonction d'intégration de réseau virtuel pour atteindre les 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. Reportez-vous au point de terminaison privé pour l’accès privé entrant.

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, les applications de fonction et les applications logiques.

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 des réseaux virtuels permet de se connecter à un réseau virtuel dans la même région. L’utilisation de l’intégration au réseau virtuel permet à votre application d’accéder aux :

• ressources du réseau virtuel auquel vous êtes intégré.
• ressources dans les réseaux virtuels appairés au réseau virtuel auquel votre application est intégrée, y compris les connexions de peering mondial.
• Ressources sur des connexions Azure ExpressRoute.
• Services sécurisés par un point de terminaison de service.
• Services avec points de terminaison privés.

Lorsque vous utilisez l’Intégration au réseau virtuel, 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 à l’aide d’un NSG que vous utilisez 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.
• Passerelle NAT : vous pouvez utiliser la passerelle NAT pour obtenir une adresse IP sortante dédiée et atténuer l’épuisement des ports SNAT.

Découvrez comment activer l’intégration au réseau virtuel.

Comment l’intégration de réseau virtuel fonctionne

Les applications contenues dans App Service sont hébergées dans des rôles de travail. L’intégration au réseau virtuel opère en montant des interfaces virtuelles aux rôles de travail avec des adresses du sous-réseau délégué. Les interfaces virtuelles utilisées ne sont pas une ressource à laquelle les clients peuvent accéder directement. Comme l’adresse De se trouve dans votre réseau virtuel, elle peut accéder à la plupart des éléments de votre réseau virtuel, comme le ferait une machine virtuelle de votre réseau virtuel.

Lorsque l’intégration au réseau virtuel est activée, votre application effectue des appels sortants via votre réseau virtuel. Les adresses sortantes figurant sur le portail des propriétés de l’application sont toujours les adresses qu’utilise votre application. Toutefois, si votre appel sortant concerne une machine virtuelle ou un point de terminaison privé dans le réseau virtuel d’intégration ou le réseau virtuel appairé, l’adresse sortante est une adresse du sous-réseau d’intégration. L’adresse IP privée assignée à une instance est exposée via la variable d’environnement WEBSITE_PRIVATE_IP.

Quand le routage de l’ensemble du trafic est activé, tout le trafic sortant est envoyé dans votre réseau virtuel. Si le routage de tout le trafic n’est pas activé, seul le trafic privé (RFC1918) et les points de terminaison de service configurés sur le sous-réseau d’intégration sont envoyés dans le réseau virtuel. Le trafic sortant vers Internet est acheminé directement depuis l’application.

La fonctionnalité d’intégration du réseau virtuel prend en charge deux interfaces virtuelles par rôle de travail. Deux interfaces virtuelles par Worker signifient deux intégrations au réseau virtuel par plan App Service. En d’autres termes, un plan App Service peut disposer d’intégrations de réseau virtuel avec jusqu’à deux sous-réseaux/réseaux virtuels. Les applications du même plan App Service ne peuvent utiliser qu’une des intégrations du réseau virtuel à un sous-réseau spécifique, ce qui signifie qu’une application ne peut avoir qu’une seule intégration du réseau virtuel à un moment donné.

Configuration requise du sous-réseau

L’intégration au réseau virtuel dépend d’un sous-réseau dédié. Quand vous créez un sous-réseau, le sous-réseau Azure consomme cinq IP dès le début. Une seule adresse du sous-réseau d’intégration est utilisée pour chaque instance de plan App Service. Si vous définissez l’échelle de votre application sur quatre instances, quatre adresses sont utilisées.

Lorsque vous effectuez un scale-up/down de la taille de l’instance, la quantité d’adresses IP utilisées par le plan App Service est temporairement doublée alors que l’opération de mise à l’échelle se termine. Les nouvelles instances doivent être entièrement opérationnelles avant que les instances existantes ne soient déprovisionnées. L’opération de mise à l'échelle affecte les instances prises en charge réelles et disponibles pour une taille de sous-réseau donnée. Les mises à niveau de plateforme nécessitent des adresses IP gratuites pour garantir que les mises à niveau peuvent avoir lieu sans interruption du trafic sortant. Enfin, une fois les opérations de mise à l’échelle (scale up, scale down ou scale in) terminées, il peut s’écouler un court laps de temps avant que les adresses IP ne soient publiées. Dans de rares cas, cette opération peut durer jusqu’à 12 heures et si vous procédez à une mise à l’échelle rapide (entrée/sortie ou augmentation/diminution), vous aurez besoin de plus d’adresses IP que la mise à l’échelle maximale.

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. Vous devez également réserver des adresses IP pour les mises à niveau de la plateforme. Pour éviter tout problème de capacité de sous-réseau, nous recommandons d’allouer le double d’adresses IP par rapport à l’échelle maximale prévue. Une /26 avec 64 adresses couvre l’échelle maximale d’un seul plan App Service multilocataire. 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 /27 est requise. Si le sous-réseau existe déjà avant l’intégration via le portail, vous pouvez utiliser un sous-réseau /28.

Avec la jointure de sous-réseau multiplan (MPSJ), vous pouvez fusionner plusieurs plans App Service au même sous-réseau. Tous les plans App Service doivent se trouver dans le même abonnement, mais le réseau virtuel/sous-réseau peut se trouver dans un autre abonnement. Chaque instance de chaque plan App Service nécessite une adresse IP à partir du sous-réseau et pour utiliser la MPSJ une taille minimale de /26 sous-réseau est requise. Si vous envisagez de joindre de nombreux plans à grande échelle et/ou à grande échelle, vous devez planifier des plages de sous-réseaux plus grandes.

Important

En raison d'un bogue connu, MPSJ échoue si plusieurs sites sont créés et tentent de s'intégrer au réseau virtuel en même temps. Un correctif sera bientôt déployé. En attendant, vous pouvez contourner le problème avec l’une des méthodes suivantes :

• Si vous créez des sites manuellement, créez et intégrez les sites un par un.
• Si vous créez des sites par programmation, par exemple à l'aide de modèles Terraform ou ARM, ajoutez un élément dependsOn à chaque site de vos modèles pour dépendre de la création du site précédent pour tous les sites sauf le premier du modèle. Cela crée un délai entre la création du site et l'intégration du réseau virtuel pour chaque site et n'est donc pas bloqué par le bug connu. Pour plus d'informations, consultez Définir l'ordre de déploiement des ressources dans les modèles ARM.

Limites spécifiques aux conteneurs Windows

Les conteneurs Windows utilisent une adresse IP supplémentaire par application pour chaque instance de plan App Service, et vous devez dimensionner le sous-réseau en conséquence. Si vous avez, par exemple, 10 instances de plan App Service de conteneur Windows avec quatre applications en cours d’exécution, vous avez besoin de 50 adresses IP et adresses supplémentaires pour prendre en charge la mise à l’échelle horizontale (entrée/sortie).

Exemple de calcul :

Pour chaque instance de plan App Service, vous avez besoin de : 4 applications conteneur Windows = 4 adresses IP, 1 adresse IP par instance de plan App Service, 4 + 1 = 5 adresses IP

Pour 10 instances : 5 x 10 = 50 adresses IP par plan App Service

Étant donné que vous avez un plan App Service, 1 x 50 = 50 adresses IP.

Vous êtes en outre limité par le nombre de cœurs disponibles dans le niveau Worker utilisé. Chaque cœur ajoute trois « unités réseau ». Le worker lui-même utilise une unité et chaque connexion de réseau virtuel utilise une unité. Les unités restantes peuvent être utilisées pour les applications.

Exemple de calcul :

Instance de plan App Service avec quatre applications en cours d’exécution qui utilisent l’intégration de réseau virtuel. Les applications sont connectées à deux sous-réseaux différents (connexions de réseau virtuel). Cette configuration nécessite sept unités réseau (1 Worker + 2 connexions + 4 applications). La taille minimale pour l’exécution de cette configuration serait I2v2 (4 cœurs x 3 unités = 12 unités).

Avec I1v2, vous pouvez exécuter au maximum quatre applications à l’aide de la même connexion (1) ou 3 applications utilisant 2 connexions.

Autorisations

Pour configurer l’intégration du réseau virtuel par le biais du portail Azure, de l’interface CLI ou lors de la définition directe de la propriété de site virtualNetworkSubnetId, vous devez disposer au moins des autorisations de contrôle d’accès en fonction du rôle suivantes sur le sous-réseau ou à un niveau supérieur :

Action	Description
Microsoft.Network/virtualNetworks/read	Lire la définition de réseau virtuel
Microsoft.Network/virtualNetworks/subnets/read	Lire la définition de sous-réseau de réseau virtuel
Microsoft.Network/virtualNetworks/subnets/join/action	Joint un réseau virtuel.

Si le réseau virtuel se trouve dans un abonnement différent de celui de l’application, vous devez vous assurer que l’abonnement avec le réseau virtuel est inscrit pour le fournisseur de ressources Microsoft.Web. Vous pouvez inscrire explicitement le fournisseur en suivant cette documentation, mais il est également inscrit automatiquement lors de la création de la première application web dans un abonnement.

Itinéraires

Vous pouvez contrôler le trafic qui transite par l’intégration du réseau virtuel. Il existe trois types de routage à prendre en compte lorsque vous configurez l’intégration au réseau virtuel. Le routage des applications définit quel trafic est routé de votre application vers le réseau virtuel. Le routage de la configuration affecte les opérations qui se produisent avant ou pendant le démarrage de votre application. Il s’agit par exemple du tirage (pull) d’une image conteneur ou des paramètres d’application utilisant une référence Key Vault. Le routage réseau permet de contrôler la manière dont le trafic de l’application et de la configuration est routé à partir de votre réseau virtuel et vers l’extérieur.

Grâce aux options de routage des applications ou de routage de la configuration, vous pouvez configurer le trafic qui est envoyé par l’intégration du réseau virtuel. Le trafic est soumis uniquement au routage réseau s’il est envoyé par le biais de l’intégration du réseau virtuel.

Acheminement des candidatures

Le routage d’application s’applique au trafic qui est envoyé à partir de votre application après le démarrage. Pour plus d’informations sur le trafic au moment du démarrage, consultez routage de la configuration. Lorsque vous configurez le routage d’applications, vous pouvez acheminer tout le trafic ou seulement le trafic privé (également appelé trafic RFC1918) vers votre réseau virtuel. Vous configurez ce comportement via le paramètre de trafic Internet sortant. Si le routage de trafic Internet sortant est désactivé, votre application achemine uniquement le trafic privé vers votre réseau virtuel. Si vous souhaitez router l’ensemble de votre trafic d’application sortant vers votre réseau virtuel, vérifiez que le trafic Internet sortant est activé.

• Seul le trafic configuré dans l’application ou le routage de configuration est soumis aux groupes de sécurité réseau et aux NSG qui sont appliqués à votre sous-réseau d’intégration.
• Lorsque le routage de trafic Internet sortant est activé, l’adresse source de votre trafic sortant à partir de votre application est néanmoins toujours une des adresses IP répertoriées dans les propriétés de votre application. Si vous routez votre trafic via un pare-feu ou une passerelle NAT, l’adresse IP source provient alors de ce service.

Découvrez comment configurer le routage d’application.

Notes

La connectivité SMTP sortante (port 25) est prise en charge pour App Service lorsque le trafic SMTP est routé via l’intégration du réseau virtuel. La prise en charge est déterminée par un paramètre de l’abonnement où le réseau virtuel est déployé. Pour les réseaux virtuels/sous-réseaux créés avant le 1er août 2022, vous devez lancer une modification de configuration temporaire sur le réseau virtuel/sous-réseau pour que le paramètre soit synchronisé à partir de l’abonnement. Par exemple, vous pouvez ajouter un sous-réseau temporaire, associer/dissocier temporairement un groupe de sécurité réseau ou configurer temporairement un point de terminaison de service. Pour plus d’informations, consultez Résoudre les problèmes de connectivité SMTP sortante dans Azure.

Routage de la configuration

Lorsque vous utilisez l’intégration du réseau virtuel, vous pouvez configurer la gestion des parties du trafic de configuration. Par défaut, le trafic de configuration passe directement par l’itinéraire public. Toutefois, pour les composants mentionnés, vous pouvez le configurer activement pour qu’il soit routé via l’intégration du réseau virtuel.

Partage de contenu

Par défaut, Azure Functions utilise un partage de contenu comme source de déploiement lors de la mise à l’échelle des applications de fonction dans un plan Premium. Vous devez configurer un paramètre supplémentaire pour garantir que le trafic est acheminé vers ce partage de contenu via l’intégration du réseau virtuel. Pour plus d’informations, consultez Comment configurer le routage du partage de contenu.

Outre l’ajout de la configuration du routage, vous devez également vous assurer que tous les pare-feu ou groupes de sécurité réseau configurés sur le trafic à partir du sous-réseau autorisent le trafic vers les ports 443 et 445.

Extraction de l’image conteneur

Lorsque vous utilisez des conteneurs personnalisés, vous pouvez extraire le conteneur via l’intégration du réseau virtuel. Pour acheminer le trafic d’extraction de conteneurs via l’intégration du réseau virtuel, vous devez vous assurer que le paramètre de routage est configuré. Découvrez comment configurer le routage du tirage (pull) d’images.

Sauvegarde/restauration

App Service dispose d’une sauvegarde/restauration intégrée, mais si vous souhaitez effectuer une sauvegarde sur votre compte de stockage, vous pouvez utiliser la fonctionnalité de sauvegarde/restauration personnalisée. Si vous souhaitez router le trafic vers le compte de stockage via l’intégration au réseau virtuel, vous devez configurer le paramètre de route. La sauvegarde de base de données n’est pas prise en charge sur l’intégration du réseau virtuel.

Paramètres d’application utilisant des références Key Vault

Les paramètres d’application qui utilisent des références Key Vault tentent d’accéder aux secrets via l’itinéraire public. Si le Key Vault bloque le trafic public et si l’application utilise l’intégration du réseau virtuel, une tentative est effectuée pour récupérer les secrets par le biais de l’intégration du réseau virtuel.

Remarque

• La configuration de certificats SSL/TLS à partir de coffres de clés privés n’est pas prise en charge.
• L’envoi de journaux App Service vers des comptes de stockage privés n’est pas pris en charge. Nous vous recommandons d’utiliser la journalisation des diagnostics et d’autoriser les services approuvés pour le compte de stockage.

Routage des paramètres d’application

App Service dispose de paramètres d'application existants pour configurer l'application et l'acheminement de la configuration. Les propriétés du site ont la priorité sur les paramètres de l’application s’ils existent tous les deux. Les propriétés de site ont l’avantage d’être auditables avec Azure Policy et validées au moment de la configuration. Nous vous recommandons d’utiliser les propriétés du site.

Vous pouvez toujours utiliser le paramètre d’application WEBSITE_VNET_ROUTE_ALL existant pour configurer le routage des applications.

Il existe également des paramètres d’application pour certaines options de routage de la configuration. Ces paramètres d’application sont nommés WEBSITE_CONTENTOVERVNET et WEBSITE_PULL_IMAGE_OVER_VNET.

Routage réseau

Vous pouvez utiliser des tables de routage pour router le trafic sortant depuis votre application sans restriction. Les destinations courantes peuvent inclure des pare-feu ou des passerelles. Vous pouvez également utiliser un groupe de sécurité réseau pour bloquer le trafic sortant vers des ressources dans votre réseau virtuel ou sur Internet. Un NSG que vous appliquez à votre sous-réseau d’intégration est en vigueur indépendamment des tables de routage appliquées à votre sous-réseau d’intégration.

Les tables de routage et les groupes de sécurité réseau s’appliquent uniquement au trafic qui est routé via l’intégration du réseau virtuel. Pour plus d’informations, consultez routage d’application et routage de configuration. Les itinéraires ne s'appliquent pas aux réponses des requêtes entrantes de l'application et les règles entrantes dans un groupe de sécurité réseau (NSG) ne s'appliquent pas à votre application. L’intégration au réseau virtuel affecte uniquement le trafic sortant de votre application. Pour contrôler le trafic entrant vers votre application, utilisez la fonctionnalité de restrictions d’accès ou les points de terminaison privés.

Lorsque vous configurez des groupes de sécurité réseau ou des tables de routage qui s’appliquent au trafic sortant, vous devez vous assurer que vous tenez compte des dépendances de votre application. Les dépendances d’application incluent des points de terminaison dont votre application a besoin pendant l’exécution. Outre les API et les services que l’application appelle, ces points de terminaison peuvent être dérivés de points de terminaison tels que ceux de vérification de la liste de révocation de certificats (CRL) et du point de terminaison d’identité/d’authentification, par exemple Azure Entra ID. Si vous utilisez un déploiement continu dans App Service, vous devrez peut-être également autoriser les points de terminaison en fonction du type et de la langue. Spécifiquement pour le déploiement continu Linux, vous devez autoriser oryx-cdn.microsoft.io:443. Pour Python, vous devez également autoriser files.pythonhosted.org, pypi.org.

Azure utilise le port UDP 30 000 pour effectuer des contrôles de santé du réseau. Si vous bloquez ce trafic, cela n'aura pas d'impact direct sur votre application, mais il sera plus difficile pour le support Azure de détecter et de dépanner les problèmes liés au réseau.

Pour router le trafic sortant vers un emplacement local, vous pouvez utiliser une table de routage afin d’envoyer le trafic sortant vers votre passerelle Azure ExpressRoute. Si vous choisissez de router le trafic vers une passerelle, définissez 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é. Semblable aux itinéraires définis par l’utilisateur, les itinéraires BGP ont un impact sur le trafic en fonction des paramètres d’étendue du routage.

Points de terminaison de service

L’intégration au réseau virtuel vous permet d’atteindre les services Azure sécurisés avec les points de terminaison de service. Pour accéder à un service sécurisé par un point de terminaison de service, procédez comme suit :

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

Instances Private Endpoint

Si vous souhaitez effectuer des appels vers des points de terminaison privés, assurez-vous 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 Si votre réseau virtuel n’a pas de serveur DNS personnalisé, cette intégration est effectuée automatiquement quand les zones sont liées au réseau virtuel.
• Gérer le point de terminaison privé dans le serveur DNS utilisé par votre application. Pour gérer la configuration, vous devez connaître l’adresse IP du point de terminaison privé. Pointez ensuite 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.

Zones privées Azure DNS

Une fois votre application intégrée au réseau virtuel, elle utilise le serveur DNS avec lequel votre réseau virtuel est configuré. Si aucun DNS personnalisé n’est spécifié, il utilise le DNS par défaut Azure et toutes les zones privées liées au réseau virtuel.

Limites

Il existe certaines limitations concernant l’utilisation de l’intégration au réseau virtuel :

• Cette fonctionnalité est disponible dans tous les déploiements App Service Premium v2 et Premium v3. Elle est également disponible au niveau Basic et 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 voulez être sûr de pouvoir utiliser la fonctionnalité dans un plan App Service De base ou 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 réduire la taille du plan si vous le souhaitez après avoir créé le plan.
• La fonctionnalité n’est pas disponible pour les applications Service isolé dans un App Service Environment.
• Vous ne pouvez pas accéder aux ressources sur des connexions de peering avec des réseaux virtuels classiques.
• La fonctionnalité nécessite un sous-réseau inutilisé avec un bloc IPv4 /28 au moins dans un réseau virtuel Azure Resource Manager. La MPSJ nécessite un bloc /26 ou plus grand.
• L’application et le réseau virtuel doivent se trouver dans la même région.
• Il n’est pas possible de définir des espaces d’adressage IPv6 pour le réseau virtuel d’intégration.
• Les stratégies de point de terminaison de service ne peuvent pas être activées sur le 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 avoir plus de deux intégrations de réseau virtuel par plan App Service. Plusieurs applications d’un même plan App Service peuvent utiliser l’intégration au même 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.

Accès aux ressources locales

Aucune configuration supplémentaire n’est nécessaire pour permettre à la fonctionnalité d’intégration au réseau virtuel d’accéder à vos ressources locales via votre réseau virtuel. Vous devez simplement connecter votre réseau virtuel aux ressources locales à l’aide d’ExpressRoute ou d’un VPN de site à site.

Appairage

Si vous utilisez le peering avec l’intégration au réseau virtuel, vous n’avez pas besoin d’effectuer d’autres tâches de configuration.

Gérer l’intégration au réseau virtuel

Les connexions et déconnexions avec un réseau virtuel se font au niveau de l’application. Les opérations qui peuvent affecter l’intégration au réseau virtuel entre plusieurs applications s’effectuent au niveau du plan App Service. Dans le portail, sous l’application >Mise en réseau>Intégration au réseau virtuel, vous pouvez obtenir des détails sur votre réseau virtuel. Vous pouvez consulter des informations similaires au niveau du plan App Service dans le portail Plan App Service>Mise en réseau>Intégration au réseau virtuel.

Dans la vue d’application de votre instance d’intégration de réseau virtuel, vous pouvez déconnecter votre application du réseau virtuel et configurer le routage des applications. Pour déconnecter votre application d’un réseau virtuel, sélectionnez Déconnecter. Votre application est redémarrée quand vous vous déconnectez d’un réseau virtuel. La déconnexion ne change pas votre réseau virtuel. Le sous-réseau n’est pas supprimé. Donc, si vous souhaitez supprimer votre réseau virtuel, déconnectez d’abord votre application du réseau virtuel.

L’adresse IP privée assignée à l’instance est exposée via la variable d’environnement WEBSITE_PRIVATE_IP. L’interface utilisateur de la console Kudu affiche également la liste des variables d’environnement disponibles pour l’application web. Cette adresse IP est attribuée à partir de la plage d’adresses du sous-réseau intégré. Cette adresse IP est utilisée par l’application web pour se connecter aux ressources via le réseau virtuel Azure.

Notes

La valeur de WEBSITE_PRIVATE_IP est appelée à changer. Toutefois, il s’agit d’une adresse IP de la plage d’adresses du sous-réseau d’intégration. De ce fait, vous devrez autoriser l’accès depuis toutes les adresses de la plage.

Détails de la tarification

L’utilisation de la fonctionnalité d’intégration au réseau virtuel ne s’accompagne d’aucuns frais d’utilisation supplémentaires au-delà des frais liés au niveau tarifaire du plan App Service.

Dépannage

Cette fonctionnalité est facile à configurer, mais il est possible que vous rencontriez des problèmes. Si vous rencontrez des problèmes d’accès au point de terminaison souhaité, vous pouvez effectuer différentes étapes en fonction de ce que vous observez. Pour plus d’informations, consultez le Guide de résolution des problèmes d’intégration de réseau virtuel.

Notes

• L’intégration au réseau virtuel n’est pas prise en charge pour les scénarios Docker Compose dans App Service.
• Les restrictions d’accès ne s’appliquent pas au trafic arrivant via un point de terminaison privé.

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

Si vous avez supprimé l'application ou le plan App Service sans déconnecter l'intégration du réseau virtuel au préalable, vous ne pouvez pas effectuer d'opérations de mise à jour/de suppression sur le réseau ou le sous-réseau virtuel qui était utilisé pour l'intégration avec la ressource supprimée. Une délégation de sous-réseau « Microsoft.Web/serverFarms » reste attribuée à votre sous-réseau et empêche les opérations de mise à jour et de 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 (il est obligatoire d’utiliser le même nom d’application web que précédemment).
2. Accédez à Mise en réseau sur l’application dans Portail Azure 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 ou l’application App Service.
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é ces étapes, contactez Support Microsoft.