Suggestion: Different approach for distroless .NET Core

[jgowdy]

I'd like to suggest a different approach for building distroless .NET Core container images. Rather than shipping the runtime and creating runtime dependent versions of the .NET Core container images, if we utilize the package list in:

https://github.com/GoogleContainerTools/distroless/blob/master/experimental/dotnet/BUILD

to build an image with those dependencies (but without the .NET runtime tarball), then a .NET Core application compiled with the "self-contained" option would include the aspects of the runtime that are used (and only those aspects). This would allow the distroless image for .NET Core to change when the underlying dependencies are changed, or when the base distribution of Debian changes, but would potentially not require an update for consumers to use newer versions of .NET Core where the dependencies are the same. The idea being a distroless .NET Core image that supports multiple versions of .NET Core self-contained applications.

https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained

As a demonstration, you can use the "cc" distroless image to run self-contained hello-world .NET Core apps today, although you will potentially hit missing dependencies at runtime if you try to use functionality that depends on libcurl for example.

I believe if this approach was used for .NET Core support, the burden of maintaining the distroless .NET Core images may be greatly reduced.

Thoughts?

[chanseokoh]

Sounds like a great suggestion (although I admit I don't really understand as I know nothing about .NET). I am also curious what the .NET Distroless community thinks.

[chgl]

The downside I can see with this is that it doesn't make effective use of layer caching: usually, the .NET Core runtime files would reside in their own layer and any custom assemblies would be added to the final layer(s). Releasing a new version of one's assembly would then only require downloading this small final layer.

On the other hand: self-contained and trimmed .NET Core binaries are already quite small...

I quite like the Layered Jar approach that Spring Boot/Java uses: explode your binary and its dependencies into multiple layers which can be efficiently cached based on change frequency.

[chanseokoh]

@chgl if you liked Spring's layered Jar approach, you should definitely check out Jib (although the article uses a very old version of Jib–the latest is 2.4.0). I am sure it will take you to the whole new next level of dev experience.

[EricStG]

I'd be interested in this as well.

To add a bit more details, .NET Core applications can be published in two ways:

• Framework dependent
  That's when you have the runtime installed on the OS.
  When it comes to Docker, it means you either have the .NET Runtime or the ASP.NET Core Runtime as your base image.

• Self contained
  This is when the application is publish with all of its dependencies, including the runtime, which can then be trimmed and packed into a single file.
  Once published, you only need the .NET Runtime Dependencies base to run your application

Having a distroless image with only the runtime dependencies would make it possible to have much smaller images than the current approach, which includes the entire runtime.

[aw185176]

It looks like the .NET distroless image was removed recently, is there any intention to bring it back or should this issue be closed?

[viewable]

@aw185176

It looks like the .NET distroless image was removed recently, is there any intention to bring it back or should this issue be closed?

Per #710

We can consider adding it back if there's sufficient demand once we figure out how to stop overloading the package mirrors.

So my vote is probably stay open, since .NET distroless images were removed only due to rate limits directly related to some of what's been discussed here.

[hazcod]

FYI if you need native code self-contained apps don't work with distress.