Item template for dockerfile

[vlada-shubina]

Extracted from https://github.com/dotnet/templating/issues/233

Create an item template for a dockerfile (for .NET projects)

This is currently blocked by https://github.com/dotnet/templating/issues/3107 and https://github.com/dotnet/templating/issues/3829 as there is no way to get information about the project such the output path of a project, its TFM, etc in order to correctly generate a dockerfile.

[baronfel]

Spec:

• two images:
  • build image of dotnet/sdk, with an SDK docker image tag chosen based on the SDK version at the time of running the dotnet new command
  • runtime image, with the appropriate runtime base image (dotnet/runtime or dotnet/aspnet, based on the type of project) and runtime tag (based on the runtime version at time of running the dotnet new command)

Required inputs (may be derived from runtime execution at time of dotnet new, or specified explicitly during the dotnet new command as options):

• SDK version
  • Compute SDK_MAJOR_MINOR from this
• Runtime version (RUNTIME_IMAGE_TAG)
• Project output assembly name (PROJECT_OUTPUT_ASSEMBLY_NAME)
• Path to project file (PROJECT_FILE)
• All contents of project file (ALL_PROJECT_CONTENT)

Proposed Dockerfile template contents:

FROM mcr.microsoft.com/dotnet/sdk:<SDK_MAJOR_MINOR> AS build-env
WORKDIR /app

# Copy project file and restore as distinct layers
COPY <PROJECT_FILE> ./
RUN dotnet restore

# Copy everything else and build
COPY <ALL_PROJECT_CONTENT> ./
# publish RID-specific since we know the hosting OS/Architecture
RUN dotnet publish -c Release -o out --os linux --arch x64

# Build runtime image
FROM mcr.microsoft.com/<RUNTIME_IMAGE_NAME>:<RUNTIME_IMAGE_TAG>
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", <PROJECT_OUTPUT_ASSEMBLY_NAME>]

There's some overlap here with the proposed SDK User Story around generating OCI Container Images from a project natively. If that progresses the need for this template item may be lessened.

[dasMulli]

I'd suggest using a non-root user by default together with a port > 1024 (e.g. 8080) to make sure that:

• The Dockerfile doesn't trigger repo scanning tools for misconfiguration warnings
• Running the container in Kubernetes won't be a problem even in presence of stricter configurations since requiring to run as non-root user is likely to become a common default with Pod Security Admission controller setups (PodSecurityPolicy on clusters compliant with CIS Benchmarks already require this and depending the underlying software, binding to a port < 1024 won't work as non-root user)