Сетевое взаимодействие в среде службы приложений

Среда службы приложений — это развертывание Службы приложений Azure для одного клиента, в котором размещаются контейнеры Windows и Linux, веб-приложения, приложения API, приложениям логики, а также приложения-функции. При установке Среды службы приложений необходимо выбрать виртуальную сеть Azure, в которую необходимо развернуть службу. Весь входящий и исходящий трафик приложения находится в указанной вами виртуальной сети. Развертывание выполняется в одну подсеть в виртуальной сети, и в нее невозможно развернуть что-либо еще.

Требования к подсети

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

• Подсеть должна быть делегирована к Microsoft.Web/hostingEnvironments.
• Подсеть должна быть пуста.
• Свойство подсети addressPrefix должно быть отформатировано как строка, а не массив.

Размер подсети может влиять на пределы масштабирования экземпляров плана службы приложений в Среде службы приложений. Для производственного масштаба мы рекомендуем использовать адресное /24 пространство (256 адресов) для вашей подсети. Если вы планируете масштабировать почти максимальную емкость до 200 экземпляров в нашей среде службы приложений и планируете частые операции увеличения и уменьшения масштаба, рекомендуется адресное /23 пространство (512 адресов) для подсети.

Если вы используете меньшую подсеть, помните о следующих ограничениях:

• В любой конкретной подсети имеется пять адресов, зарезервированных для целей управления. Помимо адресов управления, Среда службы приложений динамически масштабирует поддержку инфраструктуры и использует от 7 до 27 адресов в зависимости от конфигурации и загрузки. Оставшиеся адреса можно использовать для экземпляров в рамках плана службы App Service. Минимальный размер подсети — диапазон адресов /27 (32 адреса).
• Для любой комбинации ОС/SKU плана службы приложений, используемой в среде службы приложений, например, i1v2 Windows, создается один резервный экземпляр для каждых 20 активных экземпляров. Резервные экземпляры также требуют IP-адресов.
• При масштабировании планов службы приложений в среде службы приложений, вверх/вниз, количество IP-адресов, используемых планами службы приложений, временно удваивается, пока операция масштабирования не завершится. Перед выведением существующих экземпляров новые экземпляры должны полностью функционировать.
• Обновления платформы нуждаются в бесплатных IP-адресах, чтобы гарантировать, что обновления могут произойти без прерываний исходящего трафика.
• После увеличения масштаба, уменьшения или завершения операций может потребоваться некоторое время до освобождения IP-адресов. В редких случаях эта операция может составлять до 12 часов.
• Если в вашей подсети закончились адреса, вы можете столкнуться с ограничениями на масштабирование планов службы приложений в Среде службы приложений. Другая возможность заключается в том, что при интенсивной нагрузке трафика может возникнуть увеличенная задержка, если корпорация Майкрософт не сможет масштабировать поддерживающую инфраструктуру.

Адреса

На этапе создания к Среде службы приложений относятся следующие сведения о сети.

Сведения можно найти в разделе IP-адреса на портале, как показано на следующем снимке экрана:

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

Принести собственный входящий адрес

Вы можете использовать собственный входящий адрес в Среда службы приложений. При создании среды приложений с виртуальным внутренним IP-адресом вы можете указать статический IP-адрес в подсети. При создании Среды службы приложений (Среда службы приложений) с внешним виртуальным IP-адресом вы можете использовать собственный публичный IP-адрес Azure, указав идентификатор ресурса этого IP-адреса. Ниже приведены ограничения для привлечения собственного входящего адреса:

• Для Среды службы приложений с внешним VIP ресурс общедоступного IP-адреса Azure должен находиться в той же подписке, что и Среда службы приложений.
• Нельзя изменить входящий адрес после создания окружения службы приложений.

Ограничение входящего трафика для среды службы приложений ILB

Для сред службы приложений с внутренним виртуальным IP-адресом входящий трафик к фронтэндам может быть отброшен, если исходный IP-адрес попадает в диапазон адресов инфраструктуры, используемый для фронтэндов среды службы приложений. Не используйте исходные IP-адреса в адресном 172.31.192.0/25 пространстве при подключении к среде службы приложений ILB.

Ограничения портов и сети

Чтобы ваше приложение могло получать трафик, убедитесь, что правила группы безопасности сети (NSG) для входящего трафика разрешают подсети Среды службы приложений получать трафик с необходимых портов. Помимо портов, на которые вы хотите получать трафик, необходимо убедиться, что Azure Load Balancer может подключиться к подсети через порт 80. Этот порт используется для проверки работоспособности внутренней виртуальной машины. Вы по-прежнему можете контролировать трафик порта 80 из виртуальной сети в свою подсеть.

Рекомендуем настроить следующее правило NSG для входящего трафика:

Минимальные требования к работе Среды службы приложений:

При использовании минимально необходимого правила может потребоваться одно или несколько правил для трафика приложения. Если вы используете любой из вариантов развертывания или отладки, необходимо также разрешить этот трафик в подсеть Среды службы приложений. Источником этих правил может быть виртуальная сеть, а также один или несколько конкретных IP-адресов или диапазонов IP-адресов. Назначение всегда является диапазоном подсети Среды службы приложений.

Внутренний трафик проверки состояния на порту 80 изолирован между балансировщиком нагрузки и внутренними серверами. Внешний трафик не может получить доступ к конечной точке для проверки работоспособности.

Стандартные входящие порты доступа для приложения:

Сетевая маршрутизация

Можно задать таблицы маршрутизации без ограничения. Вы можете туннелировать весь исходящий трафик приложения из среды App Service на устройство брандмауэра, такое как Брандмауэр Azure. В этом сценарии единственное, о чем следует беспокоиться, — это зависимости приложения.

Зависимости приложений включают конечные точки, необходимые приложению во время выполнения. Помимо API и служб, которые вызывает приложение, зависимости также могут быть конечными точками, такими как конечные точки проверки списков отзыва сертификатов (CRL) и точки идентификации и аутентификации, например служба Microsoft Entra ID. Если вы используете непрерывное развертывание в Службе приложений, вам, возможно, также придется разрешить конечные точки в зависимости от типа и языка. В частности, для непрерывного развертывания Linux необходимо разрешить oryx-cdn.microsoft.io:443.

Вы можете разместить устройства брандмауэра веб-приложения, например Шлюз приложений Azure, перед входящим трафиком. Это позволяет вам сделать доступными определенные приложения в этой Среде службы приложений.

Приложение использует один из исходящих адресов по умолчанию для исходящего трафика в общедоступные конечные точки. Если вы хотите настроить исходящий адрес приложений в Среде службы приложений, можете добавить шлюз преобразования сетевых адресов (NAT) в свою подсеть.

Сегментация исходящей сети

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

Включение сегментации исходящей сети

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

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

"clusterSettings": [
    {
        "name": "MultipleSubnetJoinEnabled",
        "value": "true"
    }
]

Инструкции по настройке параметров кластера см. в разделе "Пользовательские параметры конфигурации" для сред службы приложений.

Необходимо также задать allowNewDirectNetworkIntegrations свойство true в сетевой конфигурации служебной среды приложения. Это свойство является обязательной составной частью конфигурации сети. Если вы обновляете сетевую конфигурацию без включения этого свойства, ее можно отключить, так как она по умолчанию false.

Это свойство можно задать с помощью интерфейса командной строки или непосредственно в шаблоне ARM.

az rest --method put \
  --uri "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/hostingEnvironments/{aseName}/configurations/networking?api-version=2024-04-01" \
  --body '{
    "properties": {
      "allowNewDirectNetworkIntegrations": true
    }
  }'

{
  "type": "Microsoft.Web/hostingEnvironments/configurations",
  "apiVersion": "2024-04-01",
  "name": "[concat(parameters('aseName'), '/networking')]",
  "properties": {
    "allowNewDirectNetworkIntegrations": true
  }
}

Присоединение приложения к альтернативной подсети

Альтернативная подсеть должна быть пуста и делегирована Microsoft.Web/serverFarms. Убедитесь, что для приложения включена маршрутизация трафика приложений для маршрутизации всего трафика через альтернативную подсеть.

Чтобы присоединить приложение к альтернативной подсети, используйте следующую команду Azure CLI:

az webapp vnet-integration add --resource-group <APP-RESOURCE-GROUP> --name <APP-NAME> --vnet <VNET-NAME> --subnet <ALTERNATE-SUBNET-NAME>

Если альтернативная подсеть находится в другой группе ресурсов, отличной от приложения, запустите az webapp vnet-integration add -h , чтобы узнать, как указать идентификатор ресурса.

Чтобы изменить альтернативную подсеть для приложения, сначала удалите существующую интеграцию и добавьте новую.

Чтобы удалить альтернативное присоединение подсети для приложения, удалите интеграцию виртуальной сети с помощью Azure CLI или ARM/Bicep:

az webapp vnet-integration remove --resource-group <APP-RESOURCE-GROUP> --name <APP-NAME>

Ограничения

• Приложение, среда службы приложений и виртуальная сеть должны находиться в одной подписке.
• Каждое приложение из заданного плана может интегрироваться только с одной альтернативной подсетью.
• План может иметь до четырех разных подключений подсети, а приложения в одном плане могут использовать любой из подключений.
• Эта функция несовместима с функцией соединения подсети с несколькими планами , доступной в предложении мультитенантной службы приложений.

Частная конечная точка

Чтобы включить частные конечные точки для приложений, размещенных в Среде службы приложений, необходимо сначала включить эту функцию на уровне Среды службы приложений.

Его можно активировать с помощью портал Azure. В области конфигурации Среды службы приложений включите настройку Allow new private endpoints. В качестве альтернативы можно включить следующий интерфейс командной строки:

az appservice ase update --name myasename --allow-new-private-endpoint-connections true

Дополнительные сведения о Частной конечной точке и веб-приложении см. на странице Частная конечная точка для веб-приложения Azure.

DNS

В следующих разделах описываются рекомендации по использованию и настройке DNS для входящего и исходящего трафика из Среды службы приложений. В примерах используется суффикс appserviceenvironment.net домена из общедоступного облака Azure. Если вы используете другие облака, такие как Azure для государственных организаций, необходимо использовать соответствующий суффикс домена. Для доменов Среда службы приложений имя сайта усечено на 59 символов из-за ограничений DNS. Для доменов Среда службы приложений с слотами имя сайта усечено на 40 символов, а имя слота усечено на 19 символов из-за ограничений DNS.

Настройка DNS в среде платформы служб приложений

Если ваша среда службы приложений создана с внешним виртуальным IP-адресом, ваши приложения автоматически помещаются в общедоступный DNS. Если ваша Среда службы приложений создана с использованием внутреннего VIP-адреса, при создании Среды службы приложений у вас есть два варианта. Если вы выбираете, что частные зоны Azure DNS настроены автоматически, DNS настраивается в виртуальной сети. Если вы решили настроить DNS вручную, необходимо либо использовать собственный DNS-сервер, либо настроить частные зоны Azure DNS. Чтобы найти входящий адрес, перейдите на портал Среды службы приложений и выберите IP-адреса.

Если нужно использовать собственный DNS-сервер, необходимо добавить следующие записи:

1. Создайте зону для <Среда службы приложений-name>.appserviceenvironment.net.
2. Создайте в этой зоне запись A, которая указывает * на исходящий IP-адрес, используемый вашей средой App Service.
3. Создайте в этой зоне запись A, которая указывает @ на входящий IP-адрес, используемый вашей ASE.
4. Создайте в <Среда службы приложений-name>.appserviceenvironment.net зону с именем scm.
5. Создайте в зоне scm запись A, которая указывает * на IP-адрес, используемый частной конечной точкой вашей Среды службы приложений.

Чтобы настроить DNS в частных зонах Azure DNS, выполните следующие действия:

1. Создайте частную зону Azure DNS с именем <Среда службы приложений-name>.appserviceenvironment.net.
2. Создайте в этой зоне запись A, которая указывает * на входящий IP-адрес.
3. Создайте в этой зоне запись A, которая указывает @ на входящий IP-адрес.
4. Создайте в этой зоне запись A, которая указывает *.scm на входящий IP-адрес.

Кроме домена по умолчанию, предоставляемого при создании приложения, можно также добавить в приложение личный домен. Можно задать имя личного домена без проверки в ваших приложениях. Если вы используете личные домены, необходимо убедиться, что для них настроены записи DNS. Вы можете следовать указанным выше инструкциям, чтобы настроить зоны и записи DNS для пользовательского доменного имени (замените доменное имя по умолчанию на пользовательское доменное имя). Имя личного домена подходит для запросов приложений, но не подходит для сайта scm. Сайт scm доступен только по адресу <appname>.scm.<asename>.appserviceenvironment.net.

Конфигурация DNS для FTP-доступа

В частности, для FTP-доступа к среде Службы приложений с внутренней подсистемой балансировки нагрузки (ILB) версии 3 необходимо убедиться, что DNS настроен. Настройте частную зону Azure DNS или эквивалентную пользовательскую службу DNS со следующими параметрами.

1. Создайте частную зону Azure DNS с именем ftp.appserviceenvironment.net.
2. Создайте в этой зоне запись A, которая указывает <Среда службы приложений-name> на входящий IP-адрес.

Помимо настройки DNS, его также необходимо включить в среде службы приложений. Настройте параметры сети и на уровне приложения.

Настройка DNS из Среды службы приложений

Приложения в вашей среде службы приложений используют DNS, с которым настроена ваша виртуальная сеть. Если требуется, чтобы некоторые приложения использовали другой DNS-сервер, можно вручную задать его для каждого приложения с помощью параметров приложения WEBSITE_DNS_SERVER и WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER настраивает дополнительный DNS-сервер. Вторичный DNS-сервер используется только при отсутствии ответа от основного DNS-сервера.

Дополнительные ресурсы

• Справка по переменным среды и параметрам приложений