billgeek
billgeek

Reputation: 76

How do I automatically start a .NET Core 3.1 API when the docker container starts?

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.

debug as docker compose

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

Answers (2)

billgeek
billgeek

Reputation: 76

Running docker-compose up --build from outside Visual Studio will rebuild and run the container as expected.

Upvotes: 1

kvp2982
kvp2982

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

Related Questions