Créer et utiliser un environnement App Service Environment avec équilibreur de charge interne

Important

Cet article concerne la fonctionnalité App Service Environment v2, qui est utilisée avec les plans App Service isolés. App Service Environment v1 et v2 seront mis hors service le 31 août 2024. Il existe une nouvelle version d’App Service Environment, plus facile à utiliser et qui s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la nouvelle version, commencez par consulter Présentation de l’environnement App Service Environment. Si vous utilisez actuellement App Service Environment v1, suivez les étapes de cet article pour migrer vers la nouvelle version.

À compter du 31 août 2024, le Contrat de niveau de service (SLA) et les crédits de service ne s’appliqueront plus aux charges de travail App Service Environment v1 et v2 qui seront toujours en production. La mise hors service du matériel App Service Environment v1 et v2 a commencé, ce qui risque d’avoir une incidence sur la disponibilité et les performances de vos applications et de vos données.

Vous devez effectuer la migration vers App Service Environment v3 immédiatement, sans quoi vos applications et ressources risquent d'être supprimées. Nous ferons tout notre possible pour migrer automatiquement les charges de travail App Service v1 et v2 restantes à l’aide de la fonctionnalité de migration sur place, mais Microsoft ne garantit nullement ni n’affirme que les applications seront disponibles après la migration automatique. Vous serez peut-être amené à effectuer une configuration manuelle pour finaliser la migration et choisir la référence SKU du plan App Service la mieux adaptée à vos besoins. Si la migration automatique n’est pas possible, vos ressources et les données d’application associées seront supprimées. Nous vous recommandons vivement d’agir dès maintenant pour éviter l’un ou l’autre de ces scénarios extrêmes.

Si vous avez besoin de plus de temps, nous pouvons offrir une seule période de grâce de 30 jours pour vous permettre d’effectuer votre migration. Pour plus d’informations et pour demander cette période de grâce, passez en revue la vue d’ensemble de la période de grâce, puis accédez au Portail Azure et accédez au panneau Migration pour chacun de vos environnements App Service.

Pour obtenir les informations les plus à jour sur la mise hors service d’App Service Environment v1/v2, consultez la Mise à jour sur la mise hors service d’App Service Environment v1 et v2.

L’environnement Azure App Service est un déploiement d’Azure App Service dans un sous-réseau de réseau virtuel Azure. Il existe deux façons de déployer un environnement App Service (ASE, App Service Environment) :

• avec une adresse IP virtuelle sur une adresse IP externe, solution souvent appelée ASE externe ;
• avec une adresse IP virtuelle sur une adresse IP interne, solution souvent appelée ASE ILB, car le point de terminaison interne est un équilibreur de charge interne (ILB, Internal Load Balancer).

Cet article explique comment créer un ASE ILB. Pour une présentation de l’ASE, consultez Présentation des environnements App Service. Pour savoir comment créer un ASE externe, consultez [Créer un ASE externe][MakeExternalASE].

Vue d’ensemble

Vous pouvez déployer un ASE avec un point de terminaison accessible via Internet ou avec une adresse IP de votre réseau virtuel. Pour définir l’adresse IP sur une adresse de réseau virtuel, l’ASE doit être déployé avec un ILB. Lorsque vous déployez votre ASE avec un ILB, vous devez indiquer le nom de votre ASE. Le nom de votre ASE est utilisé dans le suffixe du domaine pour les applications dans votre ASE. Le suffixe du domaine pour votre ASE ILB est <nom ASE>.appserviceenvironment.net. Les applications qui sont créées dans un ASE ILB ne sont pas placées dans le DNS public.

Dans les versions antérieures de l’ASE ILB, vous deviez indiquer un suffixe de domaine et un certificat par défaut pour les connexions HTTPS. Le suffixe de domaine n’est plus collecté lors de la création de l’ASE ILB et aucun certificat par défaut n’est collecté. À présent, lorsque vous créez un ASE ILB, le certificat par défaut est fourni par Microsoft et est approuvé par le navigateur. Vous pouvez toujours définir des noms de domaine personnalisés pour les applications dans votre ASE et définir des certificats sur ces noms de domaine personnalisés.

Avec un ASE ILB, vous pouvez effectuer des tâches telles que :

• Héberger des applications intranet en toute sécurité dans le cloud, auquel vous accédez via un réseau de site à site ou ExpressRoute.
• Protéger les applications à l’aide d’un appareil WAF
• héberger des applications dans le cloud qui ne figurent pas dans les serveurs DNS publics ;
• créer des applications principales isolées d’Internet auxquelles vos applications frontales peuvent s’intégrer en toute sécurité.

Fonctionnalités désactivées

Lorsque vous utilisez un ASE ILB, vous ne pouvez pas effectuer certaines opérations :

• utiliser une liaison TLS/SSL basée sur une adresse IP ;
• attribuer des adresses IP à des applications spécifiques ;
• acheter et utiliser un certificat avec une application via le portail Azure. Vous pouvez obtenir des certificats directement auprès d’une autorité de certification et les utiliser avec vos applications. Vous ne pouvez pas les obtenir via le portail Azure.

Créer un environnement ASE ILB

Pour créer un ASE ILB, consultez Créer un ASE à l'aide d'un modèle Azure Resource Manager.

Remarque

Le nom de l’environnement App Service Environment ne doit pas dépasser 36 caractères.

Créer une application dans un ASE ILB

Pour créer une application dans un ASE ILB, procédez de la même façon que pour créer une application dans un ASE normalement.

1. Dans le portail Azure, sélectionnez Créer une ressource>Web>Application web.

2. Entrez le nom de l’application.

3. Sélectionnez l’abonnement.

4. Sélectionnez ou créez un groupe de ressources.

5. Sélectionnez le système de publication, la pile d’exécution et le système d’exploitation.

6. Sélectionnez un emplacement où se trouve un ASE ILB existant.

7. Sélectionnez ou créez un plan App Service.

8. Sélectionnez Vérifier et créer puis sélectionnez Créer lorsque vous êtes prêt.

Tâches Web, fonctions et l’environnement App Service ILB

Les fonctions et les tâches Web sont prises en charge sur un environnement App service ILB, mais pour que le portail interagisse avec eux, vous devez disposer d’un accès réseau vers le site SCM. Cela signifie que votre navigateur doit être sur un ordinateur hôte qui se trouve dans ou connecté au réseau virtuel. Si votre ASE ILB a un nom de domaine qui ne se termine pas par appserviceenvironment.net, vous devrez faire en sorte que votre navigateur approuve le certificat HTTPS utilisé par votre site scm.

Configuration DNS

Lorsque vous utilisez un environnement ASE externe, les applications effectuées dans votre ASE sont inscrites auprès d’Azure DNS. Il n’est pas nécessaire de passer par d’autres étapes dans un ASE externe pour que vos applications soient disponibles publiquement. Avec un environnement ASE ILB, vous devez gérer votre propre service DNS. Vous pouvez effectuer cette opération sur votre propre serveur DNS ou avec des zones privées Azure DNS.

Pour configurer DNS sur votre propre serveur DNS avec votre ASE ILB :

1. créez une zone pour <nom ASE>.appserviceenvironment.net
2. créez un enregistrement A dans cette zone qui pointe * vers l’adresse IP ILB
3. créez un enregistrement A dans cette zone qui pointe @ vers l’adresse IP ILB
4. créez une zone dans le scm nommé <nom ASE>.appserviceenvironment.net
5. créez un enregistrement A dans la zone scm qui pointe * vers l’adresse IP ILB

Pour configurer DNS dans les zones privées Azure DNS :

1. créez une zone privée Azure DNS nommée <nom ASE>.appserviceenvironment.net
2. créez un enregistrement A dans cette zone qui pointe * vers l’adresse IP ILB
3. créez un enregistrement A dans cette zone qui pointe @ vers l’adresse IP ILB
4. créez un enregistrement A dans cette zone qui pointe *.scm vers l’adresse IP ILB

Les paramètres DNS du suffixe de domaine par défaut de votre ASE ne limitent pas vos applications à être accessibles uniquement par ces noms. Vous pouvez définir un nom de domaine personnalisé sans validation sur vos applications dans un environnement ASE ILB. Si vous souhaitez ensuite créer une zone nommée contoso.net, vous pouvez le faire et la pointer vers l’adresse IP ILB. Le nom de domaine personnalisé fonctionne pour les demandes d’application, mais pas pour le site GCL. Le site GCL est disponible uniquement pour <appname>.scm.<asename>.appserviceenvironment.net.

La zone nommée .<asename>.appserviceenvironment.net est globalement unique. Avant mai 2019, les clients pouvaient spécifier le suffixe de domaine de l’ASE ILB. Si vous souhaitez utiliser .contoso.com comme suffixe de domaine, vous pouvez le faire et inclure le site GCL. Ce modèle présentait quelques contraintes au niveau de la gestion du certificat TLS/SSL par défaut, de l’absence d’authentification unique auprès du site GCL et de la nécessité d’utiliser un certificat générique. Le processus de mise à niveau du certificat par défaut de l’ASE ILB entraînait également une interruption du service et le redémarrage de l’application. Pour résoudre ces problèmes, le comportement de l’ASE ILB a été modifié pour utiliser un suffixe de domaine basé sur le nom de l’ASE, avec un suffixe appartenant à Microsoft. La modification apportée au comportement de l’ASE ILB affecte uniquement les environnements ASE ILB créés après mai 2019. Les environnements ASE ILB préexistants doivent toujours gérer le certificat par défaut de l’ASE et leur configuration DNS.

Publier avec un ASE ILB

Pour chaque application créée, il existe deux points de terminaison. Dans un ASE ILB, vous avez <nom d’application>.<Domaine ASE ILB> et <nom d’application>.scm<Domaine ASE ILB> .

Le nom du site SCM vous dirige vers la console Kudu nommée Portail avancé au sein du portail Azure. La console Kudu vous permet d’afficher des variables d’environnement, d’explorer le disque, d’utiliser une console, et bien plus encore. Pour plus d’informations, consultez Console Kudu pour Azure App Service.

Les systèmes d’intégration continue basés sur Internet, comme GitHub et Azure DevOps, continueront de fonctionner avec un environnement ASE d’équilibreur de charge interne si l’agent de build est accessible par Internet et se trouve sur le même réseau que l’environnement ASE d’équilibreur de charge interne. Par conséquent, avec Azure DevOps, si l’agent de build est créé sur le même réseau virtuel que l’environnement ASE d’équilibreur de charge interne (vous pouvez utiliser un autre sous-réseau), il ne pourra pas extraire le code d’Azure DevOps Git et se déployer dans l’environnement ASE d’équilibreur de charge interne. Si vous ne souhaitez pas créer votre propre agent de build, vous devez utiliser un système d’intégration continue qui utilise un modèle d’extraction, par exemple Dropbox.

Les points de terminaison de publication pour les applications d’un environnement ASE d’équilibreur de charge interne utilisent le domaine avec lequel l’environnement ASE d’équilibreur de charge interne a été créé. Ce domaine apparaît dans le profil de publication de l’application et sur le panneau du portail de l’application (Vue d’ensemble>Bases et également Propriétés). Si vous avez un ASE ILB avec le suffixe de domaine <nom ASE>.appserviceenvironment.net et une application nommée mytest, utilisez mytest.<nom ASE>.appserviceenvironment.net pour FTP et mytest.scm.contoso.net pour le déploiement MSDeploy.

Configurer un ASE ILB avec un appareil WAF

Vous pouvez combiner un appareil de pare-feu d’application web (WAF) avec votre ASE ILB pour exposer uniquement les applications souhaitées sur Internet et conserver le reste accessible uniquement à partir du réseau virtuel. Cela vous permet de créer des applications à plusieurs niveaux sécurisées, entre autres choses.

Pour en savoir plus sur la configuration de votre ASE ILB avec un appareil WAF, consultez Configurer un pare-feu d’applications web avec votre environnement App Service. Cet article explique comment utiliser une appliance virtuelle Barracuda avec votre ASE. Une autre option consiste à utiliser Azure Application Gateway. Azure Application Gateway utilise les règles de base OWASP pour sécuriser les applications placées derrière lui. Pour plus d’informations sur Application Gateway, consultez Introduction au pare-feu d’applications web Azure.

ASE ILB créés avant mai 2019

Pour les ASE ILB créés avant mai 2019, vous deviez définir le suffixe de domaine lors de la création de l’ASE. Il était également nécessaire de charger un certificat par défaut qui était basé sur ce suffixe de domaine. En outre, avec un ASE ILB plus ancien vous ne pouvez pas effectuer l’authentification unique sur la console Kudu avec des applications dans cet ASE ILB. Lors de la configuration de DNS pour un ASE ILB plus ancien, vous devez définir l’enregistrement A de caractère générique dans une zone correspondant à votre suffixe de domaine. La création ou la modification de l’ASE ILB avec un suffixe de domaine personnalisé vous impose l’utilisation de modèles Azure Resource Manager et une version d’API antérieure à 2019. La dernière version prise en charge de l’API est 2018-11-01.

Bien démarrer

• Pour bien démarrer avec les ASE, consultez Présentation des environnements App Service.