Перенаправление https-трафика в Azure Container App на другой порт

Вопрос или проблема

У меня есть приложение Container, которое работает с IdentityServer4. Оно больше не поддерживается, и в нем есть известная ошибка, когда при входе по порту 80 происходит бесконечная перенаправление обратно на страницу входа, даже если вход успешен.

FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS base
WORKDIR /app
#EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:3.1 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["IdentityServer/IdentityServer.csproj", "IdentityServer/"]
RUN dotnet restore "./IdentityServer/IdentityServer.csproj"
COPY . .
WORKDIR "/src/IdentityServer"
RUN dotnet build "./IdentityServer.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./IdentityServer.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "IdentityServer.dll"]

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

конфигурация

У меня выбрано только https, но это не позволяет мне настроить порт или протокол для внутренней перенаправления. По крайней мере, насколько я могу сказать.

Ответ или решение

Чтобы решить проблему с перенаправлением трафика HTTPS на другой порт в Azure Container App, нам нужно рассмотреть несколько аспектов. Прежде всего, давайте разберемся с теоретической частью.

Теория

Azure Container Apps — это управляемая платформа для развертывания контейнеризированных приложений. Обычно они поддерживают работу на стандартных портах (80 для HTTP и 443 для HTTPS), так как эти порты общеприняты для веб-трафика. В контексте службы контейнеров, это подразумевает, что ваше приложение должно быть готово принимать трафик HTTPS на порт 443.

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

Пример

Возьмем пример контейнеризированного приложения, развернутого с использованием ASP.NET Core, в котором вы уже отключили экспонирование порта 80:

FROM mcr.microsoft.com/dotnet/aspnet:3.1 AS base
WORKDIR /app
#EXPOSE 80
EXPOSE 443

Ваш Dockerfile настроен так, что приложения внутри контейнера слушают только на порту 443. Это правильный шаг, если вы предполагаете, что трафик должен приходить исключительно по HTTPS.

Проблема возникает, когда Azure Container Apps пытается "узнать", какой порт использовать для входящего трафика. Если он настроен слушать на порт 80, а внутри контейнера этот порт не слушает, это может привести к тайм-аутам и проблемам с доступом к вашему приложению.

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

Применение

Для решения вашей проблемы, рекомендуется выполнить следующие шаги:

Настройка HTTPS только на уровне платформы: Убедитесь, что на уровне Azure у вас включен доступ только по HTTPS. Если вы используете Azure Application Gateway или Azure Front Door, убедитесь, что они настроены пропускать только HTTPS-трафик.
Использование Application Gateway для перенаправления: Можете настроить Azure Application Gateway для перенаправления трафика с порта 80 на порт 443. Это позволит вам использовать стандартное перенаправление HTTP на HTTPS.
Настройка файла конфигурации: Проверьте файл конфигурации вашего приложения, чтобы оно было способно правильно обрабатывать все схемы и порты. В файле appsettings.json проверьте секцию, отвечающую за конфигурацию Kestrel и перенаправьте все HTTP-запросы на HTTPS.
Обновление контейнера/образа приложения: Убедитесь, что приложение внутри контейнера правильно сконфигурировано для работы исключительно с HTTPS. Например, в настройках .NET перенаправьте все HTTP-запросы на HTTPS:
```
public class Startup
{
   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
       app.UseHttpsRedirection();
       ...
   }
}
```
Проверка маршрутизации в Azure: Если используется Azure Kubernetes Service (AKS) или другой контейнерный подход с услугами, убедитесь, что ваша служба правильно настроена для маршрутизации трафика.

Если проблема с бесконечным редиректом на ваш взгляд связана с конкретным багом IdentityServer4, возможно, стоит рассмотреть альтернативные решения, например, обновление до более актуальной библиотеки или замена IdentityServer на другую платформу, поддерживающую OpenID Connect или OAuth2.0.

Внимательно проверьте всю цепь маршрутизации и настройки SSL/TLS, так как ошибка может быть связана с несовпадением ожиданий между тем, как настроен ваш контейнер и как настроено ваше облачное окружение. Зачастую корректировка мелких параметров на одном из уровней может решить весь комплекс проблем с переправлением трафика.