Доменное имя не разрешается после изменения с WIndows на Linux тарифного плана службы приложений

Question

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

Недавно Microsoft объявила, что региональная интеграция VNet для Linux служб приложений общедоступна. мы попытались перенести все наши службы приложений windows на Linux. К счастью, мы не столкнулись с какими-либо проблемами с su bnet -delegation. Но после миграции службы приложений Linux не могут подключиться к локальной службе. Он говорит UnknownHostException из кода java и пытался из консоли Kudo, там также говорится, что имя домена не разрешается. и мы заметили, что журналы не отправляются в Application Insights.

На следующий день мы просто попробовали использовать IP-адрес вместо доменных имен, это сработало. Для Application Insights мы ничего сделать не смогли. Чтобы просто подтвердить наличие Application Insights, мы отключили vnet -интеграцию для службы приложений, после чего приложение может отправлять журналы в аналитику приложений.

Так в чем же проблема?

Answer 1

Вы не можете создать веб-приложение Linux в плане службы приложений, в котором уже размещены веб-приложения, отличные от Linux. Я полагаю, вы создали новый план обслуживания приложений и службу приложений для Linux для управления региональным VNet Интеграция .

Ваше приложение не может разрешать адреса в Azure Частные зоны DNS без изменений конфигурации

Функция полностью поддерживается как для Windows, так и для Linux веб-приложений. Все поведения действуют одинаково между Windows приложениями и Linux приложениями.

Кроме того, из https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances

В сценарии имени разрешение веб-приложений службы приложений в одной виртуальной сети на виртуальные машины в другой виртуальной сети, для этого требуется управляемые клиентом DNS-серверы, перенаправляющие запросы между виртуальными сетями для разрешения Azure (DNS-прокси) . См. Разрешение имен с использованием вашего собственного DNS-сервера.

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

Для Application Insights вы можете проверить, есть ли у вас правило, блокирующее исходящий вызов к анализу приложений, если вы установили для приложения WEBSITE_VNET_ROUTE_ALL значение 1. Обратитесь к this .

Если вы интегрируете свое приложение с VNet, поведение по умолчанию останется таким, как было. Вы сможете получить доступ только к адресам RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) и конечным точкам службы. Как и в случае с Windows, эта функция теперь поддерживает исходящие вызовы на VNet на адресах, не относящихся к RFC1918. Чтобы получить доступ ко всем адресам, вам необходимо установить для параметра приложения WEBSITE_VNET_ROUTE_ALL значение 1, после этого ваше приложение будет разрешать всему исходящему трафику c из вашего приложения подчиняться NSG и UDR.