Почему многостадийный Dockerfile для ASP.NET Core использует 4 этапа

Question

Это многоэтапный Dockerfile по умолчанию, когда вы нажимаете "Добавить поддержку Docker" в Visual Studio на основном сайте ASP.NET.

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 этап. Кроме того, зачем создавать publish этап с использованием того же build базовое изображение. Почему 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"]

Есть ли какое-то преимущество в этом, которого мне не хватает?

Answer 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 этапом. Это становится вопросом предпочтения, представления и всего. Ничто технологически не отличается

Answer 2

Нет никаких программных оснований для использования 4 этапов.

На первом этапе меняется только конфигурация. На третьем этапе изображение не меняется. Единственное использование FROM build AS publish иметь новый псевдоним.

Я думаю, что бесполезно заботиться о последующих изменениях в структуре сборки Docker. (Код из 4 этапов, вероятно, делает это.) Используйте версионные изображения, как в вашем примере. Например 2.0 вместо latest, Таким образом, несовместимости можно избежать. Если будут изменения в сборке, вы можете ее догнать.

Рекомендация докера работает без указания имени csproj, как при использовании *.csproj, Это работает для большинства проектов, создавая размер изображения около 350 МБ.