A Dockerfile tells Docker how to build a container image. It is a text file named `Dockerfile`, usually placed in the project directory, containing comments and instructions. Each instruction has the form `INSTRUCTION arguments`. The file begins with `FROM`, which selects an existing base image; subsequent instructions modify that base to produce a new image. section 13.3.1
For .NET 6 and earlier, a Dockerfile is needed to build the application image. .NET 7 and later can publish a basic container image directly, but customizations still require a Dockerfile. Docker Desktop and a working `docker` command are needed to follow the build workflow. section 13.3 section 13.3.1
Listing 13.2 Dockerfile for AsciiArtSvc
# Use the official .NET 6 container FROM mcr.microsoft.com/dotnet/sdk:6.0 # Copy files from the current folder on your machine to # the /src folder in the container COPY . /src # Set working directory in the container WORKDIR /src # Expose HTTP port from "docker" launch profile EXPOSE 5101 # Run the application when the container is started ENTRYPOINT ["dotnet", "run", "--launch-profile", "docker"]
A minimal service image starts from the .NET 6 SDK image, copies the project into `/src`, sets that working directory, exposes the service port, and starts the application with `dotnet run`. section 13.3.1
`COPY . /src` includes the current folder unless files are excluded. Put local build artifacts such as `/bin/` and `/obj/` in `.dockerignore` so they do not enter the image. Build from the project folder with `docker build --tag asciiartsvc .`; the first build retrieves the base image, while later builds can use cached images. section 13.3.1
Listing 13.7 Dockerfile with named stages
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-stage #1 WORKDIR /src #2 COPY AsciiArtSvc.csproj . #3 RUN dotnet restore #4 COPY . . #5 RUN dotnet publish -o /publish FROM mcr.microsoft.com/dotnet/aspnet:6.0 WORKDIR /publish COPY --from=build-stage /publish . #6 EXPOSE 80 ENTRYPOINT ["dotnet", "AsciiArtSvc.dll"]
A multi-stage alternative publishes the application in an SDK build stage, then copies the published output into an ASP.NET runtime image. Named stages make the copy source explicit; this example copies the project file and restores dependencies before copying the remaining files. section 13.3.1
Containerizing a web service also requires a suitable listening address. A launch profile that binds only to `localhost` does not work the same way inside a container; the shown service profile listens on `http://*:5101` instead. Its port matches the minimal Dockerfile’s `EXPOSE 5101` instruction. section 13.3 section 13.3.1
