Reputation: 76
When I deploy my .NET Core WebAPI to a Docker container, it fails to "run" by default. (It's dotnet that doesn't run, the actual container runs as expected)
Running docker ps -a
shows the container with a Status of "UP":
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
eb3fa8be5101 firstapi:dev "tail -f /dev/null" 4 minutes ago Up 4 minutes 0.0.0.0:32790->80/tcp MyFirstApi
Attempting to hit "http://localhost:32790/api/WeatherForecast" shows an error in the browser (ERR_EMPTY_RESPONSE) and "Error: socket hang up" in Postman.
When I debug this project in Visual Studio (the debugging project is set to "Docker Compose") I can successfully hit the API.
As soon as I stop debugging, I can't reach the endpoints again.
When I shell into the container and manually launch the API, it works from my browser again:
PS C:\WINDOWS\system32> docker exec -it eb3 /bin/bash
root@eb3fa8be5101:/app# cd /app/bin/Debug/netcoreapp3.1/
root@eb3fa8be5101:/app/bin/Debug/netcoreapp3.1# dotnet FirstApi.dll
[18:43:16 INF] Starting up
[18:43:16 INF] Now listening on: http://[::]:80
[18:43:16 INF] Application started. Press Ctrl+C to shut down.
[18:43:16 INF] Hosting environment: Development
[18:43:16 INF] Content root path: /app/bin/Debug/netcoreapp3.1
My dockerfile looks pretty standard, untouched from when VS generated it:
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["/FirstApi.csproj", "FirstApi/"]
RUN dotnet restore "FirstApi/FirstApi.csproj"
COPY . .
WORKDIR "/src/FirstApi"
RUN dotnet build "FirstApi.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "FirstApi.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "FirstApi.dll"]
And my launchSettings.json file is also pretty standard:
{
"$schema": "http://json.schemastore.org/launchsettings.json",
"profiles": {
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
"publishAllPorts": true,
"useSSL": false
}
}
}
The docker-compose.yml file:
version: '3.4'
services:
firstapi:
image: ${DOCKER_REGISTRY-}firstapi
build:
context: .
dockerfile: FirstApi/Dockerfile
And the docker-compose.override.yml:
version: '3.4'
services:
firstapi:
environment:
- ASPNETCORE_ENVIRONMENT=Development
ports:
- "80"
volumes:
- ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
Upvotes: 0
Views: 1356
Reputation: 76
Running docker-compose up --build
from outside Visual Studio will rebuild and run the container as expected.
Upvotes: 1
Reputation: 151
It is possible that port 80 is causing the issue. Port 80 is taken by IIS and could cause issues when you run a container. Map it to some other port.
firstapi:
environment:
- ASPNETCORE_ENVIRONMENT=Development
ports:
- **"8000:80"**
volumes:
- ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
Upvotes: 0