Azure Application Gateway vous permet d’avoir une application App Service ou un autre service multilocataire en tant que membre de pool principal. Dans cet article, vous allez apprendre à configurer une application App Service avec Application Gateway. La configuration d’Application Gateway diffère selon la façon dont App Service est accessible :
- 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 à permettre à Application Gateway d'accéder à App Service à l’aide de son domaine par défaut, suffixé par «.azurewebsite.net».
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 d’un certificat associé) pour éviter d’avoir à compter sur la valeur par défaut . Domaine Azurewebsite.
Le même nom de domaine pour Application Gateway et App Service dans le pool principal, le flux de requête n’a pas besoin de remplacer le nom d’hôte. L’application web principale voit l’hôte d’origine tel qu’il a été utilisé par le client.
Cette configuration est la plus simple et ne nécessite pas de domaine personnalisé. L’installation s’avère ainsi rapide et pratique.
Quand App Service n’a pas de domaine personnalisé associé à celui-ci : l’en-tête hôte de la requête entrante sur l’application web doit être défini sur le domaine par défaut, suffixe avec .azurewebsites.net » ou bien la plateforme ne pourra pas acheminer correctement la requête.
L’en-tête de l’hôte dans la requête d’origine reçue par Application Gateway est différent du nom d’hôte de l’App Service principal.
Dans cet article, vous apprendrez comment :
- 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
Configuration du 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
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 pour le 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 récupérer le certificat du domaine personnalisé depuis Azure Key Vault.
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. L’absence d’un domaine personnalisé implique qu’aucun certificat signé publiquement n’est 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
Sur le portail Azure, sélectionnez votre passerelle Application Gateway.
Sous Pools principaux, sélectionnez le pool principal.
Sous Type de cible, sélectionnez App Services.
Sous Cible, sélectionnez votre App Service.
Remarque
La liste déroulante remplit uniquement les services d’application qui se trouvent dans le même abonnement que votre application Gateway. Si vous souhaitez utiliser un service d’application qui se trouve dans un abonnement différent de celui dans lequel l’Application Gateway est, au lieu de choisir App Services dans la liste déroulante Cibles , choisissez l’adresse IP ou l’option nom d’hôte et entrez le nom d’hôte (example.azurewebsites.net) du service d’application. Si vous utilisez des points de terminaison privés avec votre App Service, vous devez utiliser le nom de domaine complet ou l’adresse IP du point de terminaison privé à la place.
Sélectionnez Enregistrer.
# 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
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é. Le paramètre HTTP est par défaut utiliser la sonde d’intégrité par défaut. Bien 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é peuvent utiliser 127.0.0.1 comme nom d’hôte vers le pool principal, car aucun nom d’hôte n’a été défini explicitement. 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 connectons au back-end à l’aide du protocole HTTPS.
- Sous Paramètres HTTP, sélectionnez un paramètre HTTP existant ou ajoutez-en un nouveau.
- Attribuez un nom au paramètre HTTP que vous créez
- Sélectionnez HTTPS comme protocole back-end souhaité en utilisant le port 443
- Si le certificat est signé par une autorité reconnue, sélectionnez « Oui » pour « Certificat d'autorité de certification reconnue par l'utilisateur ». Vous pouvez aussi Ajouter des certificats racines d’authentification/approuvés pour les serveurs de back-end
- Veillez à définir « Remplacer par le nouveau nom d’hôte » sur « Non »
- Sélectionnez la sonde d’intégrité HTTPS personnalisée dans la liste déroulante pour « Sonde personnalisée ».
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.
- Sous Paramètres HTTP, sélectionnez un paramètre HTTP existant ou ajoutez-en un nouveau.
- Attribuez un nom au paramètre HTTP que vous créez
- Sélectionnez HTTPS comme protocole back-end souhaité en utilisant le port 443
- 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 de back-end
- Veillez à définir « Remplacer par le nouveau nom d’hôte » sur « Oui »
- Sous « Remplacement du nom d’hôte », sélectionnez « Choisir le nom d’hôte à partir de la cible back-end ». Ce paramètre entraîne la demande vers App Service d’utiliser le nom d’hôte « azurewebsites.net », tel qu’il est configuré dans le pool principal.
# 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
# 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
Pour accepter le trafic, nous devons configurer un écouteur. Pour plus d’informations sur l’écouteur, consultez la configuration de l’écouteur Application Gateway.
- Ouvrez la section « Écouteurs » et choisissez « Ajouter un écouteur » ou sélectionnez un écouteur existant à modifier.
- S’il s’agit d’un nouvel écouteur, donnez-lui un nom
- Sous « IP frontale », sélectionnez l’adresse IP sur laquelle écouter
- Sous « Port », sélectionnez 443
- Sous « Protocole », sélectionnez « HTTPS »
- Sous « Choisir un certificat », sélectionnez « Choisir un certificat dans Key Vault ». Pour plus d’informations, consultez Utilisation de Key Vault où vous trouverez plus d’informations sur la façon d’affecter une identité managée et de lui fournir des droits sur votre coffre de clés.
- Attribuez un nom au certificat
- Sélectionnez l’identité managée
- Sélectionner le coffre de clés dans lequel récupérer le certificat
- Sélectionner le certificat
- Sous « Type d’écouteur », sélectionnez « De base »
- Sélectionnez « Ajouter » pour ajouter l’écouteur
En supposant qu’il n’existe aucun domaine personnalisé ou certificat associé, configurez Application Gateway pour écouter le trafic HTTP sur le port 80. Ou bien, consultez les instructions de la page Créer un certificat auto-signé
- Ouvrez la section « Écouteurs » et choisissez « Ajouter un écouteur » ou sélectionnez un écouteur existant à modifier.
- S’il s’agit d’un nouvel écouteur, donnez-lui un nom
- Sous « IP frontale », sélectionnez l’adresse IP sur laquelle écouter
- Sous « Port », sélectionnez 80
- Sous « Protocole », sélectionnez « HTTP »
# 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
Dans de nombreux cas, un écouteur public pour HTTP sur le port 80 existe. Le script ci-dessous en crée 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
}
Le Backend Pool précédemment configuré et les paramètres HTTP, la règle de routage des requêtes peut être configurée pour acheminer le trafic à partir d’un écouteur et le diriger vers le Backend Pool en utilisant les paramètres HTTP. Pour cela, vérifiez que vous disposez d’un écouteur HTTP ou HTTPS disponible qui n’est pas déjà lié à une règle de routage existante.
- Sous « Règles », sélectionnez pour ajouter une nouvelle « règle de routage des demandes »
- Attribuez un nom à la règle
- Sélectionnez un écouteur HTTP ou HTTPS qui n’est pas encore lié à une règle de routage existante
- Sous « Cibles de back-end », choisissez le pool de back-ends dans lequel App Service a été configuré
- Configurez les paramètres HTTP avec lesquels Application Gateway doit se connecter au back-end App Service
- Sélectionnez « Ajouter » pour enregistrer cette configuration
$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 :
Ouvrez la section « Intégrité du back-end » et vérifiez que la colonne « État » indique la combinaison pour le paramètre HTTP et le pool principal comme « Sain ».
À présent, accédez à l’application web en utilisant l’adresse IP d’Application Gateway ou le nom DNS associé à l’adresse IP. Les deux sont disponibles dans la page « Vue d’ensemble » d’Application Gateway sous « Essentials ». La ressource Adresse IP publique affiche également l’adresse IP et le nom DNS associé.
Faites attention à la liste non exhaustive suivante des symptômes potentiels lors du test de l’application :
- Les redirections pointant vers .azurewebsite.net directement au lieu de l'Application Gateway
- inclut des redirections d’authentification qui essaient d’accéder directement à .azurewebsite.net »
- cookies liés au domaine non transmis au back-end
- inclure 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.
Ouvrez la section « Intégrité du back-end » et vérifiez que la colonne « État » indique la combinaison pour le paramètre HTTP et le pool principal comme « Sain ».
À 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.
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 demandons du contenu à partir d’App Service via Application Gateway à l’aide du domaine personnalisé :
$customDomainName = "<FQDN for custom domain pointing to Application Gateway>"
Invoke-WebRequest $customDomainName
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 demandons du contenu à partir d’App Service via Application Gateway à l’aide de 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)"
Faites attention à la liste non exhaustive suivante des symptômes potentiels lors du test 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. La méthode recommandée pour gérer cette condition consiste à suivre les instructions de configuration d’Application Gateway avec App Service à l’aide d’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. Toutefois, si vous envisagez de déployer une fonctionnalité en production, vous souhaitez ajouter d’autres restrictions. Considérez les options suivantes :