Не можете протестировать простой веб-API ядра Asp.net, развернутый в докере? - PullRequest
2 голосов
/ 14 марта 2019

Я новичок в докере и очень хочу испытать его возможности. Здесь я хотел бы запустить (разместить) простой веб-API ядра Asp.net в Docker (используя docker run) вместо того, чтобы запускать его с помощью IIS.

Это просто, потому что это точно стандартный базовый веб-API ASP.NET проекта auto-gen с одним контроллером с именем ValuesController. Обычно при отладке с помощью IISExpress следующий URI должен отвечать массиву значений:

http://localhost:[some_port]/api/values

Теперь я добавляю поддержку Docker для проекта (используя контейнер Windows). После сборки докера у меня есть изображение, которое можно перечислить с помощью docker images. Теперь я запускаю докер для размещения моего веб-API следующим образом:

docker run -t -rm -p 80:50633 hellodocker:dev

Он работает нормально, и я могу проверить это, используя docker ps. Однако, чтобы проверить, действительно ли он работает, я попытался ввести следующий адрес в браузере:

http://localhost/api/values

и он не работает, ничего не отображается и выглядит как несуществующий сайт.

Когда я пытаюсь выполнить следующую команду docker exec [container_id] netstat, она иногда показывает запись со статусом TIME_WAIT, и почти всегда ее нет. Хотя я не уверен, относится ли это к внешнему прослушиванию.

вот содержимое файла dockerfile:

FROM microsoft/dotnet:2.2-aspnetcore-runtime-nanoserver-1803 AS base
WORKDIR /app
EXPOSE 50633
EXPOSE 44322

FROM microsoft/dotnet:2.2-sdk-nanoserver-1803 AS build
WORKDIR /src
COPY HelloDocker/HelloDocker.csproj HelloDocker/
RUN dotnet restore HelloDocker/HelloDocker.csproj
COPY . .
WORKDIR /src/HelloDocker
RUN dotnet build HelloDocker.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish HelloDocker.csproj -c Release -o /app

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

Я действительно застрял в этом. Приложение hello-world может просто распечатать простую строку, но этот hellodocker должен быть размещен в докере и обслуживать любые HTTP-запросы так же, как когда мы размещаем его в IIS.

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

UPDATE

После попытки удалить встроенный образ и восстановить вместо него другой. Выглядит иначе после запуска той же командой docker run, указанной выше:

Hosting environment: Production
Content root path: C:\app
Now listening on: http://[::]:80
Application started. Press Ctrl+C to shut down.

Как и прежде ничего не отображается, и путь к корню приглашения становится C:\app. Так что на этот раз выглядит более очевидно, что он слушает запросы Однако это все еще не работает: (

Ответы [ 2 ]

1 голос
/ 15 марта 2019

Перед оператором ENTRYPOINT попробуйте добавить

 ENV ASPNETCORE_URLS=http://+:50633 DOTNET_RUNNING_IN_CONTAINER=true 

, чтобы оно выглядело так:

FROM base AS final WORKDIR /app COPY --from=publish /app . ENV ASPNETCORE_URLS=http://+:50633 DOTNET_RUNNING_IN_CONTAINER=true ENTRYPOINT ["dotnet", "HelloDocker.dll"]

Помогает ли это?

0 голосов
/ 14 марта 2019

Похоже, я должен был опубликовать этот вопрос на форумах докеров, где все эксперты по докерам более заинтересованы (по сравнению с SO в этой области).Не уверен, почему я не смог найти решение на форумах докера, но после попытки поиска Now listening on: http://[::]:80, и это привело меня к очень верхней ссылке на очень похожую проблему на форумах докера здесь https://forums.docker.com/t/unable-to-launch-the-net-core-website-in-docker/48129

Итак, я попробовал одно решение, используя сначала docker inspect [container_id], чтобы найти IP-адрес контейнера, и использовал этот IP-адрес для успешного доступа к веб-API:)

IP-адрес контейнера можно найти в разделе Networks.:

"Networks": {
            "nat": {
                "IPAMConfig": null,
                "Links": null,
                "Aliases": null,
                "NetworkID": "e336becc4500435f7338ebd8f84fef47ec2fc247f77bc82b6dbf49553f68afd5",
                "EndpointID": "a8ede68e3f4bb02392c295901f65d50f0ee014c114f564768d9c82a4644b0218",
                "Gateway": "172.30.240.1",
                "IPAddress": "172.30.242.85",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "00:15:5d:5a:29:8d",
                "DriverOpts": null
            }
        }

Правильный адрес, который я использовал для проверки веб-API сейчас:

http://172.30.242.85/api/values

ОБНОВЛЕНИЕ :

Я предположил EXPOSE 50633 означает, что докер будет выставлять веб-интерфейс через порт 50633, поэтому я запускаю команду docker run -t -p 80:50633 hellodocker:dev.

Но на самом деле порт, который он здесь выставляет, по-прежнему является значением по умолчанию 80 (не знаю почему).Но, по крайней мере, это имеет смысл.Поэтому для сопоставления портов между докером и хост-машиной мы используем команду docker run -t -p:80:80 hellodocker:dev.Я пробовал это, и это прекрасно работает для http://localhost/api/values.

Я думаю, что команда, использованная до docker run -t -p:80:50633 hellodocker:dev, имеет бесполезное сопоставление портов (по крайней мере, для тестирования веб-API с хост-машины), потому что http://172.30.242.85/api/values должно работать, если докер действительно запускает веб-интерфейс для прослушивания порта по умолчанию 80.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...