Configurer App Service avec Application Gateway

Application Gateway vous permet d’avoir une application App Service ou un autre service multilocataire en tant que membre du pool back-end. Dans cet article, vous allez apprendre à configurer une application App Service avec Application Gateway. La configuration pour Application Gateway varie en fonction du mode d’accès à App Service :

• La première option repose sur l’utilisation d’un domaine personnalisé dans Application Gateway et App Service au niveau du back-end.
• La deuxième option consiste à faire utiliser le domaine par défaut à Application Gateway (dont le suffixe est « .azurewebsites.net ») pour accéder à App Service.

Domaine personnalisé (recommandé)

Cette configuration est recommandée pour les scénarios de niveau production et respecte le principe de pas modifier le nom d’hôte dans le flux de requête. Vous devez disposer d’un domaine personnalisé (et du certificat associé) pour éviter d’avoir à utiliser le domaine « .azurewebsites » par défaut.

En associant le même nom de domaine à Application Gateway et App Service dans le pool back-end, le flux de requête n’a pas besoin de remplacer le nom d’hôte. L’application web back-end voit alors l’hôte d’origine tel qu’il était utilisé par le client.

Domaine par défaut

Cette configuration est la plus simple et ne nécessite pas de domaine personnalisé. L’installation s’avère ainsi rapide et pratique.

Avertissement

Cette configuration présente des limitations. Nous vous recommandons de prendre connaissance des implications d’une utilisation de noms d’hôte différents entre le client et Application Gateway et entre l’application et App Service au niveau du back-end. Pour plus d’informations, consultez l’article dans le Centre des architectures : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end

Quand aucun domaine personnalisé n’est associé à App Service, l’en-tête Host de la requête entrante dans l’application web doit être défini sur le domaine par défaut, avec le suffixe « .azurewebsites.net ». À défaut, la plateforme ne pourra pas router correctement la requête.

L’en-tête Host de la requête d’origine reçue par Application Gateway sera différent du nom d’hôte de l’App Service back-end.

Cet article porte sur les points suivants :

• Configurer DNS
• Ajouter App Service en tant que pool back-end à Application Gateway
• Configurer les paramètres HTTP pour la connexion à App Service
• Configurer un écouteur HTTP
• Créer une règle de routage de requête

Prérequis

Domaine personnalisé (recommandé)

• Application Gateway : créez une passerelle applicative sans cible de pool back-end. Pour plus d’informations, consultez Démarrage rapide : Diriger le trafic web avec Azure Application Gateway – Portail Azure

• App Service : si vous n’avez pas encore d’App Service, consultez la documentation App Service.

• Un nom de domaine personnalisé et le certificat associé (signé par une autorité connue), stockés dans Key Vault. Pour plus d’informations sur le stockage de certificats dans Key Vault, consultez Tutoriel : Importer un certificat dans Azure Key Vault

Domaine par défaut

• Application Gateway : créez une passerelle applicative sans cible de pool back-end. Pour plus d’informations, consultez Démarrage rapide : Diriger le trafic web avec Azure Application Gateway – Portail Azure

• App Service : si vous n’avez pas encore d’App Service, consultez la documentation App Service.

Configuration du système DNS

Dans le contexte de ce scénario, DNS est pertinent à deux endroits :

• Le nom DNS, que l’utilisateur ou le client utilise pour Application Gateway et ce qui apparaît dans un navigateur
• Le nom DNS, dont se sert en interne Application Gateway pour accéder à App Service au niveau du back-end

Domaine personnalisé (recommandé)

Routez l’utilisateur ou le client vers Application Gateway en utilisant le domaine personnalisé. Configurez DNS en utilisant un alias CNAME pointant vers le DNS d’Application Gateway. L’adresse DNS d’Application Gateway figure dans la page de présentation de l’adresse IP publique associée. Vous pouvez aussi créer un enregistrement A pointant directement vers l’adresse IP. (Dans le cas d’Application Gateway V1, l’adresse IP virtuelle peut changer si vous arrêtez et démarrez le service, ce qui rend cette option indésirable.)

App Service doit être configuré de façon à accepter le trafic en provenance d’Application Gateway en utilisant le nom de domaine personnalisé comme hôte entrant. Pour plus d’informations sur la façon de mapper un domaine personnalisé à App Service, consultez Tutoriel : Mapper un nom DNS personnalisé existant à Azure App Service. Pour vérifier le domaine, App Service exige uniquement l’ajout d’un enregistrement TXT. Les enregistrements CNAME ou A n’ont pas besoin d’être modifiés. La configuration DNS du domaine personnalisé reste dirigée vers Application Gateway.

Pour accepter les connexions à App Service via HTTP, configurez sa liaison TLS. Pour plus d’informations, consultez Sécuriser un nom DNS personnalisé avec une liaison TLS/SSL dans Azure App Service. Configurez App Service pour extraire le certificat du domaine personnalisé auprès d’Azure Key Vault.

Domaine par défaut

Quand aucun domaine personnalisé n’est disponible, l’utilisateur ou le client peut accéder à Application Gateway en utilisant l’adresse IP de la passerelle ou son adresse DNS. L’adresse DNS d’Application Gateway se trouve dans la page de présentation de l’adresse IP publique associée. Si aucun domaine personnalisé n’est disponible, cela signifie qu’aucun certificat signé publiquement ne sera disponible pour TLS sur Application Gateway. Les clients sont contraints d’utiliser HTTP ou HTTPS avec un certificat auto-signé, deux options qui ne sont pas souhaitables.

Pour se connecter à App Service, Application Gateway utilise le domaine par défaut fourni par App Service (avec le suffixe « azurewebsites.net »).

Ajouter un service d’application comme pool de back-ends

Azure portal

1. Sur le portail Azure, sélectionnez votre passerelle Application Gateway.

2. Sous Pools principaux, sélectionnez le pool principal.

3. Sous Type de cible, sélectionnez App Services.

4. Sous Cible, sélectionnez votre App Service.

   

   Remarque

   Le menu déroulant ne renseigne que les services d’application figurant dans le même abonnement que votre Application Gateway. Si vous voulez utiliser un service d’application qui relève d’un autre abonnement que celui où se trouve Application Gateway, au lieu de choisir App Services dans le menu déroulant Cibles, choisissez l’option Adresse IP ou nom d’hôte, puis entrez le nom d'hôte (example.azurewebsites.net) du service d’application.

5. Sélectionnez Enregistrer.

PowerShell

# Fully qualified default domain name of the web app:
$webAppFQDN = "<nameofwebapp>.azurewebsite.net"

# For Application Gateway: both name, resource group and name for the backend pool to create:
$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$appGwBackendPoolNameForAppSvc = "<name for backend pool to be added>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Add a new Backend Pool with App Service in there:
Add-AzApplicationGatewayBackendAddressPool -Name $appGwBackendPoolNameForAppSvc -ApplicationGateway $gw -BackendFqdns $webAppFQDN

# Update Application Gateway with the new added Backend Pool:
Set-AzApplicationGateway -ApplicationGateway $gw

Modifier les paramètres HTTP pour App Service

Azure portal

Un paramètre HTTP est nécessaire pour donner instruction à Application Gateway d’accéder au back-end App Service en utilisant le nom de domaine personnalisé. Par défaut, le paramètre HTTP utilise la sonde d’intégrité par défaut. Alors que les sondes d’intégrité par défaut transfèrent les requêtes avec le nom d’hôte dans lequel le trafic est reçu, les sondes d’intégrité utilisent 127.0.0.1 comme nom d’hôte pour le pool de back-ends, car aucun nom d’hôte n’a été explicitement défini. Pour cette raison, vous devez créer une sonde d’intégrité personnalisée configurée avec le nom de domaine personnalisé approprié en guise de nom d’hôte.

Nous nous connecterons au back-end en utilisant HTTPS.

1. Sous Paramètres HTTP, sélectionnez un paramètre HTTP existant ou ajoutez-en un nouveau.
2. Attribuez un nom au paramètre HTTP que vous créez
3. Sélectionnez HTTPS comme protocole back-end souhaité en utilisant le port 443
4. Si le certificat est signé par une autorité connue, sélectionnez « Oui » pour « Certificat d’autorité de certification connu de l’utilisateur ». Vous pouvez aussi Ajouter des certificats racines d’authentification/approuvés pour les serveurs back-end
5. Veillez à définir « Remplacer par le nouveau nom d’hôte » sur « Non »
6. Sélectionnez la sonde d’intégrité HTTPS personnalisée dans la liste déroulante « Sonde personnalisé ».

Azure portal

Un paramètre HTTP est nécessaire pour donner instruction à Application Gateway d’accéder au back-end App Service en utilisant le nom de domaine (« azurewebsites ») par défaut. Pour ce faire, le paramètre HTTP remplace explicitement le nom d’hôte.

1. Sous Paramètres HTTP, sélectionnez un paramètre HTTP existant ou ajoutez-en un nouveau.
2. Attribuez un nom au paramètre HTTP que vous créez
3. Sélectionnez HTTPS comme protocole back-end souhaité en utilisant le port 443
4. Si le certificat est signé par une autorité connue, sélectionnez « Oui » pour « Certificat d’autorité de certification connu de l’utilisateur ». Vous pouvez aussi Ajouter des certificats racines d’authentification/approuvés pour les serveurs back-end
5. Veillez à définir « Remplacer par le nouveau nom d’hôte » sur « Oui »
6. Sous « Remplacement du nom d’hôte », sélectionnez « Choisir un nom d’hôte à partir d’une cible de back-end ». Ce paramètre amène la requête en direction d’App Service à utiliser le nom d’hôte « azurewebsites.net », tel que configuré dans le pool back-end.

PowerShell

# Configure Application Gateway to connect to App Service using the incoming hostname
$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$customProbeName = "<name for custom health probe>"
$customDomainName = "<FQDN for custom domain associated with App Service>"
$httpSettingsName = "<name for http settings to be created>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Add custom health probe using custom domain name:
Add-AzApplicationGatewayProbeConfig -Name $customProbeName -ApplicationGateway $gw -Protocol Https -HostName $customDomainName -Path "/" -Interval 30 -Timeout 120 -UnhealthyThreshold 3
$probe = Get-AzApplicationGatewayProbeConfig -Name $customProbeName -ApplicationGateway $gw

# Add HTTP Settings to use towards App Service:
Add-AzApplicationGatewayBackendHttpSettings -Name $httpSettingsName -ApplicationGateway $gw -Protocol Https -Port 443 -Probe $probe -CookieBasedAffinity Disabled -RequestTimeout 30

# Update Application Gateway with the new added HTTP settings and probe:
Set-AzApplicationGateway -ApplicationGateway $gw

PowerShell

# Configure Application Gateway to connect to backend using default App Service hostname
$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$httpSettingsName = "<name for http settings to be created>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Add HTTP Settings to use towards App Service:
Add-AzApplicationGatewayBackendHttpSettings -Name $httpSettingsName -ApplicationGateway $gw -Protocol Https -Port 443 -PickHostNameFromBackendAddress -CookieBasedAffinity Disabled -RequestTimeout 30

# Update Application Gateway with the new added HTTP settings and probe:
Set-AzApplicationGateway -ApplicationGateway $gw

Configurer un écouteur HTTP

Pour accepter le trafic, nous devons configurer un écouteur. Pour plus d’informations sur la question, consultez Configuration des écouteurs Application Gateway.

Azure portal

1. Ouvrez la section « Écouteurs » et choisissez « Ajouter un écouteur », ou cliquez sur un écouteur existant pour le modifier
2. S’il s’agit d’un nouvel écouteur, donnez-lui un nom
3. Sous « Adresse IP du front-end », sélectionnez l’adresse IP à écouter
4. Sous « Port », sélectionnez 443
5. Sous « Protocole », sélectionnez « HTTPS »
6. Sous « Choisir un certificat », sélectionnez « Choisir un certificat à partir de Key Vault ». Pour plus d’informations, consultez Utilisation de Key Vault où vous trouverez des informations sur la façon d’attribuer une identité managée et de la doter de droits d’accès à votre coffre de clés.
   1. Attribuez un nom au certificat
   2. Sélectionnez l’identité managée
   3. Sélectionner le coffre de clés dans lequel récupérer le certificat
   4. Sélectionner le certificat
7. Sous « Type d’écouteur », sélectionnez « De base »
8. Cliquez sur « Ajouter » pour ajouter l’écouteur

Azure portal

À supposer que nous ne disposons d’aucun domaine personnalisé ou de certificat associé, nous allons configurer Application Gateway pour une écoute du trafic HTTP sur le port 80. Ou bien, consultez les instructions de la page Créer un certificat auto-signé

1. Ouvrez la section « Écouteurs » et choisissez « Ajouter un écouteur », ou cliquez sur un écouteur existant pour le modifier
2. S’il s’agit d’un nouvel écouteur, donnez-lui un nom
3. Sous « Adresse IP du front-end », sélectionnez l’adresse IP à écouter
4. Sous « Port », sélectionnez 80
5. Sous « Protocole », sélectionnez « HTTPS »

PowerShell

# This script assumes that:
# - a certificate was imported in Azure Key Vault already
# - a managed identity was assigned to Application Gateway with access to the certificate
# - there is no HTTP listener defined yet for HTTPS on port 443

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$appGwSSLCertificateName = "<name for ssl cert to be created within Application Gateway"
$appGwSSLCertificateKeyVaultSecretId = "<key vault secret id for the SSL certificate to use>"
$httpListenerName = "<name for the listener to add>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Create SSL certificate object for Application Gateway:
Add-AzApplicationGatewaySslCertificate -Name $appGwSSLCertificateName -ApplicationGateway $gw -KeyVaultSecretId $appGwSSLCertificateKeyVaultSecretId
$sslCert = Get-AzApplicationGatewaySslCertificate -Name $appGwSSLCertificateName -ApplicationGateway $gw

# Fetch public ip associated with Application Gateway:
$ipAddressResourceId = $gw.FrontendIPConfigurations.PublicIPAddress.Id
$ipAddressResource = Get-AzResource -ResourceId $ipAddressResourceId
$publicIp = Get-AzPublicIpAddress -ResourceGroupName $ipAddressResource.ResourceGroupName -Name $ipAddressResource.Name

$frontendIpConfig = $gw.FrontendIpConfigurations | Where-Object {$_.PublicIpAddress -ne $null}

$port = New-AzApplicationGatewayFrontendPort -Name "port_443" -Port 443
Add-AzApplicationGatewayFrontendPort -Name "port_443" -ApplicationGateway $gw -Port 443
Add-AzApplicationGatewayHttpListener -Name $httpListenerName -ApplicationGateway $gw -Protocol Https -FrontendIPConfiguration $frontendIpConfig -FrontendPort $port -SslCertificate $sslCert

# Update Application Gateway with the new HTTPS listener:
Set-AzApplicationGateway -ApplicationGateway $gw

PowerShell

Dans bien des cas, il existe déjà un écouteur public pour HTTP sur le port 80. Le script ci-dessous en créera un, si ce n’est pas encore le cas.

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$httpListenerName = "<name for the listener to add if not exists yet>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Check if HTTP listener on port 80 already exists:
$port = $gw.FrontendPorts | Where-Object {$_.Port -eq 80}
$listener = $gw.HttpListeners | Where-Object {$_.Protocol.ToString().ToLower() -eq "http" -and $_.FrontendPort.Id -eq $port.Id}

if ($listener -eq $null){
    $frontendIpConfig = $gw.FrontendIpConfigurations | Where-Object {$_.PublicIpAddress -ne $null}
    Add-AzApplicationGatewayHttpListener -Name $httpListenerName -ApplicationGateway $gw -Protocol Http -FrontendIPConfiguration $frontendIpConfig -FrontendPort $port

    # Update Application Gateway with the new HTTPS listener:
    Set-AzApplicationGateway -ApplicationGateway $gw
}

Configurer une règle de routage des demandes

Avec le pool back-end et des paramètres HTTP configurés précédemment, la règle de routage des demandes peut être configurée de façon à accepter le trafic d’un écouteur et à le router vers le pool back-end en utilisant les paramètres HTTP. Pour cela, vérifiez que vous disposez d’un écouteur HTTP ou HTTPS et qu’il n’est pas déjà lié à une règle de routage existante.

Azure portal

1. Sous « Règles », cliquez pour ajouter une nouvelle « Règle de routage des demandes »
2. Attribuez un nom à la règle
3. Sélectionnez un écouteur HTTP ou HTTPS qui n’est pas encore lié à une règle de routage existante
4. Sous « Cibles de back-end », choisissez le pool back-end dans lequel App Service a été configuré
5. Configurez les paramètres HTTP avec lesquels Application Gateway doit se connecter au back-end App Service
6. Sélectionnez « Ajouter » pour enregistrer cette configuration

PowerShell

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"
$httpListenerName = "<name for existing http listener (without rule) to route traffic from>"
$httpSettingsName = "<name for http settings to use>"
$appGwBackendPoolNameForAppSvc = "<name for backend pool to route to>"
$reqRoutingRuleName = "<name for request routing rule to be added>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Get HTTP Settings:
$httpListener = Get-AzApplicationGatewayHttpListener -Name $httpListenerName -ApplicationGateway $gw
$httpSettings = Get-AzApplicationGatewayBackendHttpSettings -Name $httpSettingsName -ApplicationGateway $gw
$backendPool = Get-AzApplicationGatewayBackendAddressPool -Name $appGwBackendPoolNameForAppSvc -ApplicationGateway $gw

# Add routing rule:
Add-AzApplicationGatewayRequestRoutingRule -Name $reqRoutingRuleName -ApplicationGateway $gw -RuleType Basic -BackendHttpSettings $httpSettings -HttpListener $httpListener -BackendAddressPool $backendPool

# Update Application Gateway with the new routing rule:
Set-AzApplicationGateway -ApplicationGateway $gw

Test

Avant de commencer, vérifiez que l’état du back-end est sain :

Azure portal

Ouvrez la section « Intégrité principale » et vérifiez que la colonne « État » indique « Sain » à la fois pour le paramètre HTTP et pour le pool back-end.

À présent, accédez à l’application web en utilisant l’adresse IP d’Application Gateway ou le nom DNS associé à l’adresse IP. Vous trouverez les deux dans la page « Vue d’ensemble » d’Application Gateway sous la forme d’une propriété, sous « Éléments principaux ». Sinon, la ressource Adresse IP publique indique également l’adresse IP et le nom DNS associé.

Soyez attentif à la liste non exhaustive des symptômes potentiels suivants durant les tests de l’application :

• redirections pointant directement vers « .azurewebsites.net » et non vers Application Gateway
• cela concerne notamment les redirections d’authentification qui tentent d’accéder directement à « .azurewebsites.net »
• cookies liés au domaine non transmis au back-end
• cela inclut l’utilisation du paramètre « Affinité ARR » dans App Service

Les conditions ci-dessus (expliquées plus en détail dans le Centre des architectures) indiquent que votre application web ne gère pas bien la réécriture du nom d’hôte. Cela est couramment vu. Le meilleur moyen de régler ce problème est de suivre les instructions de configuration d’Application Gateway avec App Service en utilisant un domaine personnalisé. Voir aussi : Résoudre les problèmes d’App Service dans Application Gateway.

Azure portal

Ouvrez la section « Intégrité principale » et vérifiez que la colonne « État » indique « Sain » à la fois pour le paramètre HTTP et pour le pool back-end.

À présent, accédez à l’application web en utilisant le domaine personnalisé que vous avez associé à Application Gateway et à App Service au niveau du back-end.

PowerShell

Vérifiez que l’état du back-end et des paramètres HTTP indique « Sain » :

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Check health:
Get-AzApplicationGatewayBackendHealth -ResourceGroupName $rgName -Name $appGwName

Pour tester la configuration, nous allons demander du contenu à App Service via Application Gateway en utilisant le domaine personnalisé :

$customDomainName = "<FQDN for custom domain pointing to Application Gateway>"
Invoke-WebRequest $customDomainName

PowerShell

Vérifiez que l’état du back-end et des paramètres HTTP indique « Sain » :

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Check health:
Get-AzApplicationGatewayBackendHealth -ResourceGroupName $rgName -Name $appGwName

Pour tester la configuration, nous allons demander du contenu à App Service via Application Gateway en utilisant l’adresse IP :

$rgName = "<name of resource group for App Gateway>"
$appGwName = "<name of the App Gateway>"

# Get existing Application Gateway:
$gw = Get-AzApplicationGateway -Name $appGwName -ResourceGroupName $rgName

# Get ip address:
$ipAddressResourceId = $gw.FrontendIPConfigurations.PublicIPAddress.Id
$ipAddressResource = Get-AzResource -ResourceId $ipAddressResourceId
$publicIp = Get-AzPublicIpAddress -ResourceGroupName $ipAddressResource.ResourceGroupName -Name $ipAddressResource.Name
Write-Host "Public ip address for Application Gateway is $($publicIp.IpAddress)"
Invoke-WebRequest "http://$($publicIp.IpAddress)"

Soyez attentif à la liste non exhaustive des symptômes potentiels suivants durant les tests de l’application :

• redirections pointant directement vers « .azurewebsites.net » et non vers Application Gateway
• cela concerne notamment les redirections d’authentification App Service qui tentent d’accéder directement à « .azurewebsites.net »
• cookies liés au domaine non transmis au back-end
• cela inclut l’utilisation du paramètre « Affinité ARR » dans App Service

Les conditions ci-dessus (expliquées plus en détail dans le Centre des architectures) indiquent que votre application web ne gère pas bien la réécriture du nom d’hôte. Cela est couramment vu. Le meilleur moyen de régler ce problème est de suivre les instructions de configuration d’Application Gateway avec App Service en utilisant un domaine personnalisé. Voir aussi : Résoudre les problèmes d’App Service dans Application Gateway.

Restriction de l’accès

Les applications web déployées dans ces exemples utilisent des adresses IP publiques qui sont accessibles directement à partir d’Internet. La résolution des problèmes s’en trouve facilitée quand vous découvrez une nouvelle fonctionnalité et essayez de nouvelles choses. Mais si vous prévoyez de déployer une fonctionnalité sur l’environnement de production, l’ajout de restrictions peut vous sembler approprié. Considérez les options suivantes :

• Configurer Règles de restriction d’accès basées sur des points de terminaison de service. Cela vous permet de verrouiller l’accès entrant à l’application en vérifiant que l’adresse source provient d’Application Gateway.
• Utiliser des restrictions d’adresses IP statiques Azure App Service. Par exemple, vous pouvez restreindre l’accès à l’application web au trafic transitant par la passerelle d’application. Utilisez la fonctionnalité de restriction IP avec App Service pour répertorier l’adresse IP virtuelle de la passerelle d’application comme étant la seule adresse bénéficiant d’un accès.