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

[biiiipy]

From my experience, with the relative size of images, Option 2 is the most important. The small size increase is worth it, if we can consolidate on one image. In addition, making Option 1 is probably also important.

I want to stress this - Please think about your end consumers. For MS to build couple more images so people can pick what they need is a lot easier for people than to go about and build those images themselves (and do it correctly). That's a huge time sink, and it is easily solved by MS just adding some additional automated builds, to add Option 2, 1, or even 3.

[uBpringlIoNaRys]

We want to release our product based on windows server 2019 as it is LTSC. On this OS we want to run netcore containers. Given the issues above we cannot use netcore base images as all netcore image are based on nanoserver 1809 and won't be available anymore when nanoserver falls out of support.
Meaning, if MS does not produce netcore base images based on servercore 2019 LTSC we have to build and maintain our own netcore base images.
If this is the only option we also strongly vote to support at least option 1.

[mthalman]

A decision has been made to move forward with producing Windows Server Core images and will be part of the 5.0 release. Thanks to everyone that responded on this issue. Your feedback is valuable and helps us in our decision-making.

The 5.0 release will still continue to have Nano Server images and they will be the default platform for shared tags. This means that the 5.0 tag, for example, would retrieve a Nano Server image when pulled for Windows. Windows Server Core will just be an additional tag choice that will be available.

Given the short amount of time between when 5.0 is released and the end-of-life dates for Windows Server SAC versions 1809 and 1903, those Windows versions will not be supported for either Nano Server or Windows Server Core. Only LTSC versions of Windows will be supported for Windows Server Core images.

In summary, these will be the supported Windows versions for 5.0 when it releases:

• Nano Server: 1909, 2004, 2009
• Windows Server Core: LTSC 2019

[prabh-62]

@mthalman Does this mean, dotnet team is dropping support for nanoserver:1809 ?

It is not possible to deploy (to Azure Container instance) any windows container with a version higher than nanoserver:1809. I agree, that dotnet team should not be supporting nanoserver:1809 which will go EOL on Nov 10, 2020 but that means users cannot deploy .NET5 apps on ACI (Nano Server: 1909, 2004, 2009 is not supported on ACI: Refer to #2257 (comment))

[mthalman]

Does this mean, dotnet team is dropping support for nanoserver:1809 ?

@prabh-62 - "Dropped" wouldn't be the correct terminology. Support for nanoserver:1809 is not being dropped because 5.0 hasn't even been released yet. It's just that when 5.0 is released, nanoserver:1809 will not be one of the supported platforms. For .NET Core 2.1 and 3.1, nanoserver:1809 will still be supported until its EOL date.

Your concerns are not specific to .NET. Please provide your feedback to the ACI team via the docs page you referenced.

[uBpringlIoNaRys]

@mthalman Regarding the comment to provide net5.0 on LTSC 2019. Does this imply for netcore 3.1 (support ends 12/2022) a LTSC2019 based image will not be provided?
Meaning in November when support for nanoserver:1809 ends we need to switch to net5 (which is not a LTSC release) to continue running windows containers on windows server (LTSC)?
It would be really nice to have a combination of windows server, windows base image and .net where all of them are LTSC.

[mthalman]

Does this imply for netcore 3.1 (support ends 12/2022) a LTSC2019 based image will not be provided?

@uBpringlIoNaRys - Correct. That's the plan of record right now. The support for Windows Server Core LTSC 2019 would only apply to 5.0. One way to workaround this is to author your own image based on Server Core that installs .NET Core 3.1. There is published guidance on how to do this. That would be the recommended approach if you are intending to only rely on LTS product versions given the upcoming EOL situation.

We'll continue to look for feedback on this topic of 3.1 support for an LTS Windows version. Having more demand will help us make the case to make a change.

[richlander]

Windows Server Core 2019 images have been published as part of .NET 5.0 RC2. We will update the images for .NET 5.0 GA, and then service them from there.

Note: The new Windows Server Core + .NET images were not announced in the RC2 blog post. That was accident on my part. Sorry about that! They will be announced in the 5.0 GA post, next month.

You can see Windows Server Core images in the .NET Docker Hub pages, as you can see in the following image.

From: https://hub.docker.com/_/microsoft-dotnet-sdk/

Our plan is to produce .NET images for LTSC Windows Server versions, only. We also plan to produce Windows Server Core images for .NET 5.0+. If you want some other combinations of images, please file separate issues on this repo. We have achieved the goals that were set out by this issue.

[jzabroski]

@richlander Tangential: It would be amazing if we could run tests for browser based GUI apps inside container images. The amount of value this would create for customers would just be huge.

My understanding is pre-1709 had some of the bits necessary, such as Remote Desktop Services, but it was later removed: https://www.withinrafael.com/2018/03/09/using-remote-desktop-services-in-containers/

I can't even begin to state how such a feature would basically keep me on Windows for pretty much ever, by abstracting away complex stuff like COM Registry Hive settings into docker filesystem layers within an image.

[richlander]

That would indeed be nice, @jzabroski. Have you tried the windows image? https://hub.docker.com/_/microsoft-windows. Perhaps that has more of the functionality you. I honestly don't know.