Я создал веб-API Azure Service Fabric и планировал получить доступ к нему через встроенный в Service Fabric обратный прокси-сервер.
Все работало хорошо локально, но когда я опубликовал в Azure, попытка доступа к маршруту через обратный прокси-сервер истекла по тайм-ауту.
Я подумал, что это может быть мое приложение, поэтому я просто открыл новое решение с шаблоном по умолчанию и опубликовал его на моем локальном компьютере. Все работало нормально Обратный прокси и все такое. Поэтому я опубликовал в Azure и снова столкнулся с той же проблемой.
Я мог бы получить доступ к веб-API на Azure по обычному маршруту (через конечную точку службы), например:
xxxx.east.cloudapp.azure:8080/api/values
Но при переходе через порт обратного прокси 19081 время ожидания истекло:
xxxx.east.cloudapp.azure:19081/[app]/[service]/api/values
Я обязательно поставил галочку «Включить обратный прокси» при настройке ресурса кластера в Azure и установил порт 19081. Оба вышеуказанных варианта отлично работают на локальном хосте, но в Azure работает только обычный маршрут.
Мне было интересно, есть ли дополнительное редактирование манифеста или что-то, что мне нужно было сделать, чтобы он правильно работал в Azure?
Вы видели документация о том, как его настроить?
Если вы собираетесь предоставлять услуги в Интернете, имейте в виду, что встроенная служба делает доступной каждую службу, она не защищена и уязвима для DOS-атак. Документы
Я рекомендую взглянуть на Traefik в качестве обратного прокси-сервера и балансировщика нагрузки. Вы можете запустить его как (контейнерную) службу маршрутизации входящего трафика внутри кластера и направлять вызовы HTTP к своим службам.
В качестве альтернативы вы можете использовать API-шлюз, который также интегрируется с SF. Или даже Nginx.