Возможное решение
Может быть решение:
- Создан новый VNET
- Диапазон адресов 10.60.0.0/23
- Создана подсетьКонтейнеры 10.60.0.0/24
- Создан ресурс брандмауэра VNET
- Создан межсетевой экран подсети 10.60.1.0/24
- Назначен статический публичный адрес для ресурса брандмауэра
Теперь «Правила» брандмауэра позволяют:
- Правила NAT - обычная трансляция портов
- Сетевые правила - адреса маршрутов
- Правила приложения - полное доменное имя маршрута
Работа по развертыванию контейнера в этой подсети dev, на первый взгляд, есть все опции, порт перенаправления, ip или FQDN.Изменения в игре - это возможность назначать статический публичный адрес ресурсу в VNET и разрешать NAT, правилам сети или приложениям перенаправлять трафик.
Обновит поток по результатам завтра.
Обновление: февраль 2019
Хорошо, поэтому не используйте ресурс брандмауэра Azure.Это очень дорого и, в моем случае, ни в коем случае не экономически эффективно, около 500 фунтов стерлингов в месяц.У меня не было времени проверить теорию с помощью брандмауэра, но из-за стоимости не было смысла следовать ей дальше.
Экземпляры контейнеров Azure позволяют открывать контейнеры напрямую в Интернет с IP-адресом иполное доменное имя (FQDN).При создании экземпляра контейнера вы можете указать собственную метку DNS-имени, чтобы ваше приложение было доступно по адресу customlabel.azureregion.azurecontainer.io.К сожалению, статические публичные IP-адреса в настоящее время не поддерживаются в ACI.
При развертывании групп контейнеров в виртуальной сети применяются определенные ограничения.
Чтобы развернуть группы контейнеров вподсеть, подсеть не может содержать какие-либо другие типы ресурсов.Удалите все существующие ресурсы из существующей подсети перед развертыванием в ней групп контейнеров или создайте новую подсеть.
Группы контейнеров, развернутые в виртуальной сети, в настоящее время не поддерживают общедоступные IP-адреса или DNSметки имен.
Из-за дополнительных сетевых ресурсов развертывание группы контейнеров в виртуальной сети обычно выполняется несколько медленнее, чем развертывание стандартного экземпляра контейнера.
https://feedback.azure.com/forums/602224-azure-container-instances
Решение развернуто
- Виртуальная машина Ubuntu, созданная с использованием образа Azure
- Статический общедоступный адрес, назначенный виртуальной машине
- Apiи Service развернут в образе докера в шаблоне VM
- Arm, используемом для развертывания, интегрированном со сборкой и выпуском DevOps
- Стоимость в месяц £ 23,52 (ядер: 2, оперативная память 3 ГБ, HD HD 16 ГБ)
Изначально это было решение, но разгрузка и управление сертификатом SSL добавили сложности.
Обновление, март 2019 г. - новое решение Deployed
Если кому-то интересно (не так много, исходя из количества просмотров этой цепочки), было развернуто окончательное решение:
- План обслуживания приложения Provision
- Развернутая служба приложений «API» с использованием экземпляра контейнера для размещения API на порту 443.
- Динамический адрес и стандартный сертификат SSL, развернутые в службе приложений «API».
- Развернутая «служба»Служба приложений, использующая экземпляр контейнера для размещения порта службы 80.
- Статический адрес и сертификат SSL на основе IP, развернутые в службе приложений «Служба».Это приводит к фиксации IP-адреса службы и выполнению условия «мне нужен статический IP-адрес».
- Стоимость хостинга около 65 фунтов стерлингов в месяц.
Стоит отметить, что единственной причиной развертывания сертификата было исправление IP-адреса в службе приложения «Сервис».В настоящее время необходимо решить проблему отсутствия поддержки Azure, чтобы пользователи могли применять статический IP-адрес к экземпляру контейнера.
Благодарим нашу команду разработчиков за нестандартное решение этого вопроса.
Надеюсь, это когда-нибудь кому-нибудь поможет.Скотт
