Add Dockerfiles for Linux .NET Composite Images

[ivdiazsa]

Describe the Problem

We have been working on .NET composites where, by bundling together the most needed assemblies, we are able to deliver a lower startup time, and overall better performance when running .NET apps. Our next step is to have the official Docker images recurrently built, alongside the existing .NET Linux images, so that customers can consume them.

Describe the Solution

We currently build them by hand but that can only be used for internal testing. We would like to have them officially published in the website: https://hub.docker.com/_/microsoft-dotnet

Additional Context

In order to achieve this purpose, we would like to add the corresponding Dockerfiles in this repo, which will pull the composites from the ASP.NET repo artifacts, and use them in a similar fashion as the currently existing Dockerfiles.

• https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/readytorun-overview.md
• https://github.com/dotnet/runtime/blob/main/docs/design/features/readytorun-composite-format-design.md

[ivdiazsa]

@mangod9 @richlander Here's the issue we can use to track progress and discussions to get the .NET composite images, and Dockerfiles, published to customers.

[ivdiazsa]

Adding @trylek as well as he has been a key contributor to this project.

[tmds]

We have been working on .NET composites where, by bundling together the most needed assemblies

Is a .NET composite a single file that bundles parts of different assemblies?

we are able to deliver a lower startup time, and overall better performance

What causes it to start faster? and achieve a better performance?

[trylek]

The .NET composite image bundles together the ready-to-run native code from all component assemblies. The managed assemblies themselves remain on disk but they are basically pure MSIL. (Everything can then be bundled into one file using the Single EXE .NET feature though.) The better startup and to a certain extent performance (so far we've mostly been focusing on startup) stems from the fact that a composite image can be treated as a "versioning bubble". The limitation that it always naturally needs to be shipped / serviced as a whole lets us do the following:

• JIT can drop ready-to-run type / field layout compatibility checks at assembly boundaries;
• We can inline more code across assemblies within the versioning bubble;
• We can directly encode field offsets for types from a different assembly within the versioning bubble;
• We can compile a larger set of generic instantiations over types from all assemblies within the versioning bubble.

So far we haven't been focusing too much on steady state performance as that's supposed to be optimized by runtime tiered JITting. The problem with steady state performance is that many perf-critical constructs in general JIT and in the framework foundations e.g. cleaning up local variable area on the stack in method prologs or string manipulations can be much better optimized in the presence of various instruction set extensions (e.g. AVX2 on x64) while by default we strive to generate code compatible with all CPU variants i.e. using only the base instruction set.

Crossgen2 does include options to declare what instruction set extensions are guaranteed to be present at runtime and in their presence it can generate the better optimized code right away but we tend to see that as a niche scenario that's only worth the effort where super high performance is of bigger value than compatibility.

[tmds]

If I understand correctly, the composite image is a single file that provides the functionality otherwise split in many shared framework dlls in an optimized way?

Are we building these composites as part of source-build?

Are they included in the shared framework folders (like Microsoft.NETCore.App/7.0.2)? Or where do they live?

[ivdiazsa]

Are we building these composites as part of source-build?

Yes, the artifact that we'll use for the Docker image already includes everything built. In other words, the Dockerfile's code here won't look very different from say the normal existing Runtime one.

Are they included in the shared framework folders (like Microsoft.NETCore.App/7.0.2)? Or where do they live?

That's right.

[ivdiazsa]

The composite Dockerfile would look as follows:

ARG REPO=mcr.microsoft.com/dotnet/runtime-deps

# Installer image
FROM amd64/buildpack-deps:jammy-curl AS installer

# Retrieve Composite .NET Runtime
RUN dotnet_version=7.0.2 \
    && curl -fSL --output dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/$dotnet_version/aspnetcore-runtime-$dotnet_version-linux-x64-composite.tar.gz \
    && mkdir -p /dotnet \
    && tar -oxzf dotnet.tar.gz -C /dotnet \
    && rm dotnet.tar.gz


# .NET Runtime Base Image
FROM $REPO:7.0.2-jammy-amd64

# .NET Runtime and ASP.NET Versions
ENV DOTNET_VERSION=7.0.2
ENV ASPNET_VERSION=7.0.2

COPY --from=installer ["/dotnet", "/usr/share/dotnet"]

RUN ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

Here it's using .NET 7 for testing, but the purpose is to release it for .NET 8.

[richlander]

I was thinking about the layering.

We were talking about: sdk -> aspnet -> runtime-deps; runtime -> runtime-deps

I am guessing we'll be getting layer sharing (in an absolute byte sense) by: sdk -> runtime -> runtime-deps; aspnet -> runtime-deps

We should be able to determine this through some quick measurements. I'm guessing that the runtime layer is larger than the aspnet layer.