Настройка службы приложений с помощью шлюза приложений

Эта конфигурация рекомендуется для сценариев производственного уровня и соответствует практике не изменять имя узла в потоке запросов. Необходимо иметь собственный домен (и связанный сертификат), чтобы избежать необходимости полагаться на домен по умолчанию ".Azurewebsite".

Одно и то же доменное имя для шлюза приложений и службы приложений в серверном пуле, поток запросов не должен переопределить имя узла. Серверное веб-приложение видит исходный хост так, как его использовал клиент.

Эта конфигурация является самой простой и не требует личного домена. Таким образом, это позволяет быстро и удобно настроить.

Если у службы приложений нет личного домена, связанного с ним, заголовок хоста для входящего запроса в веб-приложении должен быть установлен со стандартным доменом, оканчивающимся на ".azurewebsites.net", иначе платформа не сможет правильно маршрутизировать запрос.

Заголовок узла в исходном запросе, полученный шлюзом приложений, отличается от имени узла серверной службы приложений.

• Шлюз приложений. Создание шлюза приложений без целевого объекта внутреннего пула. Дополнительные сведения см. в разделе «Быстрое начало: управление веб-трафиком с помощью шлюза приложений Azure через портал Azure»

• Служба приложений. Если у вас нет существующей службы приложений, см. документацию по службе приложений.

• Имя пользовательского домена и связанный сертификат (подписанный авторитетным центром сертификации), хранящийся в Key Vault. Дополнительные сведения о хранении сертификатов в Key Vault см. в руководстве по импорту сертификата в Azure Key Vault.

• Настраиваемая проба работоспособности, настроенная в шлюзе приложений, которая использует имя личного домена в качестве имени узла. Сведения о создании пользовательской пробы работоспособности см. в статье "Создание пользовательской пробы работоспособности".

• Шлюз приложений. Создание шлюза приложений без целевого объекта внутреннего пула. Дополнительные сведения см. в разделе «Быстрое начало: управление веб-трафиком с помощью шлюза приложений Azure через портал Azure»

• Служба приложений. Если у вас нет существующей службы приложений, см. документацию по службе приложений.

Перенаправите пользователя или клиента в Шлюз приложений с помощью личного домена. Настройте DNS с помощью псевдонима CNAME, направляемого на DNS для шлюза приложений. DNS-адрес шлюза приложений отображается на странице обзора связанного общедоступного IP-адреса. Кроме того, создайте запись A, указывающую на IP-адрес напрямую. (Для шлюза приложений версии 1 виртуальный IP-адрес может измениться при остановке и запуске службы, что делает этот параметр нежелательным.)

Служба приложений должна быть настроена таким образом, чтобы он принимал трафик из шлюза приложений, используя имя личного домена в качестве входящего узла. Дополнительные сведения о сопоставлении пользовательского домена с Службой приложений Azure см. в руководстве: Сопоставление существующего пользовательского DNS-имени со службой приложений Azure. Для проверки домена Служба приложений Azure требует только добавления записи TXT. Для записи CNAME или A-records не требуется никаких изменений. Конфигурация DNS для личного домена остается направлена на шлюз приложений.

Чтобы принять подключения к службе приложений по протоколу HTTPS, настройте ее привязку TLS. Дополнительные сведения см. в статье «Защита пользовательского DNS-имени с помощью привязки TLS/SSL в Службе приложений Azure». Настройте Службу приложений для извлечения сертификата для пользовательского домена из Azure Key Vault.

Если личный домен недоступен, пользователь или клиент могут получить доступ к шлюзу приложений с помощью IP-адреса шлюза или DNS-адреса. DNS-адрес шлюза приложений можно найти на странице сведений общественного IP-адреса, с которым он связан. Отсутствие личного домена означает, что общедоступный подписанный сертификат недоступен для TLS в шлюзе приложений. Клиенты ограничены в использовании протоколов HTTP или HTTPS с самозаверяющим сертификатом, что в обоих случаях нежелательно.

Для подключения к службе приложений Шлюз приложений использует домен по умолчанию, предоставляемый службой приложений (суффикс "azurewebsites.net").

1. На портале Azure выберите шлюз приложений.

2. В разделе "Серверные пулы" выберите внутренний пул.

3. В разделе "Целевой тип" выберите "Службы приложений".

4. В разделе "Целевой" выберите службу приложений.

   

   Замечание

   Раскрывающийся список заполняется только теми службами приложений, которые входят в ту же подписку, что и ваш шлюз приложений. Если вы хотите использовать службу приложений, которая находится в подписке, отличной от подписки, в которой находится шлюз приложений, вместо выбора служб приложений в раскрывающемся списке "Целевые объекты", выберите IP-адрес или имя узла и введите имя узла (example.azurewebsites.net) службы приложений. Если вы используете частные конечные точки со службой приложений, вместо этого следует использовать полное доменное имя частной конечной точки или IP-адрес.

5. Нажмите кнопку "Сохранить".

# 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

Параметр HTTP требуется, чтобы шлюз приложений получил доступ к серверной части службы приложений с помощью пользовательского домена. Параметр HTTP по умолчанию использует стандартную пробу работоспособности. Хотя пробы работоспособности по умолчанию переадресуют запросы по имени узла, с которого получен трафик, они могут использовать 127.0.0.1 в качестве имени узла для пула серверов бэкенда, поскольку конкретное имя узла явно не определено. По этой причине необходимо создать настраиваемую проверку работоспособности, которая будет настроена с правильным кастомным доменным именем в качестве имени узла.

Мы подключаемся к серверной части с помощью HTTPS.

1. В разделе "Параметры HTTP" выберите существующий параметр HTTP или добавьте новый.
2. При создании нового параметра HTTP присвойте ему имя
3. Выберите HTTPS в качестве требуемого внутреннего протокола с помощью порта 443
4. Если сертификат подписан хорошо известным центром сертификации, выберите "Да" для параметра "Сертификат известного центра сертификации". Кроме того, можно добавить сертификаты проверки подлинности и доверенные корневые сертификаты серверов бэкенда
5. Обязательно установите для параметра "Переопределение с новым именем узла" значение "Нет"
6. Выберите пользовательскую пробу работоспособности HTTPS в раскрывающемся списке "Настраиваемая проба".

Необходим параметр HTTP, чтобы шлюз приложений получил доступ к серверу обратной стороны службы приложений, используя доменное имя по умолчанию ("azurewebsites.net"). Для этого параметр HTTP явно переопределит имя узла.

1. В разделе "Параметры HTTP" выберите существующий параметр HTTP или добавьте новый.
2. При создании нового параметра HTTP присвойте ему имя
3. Выберите HTTPS в качестве требуемого внутреннего протокола с помощью порта 443
4. Если сертификат подписан известным центром сертификации, выберите "Да" для параметра 'Известный центр сертификации пользователя'. В качестве альтернативы можно добавить сертификаты проверки подлинности и доверенные корневые сертификаты серверов заднего плана
5. Установите для параметра "Переопределение с новым именем хоста" значение "Да"
6. В разделе "Переопределение имени узла" выберите "Выбрать имя узла из серверного целевого объекта". Этот параметр приводит к тому, что запрос к службе приложений будет использовать имя узла "azurewebsites.net", как настроено в серверном пуле.

# 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

1. Откройте раздел "Прослушиватели" и выберите "Добавить прослушиватель" или выберите существующий для редактирования.
2. Для нового слушателя: дайте ему имя
3. В разделе "Внешний IP-адрес" выберите IP-адрес для прослушивания
4. В разделе "Порт" выберите 443
5. В разделе "Протокол", выберите "HTTPS"
6. В разделе "Выбор сертификата" выберите "Выбрать сертификат из Key Vault". Дополнительные сведения см. в разделе "Использование Key Vault ", где вы найдете дополнительные сведения о том, как назначить управляемое удостоверение и предоставить ему права на хранилище ключей.
   1. Присвойте сертификату имя
   2. Выберите управляемое удостоверение
   3. Выберите Key Vault, из которого нужно получить сертификат.
   4. Выберите сертификат
7. В разделе "Тип прослушивателя" выберите "Базовый"
8. Нажмите кнопку "Добавить", чтобы добавить прослушиватель

Если нет личного домена или связанного сертификата, настройте шлюз приложений для прослушивания трафика HTTP через порт 80. Кроме того, ознакомьтесь с инструкциями по созданию самозаверяющего сертификата.

1. Откройте раздел "Прослушиватели" и выберите "Добавить прослушиватель" или выберите существующий для редактирования.
2. Для нового слушателя: дайте ему имя
3. В разделе "Внешний IP-адрес" выберите IP-адрес для прослушивания
4. В разделе "Порт" выберите 80
5. В разделе "Протокол", выберите "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

Во многих случаях общедоступный прослушиватель http через порт 80 существует. Приведенный ниже сценарий создает один, если это еще не так.

$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
}

1. В разделе "Правила" выберите добавить новое правило маршрутизации запросов.
2. Укажите правило с именем
3. Выберите прослушиватель HTTP или HTTPS, который еще не привязан к существующему правилу маршрутизации
4. В разделе "Целевые объекты серверной части" выберите серверный пул, в котором настроена служба приложений.
5. Настройка параметров HTTP, с помощью которых шлюз приложений должен подключаться к серверной части службы приложений.
6. Нажмите кнопку "Добавить", чтобы сохранить эту конфигурацию

$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

Откройте раздел "Работоспособность серверной части" и убедитесь, что в столбце "Состояние" указано, что сочетание настройки HTTP и пула серверов отображается как "Рабочее состояние".

Теперь перейдите к веб-приложению, используя IP-адрес шлюза приложений или связанное с IP-адресом DNS-имя. Оба элемента можно найти на странице "Обзор" шлюза приложений в разделе "Основные сведения". Кроме того, ресурс общедоступного IP-адреса также отображает IP-адрес и связанное DNS-имя.

Обратите внимание на следующий неисчерпаемый список потенциальных симптомов при тестировании приложения:

• перенаправления, указывающие напрямую на ".azurewebsite.net", вместо Application Gateway.
• включает перенаправления проверки подлинности, которые напрямую пытаются получить доступ к ".azurewebsite.net"
• Файлы cookie, привязанные к домену, не передаются в серверную часть
• включить использование параметра ARR affinity в Службе приложений

Приведенные выше условия (более подробно описаны в Центре архитектуры) указывают на то, что веб-приложение плохо справляется с перезаписью имени узла. Это часто видно. Рекомендуемый способ справиться с этим — следовать инструкциям по настройке шлюза приложений с помощью службы приложений с помощью личного домена. См. также: устранение неполадок службы приложений в шлюзе приложений.

Откройте раздел "Работоспособность серверной части" и убедитесь, что в столбце "Состояние" указано, что сочетание настройки HTTP и пула серверов отображается как "Рабочее состояние".

Теперь перейдите к веб-приложению с помощью личного домена, связанного с шлюзом приложений и службой приложений в серверной части.

Проверьте, отображается ли состояние работоспособности серверной части и настроек HTTP как "Рабочее".

$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

Чтобы проверить конфигурацию, мы запрашиваем содержимое из службы приложений через шлюз приложений с помощью личного домена:

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

Проверьте, отображается ли состояние работоспособности серверной части и настроек HTTP как "Рабочее".

$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

Чтобы проверить конфигурацию, мы запрашиваем содержимое из службы приложений через шлюз приложений с помощью 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)"

Обратите внимание на следующий неисчерпаемый список потенциальных симптомов при тестировании приложения:

• перенаправления, указывающие на ".azurewebsites.net" непосредственно вместо шлюза приложений
• Это включает перенаправления аутентификации службы приложений, которые непосредственно пытаются получить доступ к ".azurewebsites.net"
• Файлы cookie, привязанные к домену, не передаются в серверную часть
• Это включает использование параметра "Сходство ARR" в Службе приложений

Приведенные выше условия (более подробно описаны в Центре архитектуры) указывают на то, что веб-приложение плохо справляется с перезаписью имени узла. Это часто видно. Рекомендуемый способ справиться с этим условием — следовать инструкциям по настройке шлюза приложений с помощью службы приложений с помощью личного домена. См. также: устранение неполадок службы приложений в шлюзе приложений.