为Web.net核心应用程序自动生成Dockerfile

在我看来，Web.net核心应用程序的自动生成Dockerfile太大了，但为什么呢？为什么微软决定这样做

这是在应用程序创建过程中添加“添加docker支持”标志时自动生成的Dockerfile：

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["app/app.csproj", "app/"]
RUN dotnet restore "app/app.csproj"
COPY . .
WORKDIR "/src/app"
RUN dotnet build "app.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "app.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "app.dll"]

在我看来，它可以是这样的：

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster as build
WORKDIR /src
COPY ["app/app.csproj", "app/"]
RUN dotnet restore "app/app.csproj"
COPY . .
WORKDIR "/src/app"
RUN dotnet build "app.csproj" -c Release -o /app/build
RUN dotnet publish "app.csproj" -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim
WORKDIR /app
EXPOSE 80
EXPOSE 443
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "app.dll"]

为什么微软决定首先获得aspnet:3.0-buster-slim只是为了公开端口，并在以后作为最终端口使用？在我的示例中，仅将此图像作为最后一步就要短得多。对于sdk，我们是否还需要双重来源：3.0-buster（第一个命名为build，第二个命名为publish）？可以像我的示例中那样逐个添加多个运行

也许有一些技术上的建议，他们为什么决定这么做？

---

谢谢

A

Dockerfile

是

docker build.

命令使用的一系列步骤。至少需要三个步骤：

FROM some-base-image
COPY some-code-or-local-content
CMD the-entrypoint-command

随着我们的应用程序变得越来越复杂，添加了额外的步骤。比如恢复包和依赖项。下面这样的命令用于：

RUN dotnet restore 

-或-

或者类似的。当它变得更加困难时，图像构建时间将增加，图像大小本身也将增加

Docker构建步骤生成多个Docker映像并缓存它们。请注意以下输出：

$ docker build .
Sending build context to Docker daemon  310.7MB
Step 1/9 : FROM node:alpine
 ---> 4c6406de22fd
Step 2/9 : WORKDIR /app
 ---> Using cache
 ---> a6d9fba502f3
Step 3/9 : COPY ./package.json ./
 ---> dc39d95064cf
Step 4/9 : RUN npm install
 ---> Running in 7ccc864c268c 

注意

步骤2

是如何说

使用缓存的

，因为docker意识到步骤2之前的所有内容都与上一个构建步骤相同，因此使用上一个构建命令中的缓存是安全的

该模板的重点之一是构建高效的图像。 可通过两种方式实现效率：

减少构建映像所需的时间

缩小最终图像的大小

对于#1，可以利用以前版本中的缓存映像。将dockerfile划分为越来越多地依赖于以前的构建，可以加快构建过程。只有在Dockerfile有效写入的情况下，才可能依赖缓存

通过分离构建的这些阶段并发布

docker build.

命令，将能够更好地使用docker文件中以前步骤中越来越多的缓存

例如，对于#2，避免安装不需要的软件包

---

有关更多详细信息，请参阅docker文档。

docker文件中的第一个图像是VS用于调试的图像（按照惯例，有一个设置可以覆盖该图像，并在VS 2019中使用特定的命名阶段）。很明显，你想要一个尽可能短和快的周转时间。

$ docker build .
Sending build context to Docker daemon  310.7MB
Step 1/9 : FROM node:alpine
 ---> 4c6406de22fd
Step 2/9 : WORKDIR /app
 ---> Using cache
 ---> a6d9fba502f3
Step 3/9 : COPY ./package.json ./
 ---> dc39d95064cf
Step 4/9 : RUN npm install
 ---> Running in 7ccc864c268c