У меня есть существующая виртуальная сеть (VN), настроенная в Azure. На нем есть ВМ. Виртуальная сеть представляет собой базовую сеть, использующую Azure DNS, и была создана с настройками по умолчанию (если не используется память).
Мне удалось настроить облачную службу и добавить ее в виртуальную сеть через файл Cloud.cscfg, например добавляя:
<NetworkConfiguration>
<VirtualNetworkSite name="Group Group-n xxxxxx" />
<AddressAssignments>
<InstanceAddress roleName="yyyyy.API">
<Subnets>
<Subnet name="Subnet-42" />
</Subnets>
</InstanceAddress>
<InstanceAddress roleName="yyyyy.WorkerRole">
<Subnets>
<Subnet name="Subnet-42" />
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>
где имена были изменены, чтобы защитить невиновных. Обратите внимание, что имя региона и группа связи не были указаны - я не уверен, что это актуально.
Я внес аналогичные изменения в файлы cscfg, которые мы загружаем после развертывания, и смог обновить конфигурацию, не вызывая проблем.
Настройка сработала (для определенных определений работы), а веб-роли и рабочие роли в нашей облачной службе могли отправлять сообщения по tcp на нашу виртуальную машину на том же виртуальном сетевом узле при использовании адресации IP-адресов (это также иногда срабатывало при использовании полного доменного имени vm, но это еще одна проблема, которая может вызвать другой вопрос).
Этот облачный сервис был стеком разработчиков. Чтобы проверить, работает ли наш процесс развертывания, я повторно развернул эту облачную службу без конфигурации сети и подтвердил, что роли больше не указаны в подсети виртуальной сети.
Затем я попытался добавить в виртуальную сеть другую облачную службу в том же регионе, используя ту же конфигурацию.
Это не удалось при развертывании с сообщением «Развертывание не может использовать VNNAME, принадлежащее лазурному региону».
Я немного поискал и не нашел, что помогает, например https://social.msdn.microsoft.com/Forums/en-US/68623f13-5acb-4cba-bb69-6c924e2786ef/the-deployment-cannot-use-the-virtualnetwork-that-belongs-to-a-region? forum = WAVirtualMachinesVirtualNetwork
описывает похожую проблему, по которой не было особо много полезных советов.
Итак, возникает вопрос: какие правильные шаги следует предпринять при добавлении и удалении облачной службы Azure в существующую виртуальную сеть, и знает ли кто-нибудь о проблемах с Azure, связанных с конфигурацией виртуальной сети, которые могут вызывать указанное выше поведение?
Спасибо
PS Вспомнил некоторую информацию, которая может быть актуальной. Когда исходная облачная служба была добавлена в виртуальную сеть, она находилась в промежуточном слоте облачной службы, в которой ничего не было развернуто в производственном слоте. Во втором случае служба развертывалась в промежуточном слоте службы, в которой был занят производственный слот с запущенными веб-ролями и рабочими ролями.
Этот вопрос настолько старый, что я забываю многие детали. Тем не менее, кто-то в нашем офисе это выяснил. Они не сталкивались с той же проблемой. Я хотел бы думать, что это произошло из-за того, что Azure был сломан, и теперь они его исправили, но, вероятно, это неправильно.
Возможно, это неправильное решение моей конкретной проблемы, но оно, по крайней мере, служит для нас подходящим решением, и я подумал, что поделюсь им.
При работе с заранее заданной виртуальной сетью и при попытке создать новый объект (например, виртуальную машину) на портале Azure мой коллега заметил, что помимо того, что его попросили предоставить регион для нового объекта, он мог вместо этого предоставить имя виртуальной сети. Он так и сделал. У него не было ни одной из замеченных мной проблем.