Reputation: 30175
I need to create a docker container for an Asp.Net Core application (though the idea is the same for any application in any language) and there are 2 different approaches from what I can see:
From Microsoft docs:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
COPY bin/Release/netcoreapp3.1/publish/ App/
WORKDIR /App
ENTRYPOINT ["dotnet", "NetCore.Docker.dll"]
From Docker docs:
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
WORKDIR /app
# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# Build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "aspnetapp.dll"]
From what I can tell the difference is where the build of the application happens: either inside the docker itself or outside docker (in ci/cd tool e.g.) and only the output being copied in the docker file.
Is there any other technical difference/benefit between these approaches apart from the obvious ones of where the build commands are executed? (E.g. one would be faster, more reliable, etc.)
P.S. I plan to run CI/CD inside a containerized environment like Github Actions or Bitbucket pipelines, so the build should not be dependent on local develop settings in any case.
Upvotes: 2
Views: 622
Reputation: 211540
Personally I find if you build in the container there's fewer surprises as slight differences between developer machines become irrelevant, but there's a case to be made for both approaches. Sometimes the container build is slower, so you have to settle for a sub-optimal situation.
A build on your dev machine will have access to 100% of the CPU, generally speaking, but in a container it is limited by your Docker settings. Most people usually have that at 50% or less to avoid hogging the whole machine, so it's 50% as fast at best.
So the more reproducible approach is to let the container build everything.
The more performant approach is to build externally, then quickly package in the container.
Note that this equation changes considerably if you have a low-powered laptop but a very fast build server you can offload the build to. For example, there's no way a 2-core i3 laptop with 8GB can keep up with a 32-core Ryzen or Epyc server with 256GB.
Upvotes: 2