Mise en réseau d’App Service Environment
App Service Environment est un déploiement monolocataire d’Azure App Service qui héberge des conteneurs Windows et Linux, des applications web, des applications API, des applications logiques et des applications de fonction. Quand vous installez un environnement App Service Environment, vous choisissez le réseau virtuel Azure dans lequel vous voulez le déployer. Tout le trafic d’application entrant et sortant se trouve à l’intérieur du réseau virtuel que vous spécifiez. Vous effectuez le déploiement dans un seul sous-réseau de votre réseau virtuel, et rien d’autre ne peut être déployé dans ce sous-réseau.
Notes
Cet article concerne la fonctionnalité App Service Environment v3 qui est utilisée avec des plans App Service v2 isolés.
Configuration requise du sous-réseau
Vous devez déléguer le sous-réseau à Microsoft.Web/hostingEnvironments, et le sous-réseau doit être vide.
La taille du sous-réseau peut avoir une incidence sur les limites de mise à l’échelle des instances du plan App Service au sein de l’environnement App Service Environment. Si vous souhaitez effectuer une mise à l’échelle pour production, nous vous recommandons un espace d’adressage /24 (256 adresses) pour votre sous-réseau. Si vous planifiez une mise à l’échelle proche de la capacité maximale de 200 instances dans votre fonctionnalité App Service Environment et prévoyez des opérations fréquentes de scale-up/scale-down, nous vous recommandons un espace d’adressage /23 (512 adresses) pour votre sous-réseau.
Si vous utilisez un sous-réseau plus petit, tenez compte des restrictions suivantes :
- Tout sous-réseau possède cinq adresses réservées à des fins de gestion. En plus des adresses de gestion, App Service Environment met dynamiquement à l’échelle l’infrastructure de prise en charge et utilise entre 7 et 27 adresses, selon la configuration et la charge. Vous pouvez utiliser les adresses restantes pour les instances du plan App Service. La taille minimale de votre sous-réseau est un espace d’adressage
/27(32 adresses). - Pour toute combinaison OS/SKU de plan App Service utilisée dans votre App Service Environment comme Windows I1v2, une instance de secours est créée pour chaque tranche de 20 instances actives. Les instances de secours nécessitent également des adresses IP.
- Lors de la mise à l’échelle des plans App Service plans dans le haut/bas du App Service Environment, la quantité d’adresses IP utilisées par le plan App Service est temporairement doublée en attendant 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.
- 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.
- Une fois les opérations de mise à l’échelle (scale-up, scale-down ou scale-in) terminées, il peut s’écouler un courte période de temps avant la publication des adresses IP. Dans de rares cas, cette opération peut prendre jusqu’à 12 heures.
- Si vous manquez d’adresses dans votre sous-réseau, vous risquez de ne pas pouvoir effectuer le scale-out de vos plans App Service dans l’environnement App Service Environment. Il est également possible que vous subissiez une augmentation de la latence lors d’une charge de trafic intense si Microsoft n’est pas en mesure de mettre à l’échelle l’infrastructure de prise en charge.
Remarque
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 votre App Service Environment a par exemple deux plans App Service de conteneurs Windows, chacun avec 25 instances et chacun avec 5 applications en cours d’exécution, vous aurez besoin de 300 adresses IP et d’adresses supplémentaires pour prendre en charge l’échelle horizontale (entrée/sortie).
Exemple de calcul :
Pour chaque instance de plan App Service, vous avez besoin de : 5 applications conteneur Windows = 5 adresses IP, 1 adresse IP par instance de plan App Service, 5 + 1 = 6 adresses IP
Pour 25 instances : 6 x 25 = 150 adresses IP par plan App Service
Étant donné que vous avez deux plans App Service, 2 x 150 = 300 adresses IP.
Adresses
App Service Environment dispose des informations réseau suivantes à la création :
| Type d’adresse | Description |
|---|---|
| Réseau virtuel App Service Environment | Réseau virtuel sur lequel l’environnement est déployé. |
| Sous-réseau App Service Environment | Sous-réseau sur lequel l’environnement est déployé. |
| Suffixe de domaine | Suffixe de domaine utilisé par les applications créées. |
| Adresse IP virtuelle (VIPA) | Type de VIPA utilisé. Les deux valeurs possibles sont interne et externe. |
| Adresse entrante | L’adresse entrante correspond à l’adresse à laquelle vos applications sont accessibles. Si vous avez une VIPA interne, il s’agit d’une adresse dans votre sous-réseau App Service Environment. Si l’adresse est externe, il s’agit d’une adresse publique. |
| Adresses sortantes par défaut | Les applications utilisent cette adresse, par défaut, lorsqu’elles effectuent des appels sortants vers l’Internet. |
Vous trouverez plus d’informations dans la partie Adresses IP du portail, comme illustré dans la capture d’écran suivante :
À mesure que vous mettez à l’échelle vos plans App Service dans votre App Service Environment, vous utilisez davantage d’adresses en dehors de votre sous-réseau. Le nombre d’adresses que vous utilisez varie selon le nombre d’instances du plan App Service que vous avez et du volume de trafic. Les applications dans l’environnement App Service Environment n’ont pas d’adresses dédiées dans le sous-réseau. Les adresses spécifiques utilisées par une application dans le sous-réseau changent au fil du temps.
Apportez votre propre adresse entrante
Vous pouvez apporter votre propre adresse entrante dans votre environnement App Service Environment. Si vous créez un environnement App Service Environment avec une adresse IP virtuelle interne, vous pouvez spécifier une adresse IP statique dans le sous-réseau. Si vous créez un environnement App Service Environment avec une adresse IP virtuelle externe, vous pouvez utiliser votre propre adresse IP publique Azure en spécifiant l’ID de ressource de l’adresse IP publique. Voici les limitations liées à l’apport de votre propre adresse entrante :
- Pour l’environnement App Service Environment ayant une adresse IP virtuelle externe, la ressource d’adresse IP publique Azure doit se trouver dans le même abonnement que l’environnement App Service Environment.
- L’adresse entrante ne peut plus être changée une fois l’environnement App Service Environment créé.
Ports et restrictions réseau
Pour que votre application reçoive du trafic, assurez-vous que les règles du groupe de sécurité réseau (NSG) du trafic entrant autorisent le sous-réseau App Service Environment à recevoir le trafic à partir des ports nécessaires. En plus des ports sur lesquels vous voulez recevoir le trafic, vous devez vérifier qu’Azure Load Balancer peut se connecter au sous-réseau sur le port 80. Ce port est utilisé pour les contrôles d’intégrité de la machine virtuelle interne. Vous pouvez toujours contrôler le trafic sur le port 80 entre le réseau virtuel et votre sous-réseau.
Il est recommandé de configurer la règle NSG entrante suivante :
| Port(s) source / de destination | Sens | Source | Destination | Objectif |
|---|---|---|---|---|
| * / 80 443 | Trafic entrant | VirtualNetwork | Plage de sous-réseaux App Service Environment | Autoriser le trafic d’application et le trafic de test ping d’intégrité interne |
La configuration minimale requise pour qu’App Service Environment soit opérationnel est :
| Port(s) source / de destination | Sens | Source | Destination | Objectif |
|---|---|---|---|---|
| * / 80 | Trafic entrant | AzureLoadBalancer | Plage de sous-réseaux App Service Environment | Autoriser le trafic de test ping d’intégrité interne |
Si vous utilisez la règle minimale requise, vous aurez peut-être besoin d’une ou plusieurs règles pour le trafic de vos applications. Si vous utilisez l’une des options de déploiement ou de débogage, vous devez également autoriser ce trafic vers le sous-réseau App Service Environment. La source de ces règles peut être le réseau virtuel, une ou plusieurs adresses IP clientes spécifiques ou des plages d’adresses IP. La destination est toujours la plage de sous-réseaux App Service Environment. Le trafic de test ping d’intégrité interne sur le port 80 est isolé entre l’équilibreur de charge et les serveurs internes. Aucun trafic externe ne peut atteindre le point de terminaison de test ping d’intégrité.
Les ports d’accès entrant d’application normaux sont les suivants :
| Utilisation | Ports |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Débogage distant de Visual Studio | 4022, 4024, 4026 |
| Service Web Deploy | 8172 |
Notes
Pour l’accès FTP, même si vous souhaitez interdire le FTP standard sur le port 21, vous devez quand même autoriser le trafic à partir de LoadBalancer vers la plage de sous-réseau App Service Environment sur le port 21, car cela est utilisé pour le trafic ping d’intégrité interne pour le service ftp spécifiquement.
Routage réseau
Vous pouvez définir des tables de routage sans restriction. Vous pouvez tunneliser tout le trafic sortant des applications de votre environnement App Service Environment vers un périphérique de pare-feu de sortie, par exemple Pare-feu Azure. Dans ce scénario, la seule chose dont vous devez vous préoccuper, ce sont les dépendances de votre application.
Les dépendances d’application incluent des points de terminaison dont votre application a besoin pendant l’exécution. En plus des API et des services que l’application appelle, les dépendances peuvent également être des points de terminaison dérivés, comme des points de terminaison de vérification de liste de révocation de certificats et le point de terminaison d’identité/authentification, par exemple, Microsoft 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.
Vous pouvez placer vos périphériques de pare-feu d’application web, par exemple Azure Application Gateway, devant le trafic entrant. Cela vous permet d’exposer des applications spécifiques sur cet App Service Environment.
Votre application utilise l’une des adresses sortantes par défaut pour le trafic de sortie vers les points de terminaison publics. Si vous souhaitez personnaliser l’adresse de sortie de vos applications sur un environnement App Service Environment, vous pouvez ajouter une passerelle NAT à votre sous-réseau.
Notes
La connectivité SMTP sortante (port 25) est prise en charge pour App Service Environment v3. La prise en charge est déterminée par 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 et pour résoudre des problèmes, consultez Résoudre les problèmes de connectivité SMTP sortante dans Azure.
Point de terminaison privé
Pour activer des points de terminaison privés pour les applications hébergées dans votre instance App Service Environment, vous devez d’abord activer cette fonctionnalité au niveau d’App Service Environment.
Vous pouvez l’activer via le Portail Azure. Dans le volet de configuration App Service Environment, activez le paramètre Allow new private endpoints.
Vous pouvez aussi l’activer avec l’interface CLI suivante :
az appservice ase update --name myasename --allow-new-private-endpoint-connections true
Pour plus d’informations sur le point de terminaison privé et l’application web, consultez Point de terminaison privé de l’application web Azure
DNS
Les sections suivantes décrivent les considérations et la configuration DNS qui s’appliquent à l’entrée et à la sortie de votre environnement App Service Environment. Les exemples utilisent le suffixe de domaine appserviceenvironment.net du cloud public Azure. Si vous utilisez d’autres clouds comme Azure Government, vous devez utiliser leur suffixe de domaine respectif. Pour les domaines App Service Environment, le nom du site est tronqué à 40 caractères en raison des limites DNS. Si vous disposez d’un emplacement, son nom est tronqué à 19 caractères.
Configuration DNS vers votre environnement App Service Environment
Si votre App Service Environment est créé avec une adresse IP virtuelle externe, vos applications sont automatiquement placées dans un DNS public. Si votre environnement App Service est créé avec une adresse IP virtuelle interne, lorsque vous créez votre environnement App Service, si vous sélectionnez la configuration automatique des zones privées Azure DNS, alors le DNS est configuré dans votre réseau virtuel. Si vous avez choisi de configurer le DNS manuellement, vous devez soit utiliser votre propre serveur DNS, soit configurer des zones privées Azure DNS. Pour rechercher l’adresse d’entrée, allez sur le portail App Service Environment et sélectionnez Adresses IP.
Si vous souhaitez utiliser votre propre serveur DNS, vous devez ajouter les enregistrements suivants :
- Créez une zone pour
<App Service Environment-name>.appserviceenvironment.net. - Créez un enregistrement A dans cette zone, qui pointe * vers l’adresse IP entrante qu’utilise votre App Service Environment.
- Créez un enregistrement A dans cette zone, qui pointe @ vers l’adresse IP entrante qu’utilise votre App Service Environment.
- Créez dans
<App Service Environment-name>.appserviceenvironment.netune zone nomméescm. - Créez un enregistrement A dans la zone
scmqui pointe * vers l’adresse IP utilisée par le point de terminaison privé de votre environnement App Service Environment.
Pour configurer DNS dans des zones privées Azure DNS :
- Créez une zone privée Azure DNS nommée
<App Service Environment-name>.appserviceenvironment.net. - Créez un enregistrement A dans cette zone, qui pointe * vers l’adresse IP entrante.
- Créez un enregistrement A dans cette zone, qui pointe @ vers l’adresse IP entrante.
- Créez un enregistrement A dans cette zone, qui pointe *.scm vers l’adresse IP entrante.
En plus du domaine par défaut fourni pendant la création d’une application, vous pouvez également ajouter un domaine personnalisé à votre application. Vous pouvez définir un nom de domaine personnalisé sans validation sur vos applications. Si vous utilisez des domaines personnalisés, vous devez vérifier que des enregistrements DNS sont configurés. Vous pouvez suivre l’aide précédente pour configurer des zones et des enregistrements DNS pour un nom de domaine personnalisé (remplacez le nom de domaine par défaut par le nom de domaine personnalisé). Le nom de domaine personnalisé fonctionne pour les demandes d’application, pas pour le site scm. Le site scm est disponible uniquement à l’adresse <appname>.scm.<asename>.appserviceenvironment.net.
Configuration DNS pour l’accès FTP
Pour l’accès FTP à l’App Service Environment (ASE) v3 d’un équilibreur de charge interne (ILB), vous devez vous assurer qu’un DNS est configuré. Configurez une zone privée Azure DNS ou un DNS personnalisé équivalent avec les paramètres suivants :
- Créez une zone privée Azure DNS nommée
ftp.appserviceenvironment.net. - Créez un enregistrement A dans cette zone, qui pointe
<App Service Environment-name>vers l’adresse IP entrante.
En plus de configurer un DNS, vous devez l’activer dans la configuration de l’App Service Environment et au niveau de l’application.
Configuration DNS à partir de votre environnement App Service Environment
Les applications de votre environnement App Service Environment utilisent le DNS avec lequel votre réseau virtuel est configuré. Si vous souhaitez que certaines applications utilisent un serveur DNS différent, vous pouvez le définir manuellement pour chaque application avec les paramètres d’application WEBSITE_DNS_SERVER et WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER configure le serveur DNS secondaire. Le serveur DNS secondaire est utilisé uniquement en l’absence de réponse du serveur DNS principal.