Redigera

Dela via


Run an ASP.NET Core app in Docker containers

Note

This isn't the latest version of this article. For the current release, see the .NET 9 version of this article.

Warning

This version of ASP.NET Core is no longer supported. For more information, see the .NET and .NET Core Support Policy. For the current release, see the .NET 9 version of this article.

Important

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 the current release, see the .NET 9 version of this article.

This article shows how to run an ASP.NET Core app in Docker containers.

Windows Home Edition doesn't support Hyper-V, and Hyper-V is needed for Docker.

See Containerize a .NET app with dotnet publish for information on containerized a .NET app with dotnet publish.

ASP.NET Core Docker images

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.

Prerequisites

Download the sample app

  • Download the sample by cloning the .NET Docker repository:

    git clone https://github.com/dotnet/dotnet-docker
    

Run the app locally

  • Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.

  • Run the following command to build and run the app locally:

    dotnet run
    
  • Go to http://localhost:<port> in a browser to test the app.

  • Press Ctrl+C at the command prompt to stop the app.

Run in a Linux container or Windows container

  • To run in a Linux container, right-click the System Tray's Docker client icon and select switch to Linux containers.

  • To run in a Windows container, right-click the System Tray's Docker client icon and select switch to Windows containers.

  • Navigate to the Dockerfile folder at dotnet-docker/samples/aspnetapp.

  • Run the following commands to build and run the sample in Docker:

    docker build -t aspnetapp .
    docker run -it --rm -p <port>:8080 --name aspnetcore_sample aspnetapp
    

    The build command arguments:

    • Name the image aspnetapp.
    • 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.

  • Run the dotnet publish command:

    dotnet publish -c Release -o published
    

    The command arguments:

    • 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.

Additional resources

Next steps

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:

ASP.NET Core Docker images

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.

Prerequisites

Download the sample app

  • Download the sample by cloning the .NET Docker repository:

    git clone https://github.com/dotnet/dotnet-docker
    

Run the app locally

  • Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.

  • Run the following command to build and run the app locally:

    dotnet run
    
  • Go to http://localhost:5000 in a browser to test the app.

  • Press Ctrl+C at the command prompt to stop the app.

Run in a Linux container or Windows container

  • To run in a Linux container, right-click the System Tray's Docker client icon and select switch to Linux containers.

  • To run in a Windows container, right-click the System Tray's Docker client icon and select switch to Windows containers.

  • Navigate to the Dockerfile folder at dotnet-docker/samples/aspnetapp.

  • Run the following commands to build and run the sample in Docker:

    docker build -t aspnetapp .
    docker run -it --rm -p 5000:80 --name aspnetcore_sample aspnetapp
    

    The build command arguments:

    • Name the image aspnetapp.
    • 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.

  • Run the dotnet publish command:

    dotnet publish -c Release -o published
    

    The command arguments:

    • 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.

Additional resources

Next steps

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:

ASP.NET Core Docker images

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.

Prerequisites

Download the sample app

  • Download the sample by cloning the .NET Docker repository:

    git clone https://github.com/dotnet/dotnet-docker
    

Run the app locally

  • Navigate to the project folder at dotnet-docker/samples/aspnetapp/aspnetapp.

  • Run the following command to build and run the app locally:

    dotnet run
    
  • Go to http://localhost:5000 in a browser to test the app.

  • Press Ctrl+C at the command prompt to stop the app.

Run in a Linux container or Windows container

  • To run in a Linux container, right-click the System Tray's Docker client icon and select switch to Linux containers.

  • To run in a Windows container, right-click the System Tray's Docker client icon and select switch to Windows containers.

  • Navigate to the Dockerfile folder at dotnet-docker/samples/aspnetapp.

  • Run the following commands to build and run the sample in Docker:

    docker build -t aspnetapp .
    docker run -it --rm -p 5000:80 --name aspnetcore_sample aspnetapp
    

    The build command arguments:

    • Name the image aspnetapp.
    • 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.

  • Run the dotnet publish command:

    dotnet publish -c Release -o published
    

    The command arguments:

    • 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.

Additional resources

Next steps

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: