为什么 ASP.NET Core Multi-Stage Dockerfile 使用 4 Stages答案

【问题标题】：Why does the ASP.NET Core Multi-Stage Dockerfile use 4 Stages为什么 ASP.NET Core Multi-Stage Dockerfile 使用 4 Stages
【发布时间】：2018-04-20 12:01:32
【问题描述】：

这是在 ASP.NET Core 站点的 Visual Studio 中单击“添加 Docker 支持”时默认的多阶段 Dockerfile。

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app

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

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

他们为什么选择使用四个阶段，从base 阶段开始和结束。另外，为什么要使用相同的build 基本映像创建publish 舞台。为什么 Dockerfile 不是这样分三个阶段的：

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app

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

FROM microsoft/aspnetcore:2.0 AS final
WORKDIR /app
EXPOSE 80
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

这有什么我缺少的优势吗？

【问题讨论】：

或许，图像尺寸更小？

标签： docker asp.net-core dockerfile docker-multi-stage-build

【解决方案1】：

文件等效于下面

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY WebApplication1.sln ./
COPY WebApplication1/WebApplication1.csproj WebApplication1/
RUN dotnet restore
COPY . .
WORKDIR /src/WebApplication1
RUN dotnet build -c Release -o /app
RUN dotnet publish -c Release -o /app

FROM microsoft/aspnetcore:2.0 AS base
EXPOSE 80
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

现在他们可能选择 4 个构建阶段的原因可能是两者中的任何一个

演示文稿
未来的变化

所以它可能描绘了一个

base -> build -> publish -> deploy the build

具有 2 个构建阶段的大小也与这个相同。所以2阶段和4阶段没有明显区别。它成为一种事物的偏好、代表和一切。技术上没有什么不同

【讨论】：

我写了一个与你的非常相似的 Dockerfile，然后意识到 dotnet build 和 dotnet publish 命令正在输出到同一个文件夹。我的问题中的 3 阶段 Dockerfile 会阻止这种情况吗？
不，它没有，它仍然是相同的输出。见stackoverflow.com/questions/27320374/…。我还没有检查 build 和 publish 是否创建不同的文件，但只有一个 publish 也应该按照操作系统线程工作，因为如果构建没有完成，那么 publish 也会构建。跨度>
是的，我也这么认为。我假设build 在那里，所以你可以添加一个命令来运行测试。可能最好的解决方案是从build 命令中删除输出参数，因此二进制文件将构建到默认的bin/Release 目录中。
阅读这个帖子stackoverflow.com/questions/46949192/…你会发现VS没有最优化的docker文件。但是您想使用 VS 生成的内容，以便它与未来的升级很好地集成

【解决方案2】：

使用 4 个阶段没有程序上的原因。

在第一阶段，只是更改了配置。在第三阶段，图像没有改变。 FROM build AS publish 的唯一用途是拥有一个新别名。

我认为在 docker 的构建结构中处理以后的更改是没有用的。（4 阶段代码可能会这样做。）使用版本化图像，就像在您的示例中一样。例如。 2.0 而不是 latest。这样可以避免不兼容。如果构建的方式会有变化，你可以赶上它。

docker 建议在没有指定 csproj 名称的情况下工作，就像使用 *.csproj 一样。这适用于大多数项目，产生大约 350MB 的图像大小。

【讨论】：