在我看来,自动生成的用于Web .net core应用程序的Dockerfile太大了,但为什么?为什么微软决定这样创建它?
当我们在应用程序创建过程中添加“添加docker支持”标志时,将生成如下Dockerfile:
为什么Microsoft决定首先获取aspnet:3.0-buster-slim来公开端口并将其后续用作最终结果呢?这样做似乎很麻烦,只需像我的示例中一样将此图像作为最后一步即可。另外,我们是否需要双重From来获取sdk:3.0-buster(第一个名称为build,第二个名称为publish)?可以像我的示例中一样逐个添加多个RUN步骤。
也许有一些技术建议解释为什么他们要这样做呢?
谢谢!
当我们在应用程序创建过程中添加“添加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"]
为什么Microsoft决定首先获取aspnet:3.0-buster-slim来公开端口并将其后续用作最终结果呢?这样做似乎很麻烦,只需像我的示例中一样将此图像作为最后一步即可。另外,我们是否需要双重From来获取sdk:3.0-buster(第一个名称为build,第二个名称为publish)?可以像我的示例中一样逐个添加多个RUN步骤。
也许有一些技术建议解释为什么他们要这样做呢?
谢谢!