Request for feedback: Should we produce .NET Core + Server Core container images?

[richlander]

Request for feedback: Should we produce .NET Core + Server Core container images?

We are exploring the possibility of producing .NET Core + Server Core container images. This is due to hearing feedback from .NET Core users that the Nano Server lifecycle relative to a Windows Server host doesn't work well. We have also seen users needing to use Server Core images because Nano Server is not compatible with their workload.

Feedback:

• Docker .Net Core Life Cycle Clarification #1842
• Using System.DirectoryServices on a Windows container with ASP.NET Core returns an error #1767
• Unable to load DLL 'gdiplus.dll' when using Windows based docker images #1098
• Unable to use HttpSys with ASP.NET Core 2.0 and Windows Server Nano aspnet/aspnet-docker#398
• https://social.msdn.microsoft.com/Forums/en-US/a6f3dd50-39c1-4bc9-a665-6a8cc2cbec81/file-share-in-app-service-or-gdi-in-containers-for-windows-apps?forum=windowsazuredevelopment

Some context: We have long believed (on the .NET team) that customer demand for the combination of .NET Core and Server Core would be low and that producing .NET Core images for both Server Core and Nano Server would be confusing and send a mixed message. In short, we thought that nearly all .NET Core users would want Nano Server images. With that in mind, we decided to let customers produce Server Core container images themselves (but, of course, still support .NET Core with Server Core, generally). We are re-assessing this viewpoint and stance, but need your feedback to do so.

It would be very useful to know how many people/companies would use .NET Core + Server Core images if we made them available. Please tell us if you'd use these images, if you would use them instead of the .NET Core + Nano Server images, and what type of app you would host, preferably in this issue. If you are willing (or would prefer a private conversation), we will want to talk to you directly to learn more about your scenarios. You can reach out to me at rlander@ms.

Details

We have discussed a few different variants of what .NET Core + Server Core images could look like. There are two (meta) use cases we are considering, in terms of the types of apps that you host across your containerized .NET app portfolio:

1. All apps are .NET Core.
2. Mixture of .NET Core and .NET Framework apps, sometimes hosted in the same image.

Some context: In order to get the best performance for .NET Framework apps, we need to NGEN the framework. In fact, without NGEN, the performance is not acceptable. See microsoft/dotnet-framework-docker#29 for past experience on this topic. NGEN is even more important starting with the Server Core 2004 container image release. See: We made Windows Server Core container images 40% smaller.

If we were to publish Server Core images, we'd need to decide if we should NGEN the framework, which would have a non-trivial size impact. Example of NGEN usage: .NET Framework runtime image. Enabling IIS and ASP.NET (not Core) support would require similar configuration and size impact.

Some people might say ... "Hey, this is .NET Core; don't worry about .NET Framework." It's not so simple. We know that a non-trivial set of users will end up using the .NET Framework in these Server Core images, and then be unhappy, but not know why. We have found over time that users do everything imaginable (and beyond that) with the product, so we have to prepare for a lot of eventualities. We are one team responsible for two products and need to consider a broad set of scenarios in which images might be used.

Possible configurations

The following is a set of configurations that we can imagine supporting (some of which resolve the .NET Framework-related topics I've raised). I've provided names for these configurations to help frame what the benefit would be. We'd like you to tell us which of these options you like best, or if you'd want multiple. If your preferred option is missing, please tell us that, too.

1. Straightforward "Core on Core" -- Publish one Server Core image per .NET Core version (example tags: dotnet-core/aspnet:3.1-windowsservercore-1909, dotnet/aspnet:5.0-windowsservercore-1909). This approach matches current practice (same model used for .NET Core on Nano Server, today). Details: do not NGEN the .NET Framework, or pre-install IIS or ASP.NET.
2. Consolidate .NET Core versions on Server Core -- Publish one Server Core image with all in-support .NET Core versions included (we'd probably start with 3.1 and 5.0). Server Core images are multi-gigabyte, while .NET Core is relatively small. It might be cheaper and easier for many customers to base all application container images on a single Server Core image, independent of which .NET Core version was used. Details: Do not NGEN the .NET Framework, or install IIS or ASP.NET.
3. Consolidate .NET Core and .NET Framework on Server Core -- -- Publish one Server Core image with all in-support .NET Core versions included, and .NET Framework (including ASP.NET and IIS fully enabled). Server Core images are multi-gigabyte, while .NET Core is relatively small and fully enabling .NET Framework doesn't cost much more. It might be cheaper and easier for many customers to base all application container images on a single Server Core image, independent of which .NET Core or .NET Framework version was used. Details: NGEN the .NET Framework, install IIS, and enable ASP.NET.

There are lots of sub-options for each of these, some of which we've already identified. For example, we could publish images aligning with options #1 and #2 in .NET Core docker repos and images aligning with option #3 in either .NET Core or .NET Framework repos. It all depends on how we want to approach this larger topic, and the scenarios we want to enable (and that you need).

I've only provided the tagging scheme for the first option, since it is so obvious. We have identified tagging schemes for the other two options, but they are more complicated (consolidation inherently complicates tagging), so we'll only continue to explore and share those if we we see interest in these other options. We want to keep this conversation as high-level as possible.

Please share your feedback!

[jbaig]

In my original issue #1842 the problem is more about nanoserver reaching end of life much before the LTSC of the server hosting it and how companies should plan if they want to use .net core with docker on windows.
The 1809 (Windows Server 2019 LTSC) was scheduled to reach EOL in May [now pushed back to November - Lifecycle changes announced on April 14, 2020], but what will that mean for users using .net core with docker on Windows Server 2019 after November?

The servercore image is over 10x larger than the nanoserver image, so although having an official .net core image would be preferred, going from ~350megs to ~5gigs is not ideal.
Is there any way the nanoserver Life Cycle can be adjusted or a similarly smaller footprint base image be created that lasts for almost as long as the life of the LTSC server it is hosted on?

[richlander]

Understood. Naturally, the .NET team doesn't define the Nano Server lifecycle. That said, we've given feedback to the Windows team on that topic over time. In absence of a change in Nano Server lifecyle, our only other option (for options my team can affect) is offering Server Core images. I understand that this comes with a size drawback.

[TheBlueSky]

I speak from personal experience rather than on behalf of a company.

A while ago I created an ASP.NET Core application that I was unable to run on a Nano Server image. So, I created and started maintaining .NET Core on Server Core images.

For me, I would have used option number 1 (Straightforward "Core on Core") if it was available. But given that maintaining 5 different images and 9 tags is just a matter of modifying one line in a file every now and then, it does not matter to me whether there are official images or not.

If I have a workload that involves .NET Core and .NET Framework with ASP.NET and IIS, the story might have been different, though.

[MichaelSimons]

aspnet/aspnet-docker#398 is another scenario that would be solved by adding support for Windows Server Core images.

[ssa3512]

We have some third party native libraries that our application does P/Invoke interop with. These libraries don't seem to be compatible with nanoserver, so having server core images maintained by Microsoft with the dotnet core sdk and runtime preinstalled would be fantastic.

[richlander]

@ssa3512 -- do you mean the SDK or the runtime or both? You need the SDK to build and test, but don't use it in production (as you likely know).

[ssa3512]

@richlander both would be ideal but runtime is more important. We have a good number of integration tests that cover portions of the application that interface with the interop components but can run these in other ways. dotnet/core/aspnet would also be preferable to us over dotnet/core/runtime as we are interested in being able to provide a gRPC or REST interface as well as utilize the aspnet core healthchecks functionality.

[sritapa]

Currently my team is working on moving away from classic Azure Cloud Services to Azure Kubernetes. The current codebase is on .Net framework. While exploring the possibility of hosting our service on Windows container in AKS, we realized that it is possible to launch an application where the service entrypoint is a .Net core app (Asp.Net Core Web application as an alternate to Webrole in Azure Cloud Service) with underlying .NetFramework dependencies. Taking this approach, we are able to reuse 90% of our regular codebase and changing only the topmost layer in our code architecture. (Our code base design allowed us to achieve this as we have separate projects for Database access, business logic, business entities etc) .This enables the migration work much easier as we do not need to rewrite any core business logic code and eliminate the need for testing of business logic layers.

However, it was difficult to find a compatible Windows image that supports this scenario and builds successfully by resolving all depenedencies. Currently I am using this -

mcr.microsoft.com/dotnet/framework/sdk/:4.8-windowsservercore-ltsc2019

The docker image that is produced is huge (~12 GB).

I described our use case scenario which might be relevant for a lot others from the . Net framework world where one would like to avoid rewriting business logic heavy code and yet leverage the advantages of AKS/ .Net core Web Apps.

I will update this thread with more details as I make progress. Thanks to @richlander for providing guidance throughout this time.

[Escoto]

I think this would solve an issue I have I've been working on solving....
I am running a .net core console app which needs some C++ libraries from SAP, I am having issues setting up an environment which runs the .net Core alongside VC_redist.exe

With the current set of images, I either get to install VC or Run my app (which crashes after not being able to execute the c++ dlls)...
Even after I get this to work i am not sure if the dlls will be compatible with the runtime i'll end-up with