This information relates to a pre-release product that may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
For this tutorial, you download an ASP.NET Core sample app and run it in Docker containers. The sample works with both Linux and Windows containers.
The sample Dockerfile uses the Docker multi-stage build feature to build and run in different containers. The build and run containers are created from images that are provided in Docker Hub by Microsoft:
dotnet/sdk
The sample uses this image for building the app. The image contains the .NET SDK, which includes the Command Line Tools (CLI). The image is optimized for local development, debugging, and unit testing. The tools installed for development and compilation make the image relatively large.
dotnet/aspnet
The sample uses this image for running the app. The image contains the ASP.NET Core runtime and libraries and is optimized for running apps in production. Designed for speed of deployment and app startup, the image is relatively small, so network performance from Docker Registry to Docker host is optimized. Only the binaries and content needed to run an app are copied to the container. The contents are ready to run, enabling the fastest time from docker run to app startup. Dynamic code compilation isn't needed in the Docker model.
Look for the Dockerfile in the current folder (the period at the end).
The run command arguments:
Allocate a pseudo-TTY and keep it open even if not attached. (Same effect as --interactive --tty.)
Automatically remove the container when it exits.
Map <port> on the local machine to port 8080 in the container.
Name the container aspnetcore_sample.
Specify the aspnetapp image.
Go to http://localhost:<port> in a browser to test the app.
Build and deploy manually
In some scenarios, you might want to deploy an app to a container by copying its assets that are needed at run time. This section shows how to deploy manually.
Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.
Build the app in release mode (the default is debug mode).
Create the assets in the published folder.
Run the app.
Windows:
dotnet published\aspnetapp.dll
Linux:
dotnet published/aspnetapp.dll
Browse to http://localhost:<port> to see the home page.
To use the manually published app within a Docker container, create a new Dockerfile and use the docker build . command to build an image.
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
To see the new image use the docker images command.
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /source
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
In the preceding Dockerfile, the *.csproj files are copied and restored as distinct layers. When the docker build command builds an image, it uses a built-in cache. If the *.csproj files haven't changed since the docker build command last ran, the dotnet restore command doesn't need to run again. Instead, the built-in cache for the corresponding dotnet restore layer is reused. For more information, see Best practices for writing Dockerfiles.
The Git repository that contains the sample app also includes documentation. For an overview of the resources available in the repository, see the README file. In particular, learn how to implement HTTPS:
For this tutorial, you download an ASP.NET Core sample app and run it in Docker containers. The sample works with both Linux and Windows containers.
The sample Dockerfile uses the Docker multi-stage build feature to build and run in different containers. The build and run containers are created from images that are provided in Docker Hub by Microsoft:
dotnet/sdk
The sample uses this image for building the app. The image contains the .NET SDK, which includes the Command Line Tools (CLI). The image is optimized for local development, debugging, and unit testing. The tools installed for development and compilation make the image relatively large.
dotnet/aspnet
The sample uses this image for running the app. The image contains the ASP.NET Core runtime and libraries and is optimized for running apps in production. Designed for speed of deployment and app startup, the image is relatively small, so network performance from Docker Registry to Docker host is optimized. Only the binaries and content needed to run an app are copied to the container. The contents are ready to run, enabling the fastest time from docker run to app startup. Dynamic code compilation isn't needed in the Docker model.
Look for the Dockerfile in the current folder (the period at the end).
The run command arguments:
Allocate a pseudo-TTY and keep it open even if not attached. (Same effect as --interactive --tty.)
Automatically remove the container when it exits.
Map port 5000 on the local machine to port 80 in the container.
Name the container aspnetcore_sample.
Specify the aspnetapp image.
Go to http://localhost:5000 in a browser to test the app.
Build and deploy manually
In some scenarios, you might want to deploy an app to a container by copying its assets that are needed at run time. This section shows how to deploy manually.
Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.
Build the app in release mode (the default is debug mode).
Create the assets in the published folder.
Run the app.
Windows:
dotnet published\aspnetapp.dll
Linux:
dotnet published/aspnetapp.dll
Browse to http://localhost:5000 to see the home page.
To use the manually published app within a Docker container, create a new Dockerfile and use the docker build . command to build an image.
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
To see the new image use the docker images command.
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /source
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:7.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
In the preceding Dockerfile, the *.csproj files are copied and restored as distinct layers. When the docker build command builds an image, it uses a built-in cache. If the *.csproj files haven't changed since the docker build command last ran, the dotnet restore command doesn't need to run again. Instead, the built-in cache for the corresponding dotnet restore layer is reused. For more information, see Best practices for writing Dockerfiles.
The Git repository that contains the sample app also includes documentation. For an overview of the resources available in the repository, see the README file. In particular, learn how to implement HTTPS:
For this tutorial, you download an ASP.NET Core sample app and run it in Docker containers. The sample works with both Linux and Windows containers.
The sample Dockerfile uses the Docker multi-stage build feature to build and run in different containers. The build and run containers are created from images that are provided in Docker Hub by Microsoft:
dotnet/sdk
The sample uses this image for building the app. The image contains the .NET SDK, which includes the Command Line Tools (CLI). The image is optimized for local development, debugging, and unit testing. The tools installed for development and compilation make the image relatively large.
dotnet/core/sdk
The sample uses this image for building the app. The image contains the .NET Core SDK, which includes the Command Line Tools (CLI). The image is optimized for local development, debugging, and unit testing. The tools installed for development and compilation make the image relatively large.
dotnet/aspnet
The sample uses this image for running the app. The image contains the ASP.NET Core runtime and libraries and is optimized for running apps in production. Designed for speed of deployment and app startup, the image is relatively small, so network performance from Docker Registry to Docker host is optimized. Only the binaries and content needed to run an app are copied to the container. The contents are ready to run, enabling the fastest time from docker run to app startup. Dynamic code compilation isn't needed in the Docker model.
dotnet/core/aspnet
The sample uses this image for running the app. The image contains the ASP.NET Core runtime and libraries and is optimized for running apps in production. Designed for speed of deployment and app startup, the image is relatively small, so network performance from Docker Registry to Docker host is optimized. Only the binaries and content needed to run an app are copied to the container. The contents are ready to run, enabling the fastest time from docker run to app startup. Dynamic code compilation isn't needed in the Docker model.
Look for the Dockerfile in the current folder (the period at the end).
The run command arguments:
Allocate a pseudo-TTY and keep it open even if not attached. (Same effect as --interactive --tty.)
Automatically remove the container when it exits.
Map port 5000 on the local machine to port 80 in the container.
Name the container aspnetcore_sample.
Specify the aspnetapp image.
Go to http://localhost:5000 in a browser to test the app.
Build and deploy manually
In some scenarios, you might want to deploy an app to a container by copying its assets that are needed at run time. This section shows how to deploy manually.
Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.
Build the app in release mode (the default is debug mode).
Create the assets in the published folder.
Run the app.
Windows:
dotnet published\aspnetapp.dll
Linux:
dotnet published/aspnetapp.dll
Browse to http://localhost:5000 to see the home page.
To use the manually published app within a Docker container, create a new Dockerfile and use the docker build . command to build an image.
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
To see the new image use the docker images command.
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /source
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
To see the new image use the docker images command.
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /source
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app --no-restore
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
In the preceding Dockerfile, the *.csproj files are copied and restored as distinct layers. When the docker build command builds an image, it uses a built-in cache. If the *.csproj files haven't changed since the docker build command last ran, the dotnet restore command doesn't need to run again. Instead, the built-in cache for the corresponding dotnet restore layer is reused. For more information, see Best practices for writing Dockerfiles.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /app
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /app/aspnetapp
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY --from=build /app/aspnetapp/out ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
As noted in the preceding Dockerfile, the *.csproj files are copied and restored as distinct layers. When the docker build command builds an image, it uses a built-in cache. If the *.csproj files haven't changed since the docker build command last ran, the dotnet restore command doesn't need to run again. Instead, the built-in cache for the corresponding dotnet restore layer is reused. For more information, see Best practices for writing Dockerfiles.
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY published/ ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
The Dockerfile
Here's the Dockerfile used by the docker build command you ran earlier. It uses dotnet publish the same way you did in this section to build and deploy.
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build
WORKDIR /app
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /app/aspnetapp
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY --from=build /app/aspnetapp/out ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
In the preceding Dockerfile, the *.csproj files are copied and restored as distinct layers. When the docker build command builds an image, it uses a built-in cache. If the *.csproj files haven't changed since the docker build command last ran, the dotnet restore command doesn't need to run again. Instead, the built-in cache for the corresponding dotnet restore layer is reused. For more information, see Best practices for writing Dockerfiles.
The Git repository that contains the sample app also includes documentation. For an overview of the resources available in the repository, see the README file. In particular, learn how to implement HTTPS:
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
ASP.NET Core feedback
ASP.NET Core is an open source project. Select a link to provide feedback:
Build end-to-end solutions in Microsoft Azure to create Azure Functions, implement and manage web apps, develop solutions utilizing Azure storage, and more.