.NET Core Docker images will move to multi-arch based tags

[kendrahavens]

Summary

Docker has a multi-arch feature that microsoft/dotnet-nightly recently started utilizing. The plan is to port this to the official microsoft/dotnet repo shortly. The multi-arch feature allows a single tag to be used across multiple machine configurations. Without this feature each architecture/OS/platform requires a unique tag. For example, the microsoft/dotnet:1.0-runtime tag is based on Debian and microsoft/dotnet:1.0-runtime-nanoserver if based on Nano Server. With multi-arch there will be one common microsoft/dotnet:1.0-runtime tag. If you pull that tag from a Linux container environment you will get the Debian based image whereas if you pull that tag from a Windows container environment you will get the Nano Server based image. This helps provide tag uniformity across Docker environments thus eliminating confusion.

Current microsoft/dotnet tags:

• 1.0.5-runtime, 1.0-runtime (1.0/debian/runtime/Dockerfile)
• 1.0.5-runtime-nanoserver, 1.0-runtime-nanoserver (1.0/nanoserver/runtime/Dockerfile)
• 1.0.5-runtime-deps, 1.0-runtime-deps (1.0/debian/runtime-deps/Dockerfile)
• 1.0.5-sdk, 1.0-sdk (1.0/debian/sdk/Dockerfile)
• 1.0.5-sdk-nanoserver, 1.0-sdk-nanoserver (1.0/nanoserver/sdk/Dockerfile)
• 1.1.2-runtime, 1.1-runtime, 1-runtime, runtime (1.1/debian/runtime/Dockerfile)
• 1.1.2-runtime-nanoserver, 1.1-runtime-nanoserver, 1-runtime-nanoserver, runtime-nanoserver (1.1/nanoserver/runtime/Dockerfile)
• 1.1.2-runtime-deps, 1.1-runtime-deps, 1-runtime-deps, runtime-deps (1.1/debian/runtime-deps/Dockerfile)
• 1.1.2-sdk, 1.1-sdk, 1-sdk, sdk, latest (1.1/debian/sdk/Dockerfile)
• 1.1.2-sdk-nanoserver, 1.1-sdk-nanoserver, 1-sdk-nanoserver, sdk-nanoserver, nanoserver (1.1/nanoserver/sdk/Dockerfile)
• 2.0.0-preview1-runtime, 2.0-runtime, 2-runtime (2.0/debian/runtime/Dockerfile)
• 2.0.0-preview1-runtime-nanoserver, 2.0-runtime-nanoserver, 2-runtime-nanoserver (2.0/nanoserver/runtime/Dockerfile)
• 2.0.0-preview1-runtime-deps, 2.0-runtime-deps, 2-runtime-deps (2.0/debian/runtime-deps/Dockerfile)
• 2.0.0-preview1-sdk, 2.0-sdk, 2-sdk (2.0/debian/sdk/Dockerfile)
• 2.0.0-preview1-sdk-nanoserver, 2.0-sdk-nanoserver, 2-sdk-nanoserver (2.0/nanoserver/sdk/Dockerfile)

New multi-arch microsoft/dotnet-nightly tags:

• 1.0.5-runtime, 1.0-runtime:
  • 1.0.5-runtime-jessie (1.0/runtime/jessie/Dockerfile)
  • 1.0.5-runtime-nanoserver (1.0/runtime/nanoserver/Dockerfile)
• 1.0.5-runtime-deps, 1.0-runtime-deps:
  • 1.0.5-runtime-deps-jessie (1.0/runtime-deps/jessie/Dockerfile)
• 1.0.5-sdk, 1.0-sdk:
  • 1.0.5-sdk-jessie (1.0/sdk/jessie/Dockerfile)
  • 1.0.5-sdk-nanoserver (1.0/sdk/nanoserver/Dockerfile)
• 1.1.2-runtime, 1.1-runtime, 1-runtime, runtime:
  • 1.1.2-runtime-jessie (1.1/runtime/jessie/Dockerfile)
  • 1.1.2-runtime-nanoserver (1.1/runtime/nanoserver/Dockerfile)
• 1.1.2-runtime-deps, 1.1-runtime-deps, 1-runtime-deps, runtime-deps:
  • 1.1.2-runtime-deps-jessie (1.1/runtime-deps/jessie/Dockerfile)
• 1.1.2-sdk, 1.1-sdk, 1-sdk, sdk, latest:
  • 1.1.2-sdk-jessie (1.1/sdk/jessie/Dockerfile)
  • 1.1.2-sdk-nanoserver (1.1/sdk/nanoserver/Dockerfile)
• 2.0.0-preview1-runtime, 2.0-runtime, 2-runtime:
  • 2.0.0-preview1-runtime-jessie (2.0/runtime/jessie/Dockerfile)
  • 2.0.0-preview1-runtime-nanoserver (2.0/runtime/nanoserver/Dockerfile)
• 2.0.0-preview1-runtime-deps, 2.0-runtime-deps, 2-runtime-deps:
  • 2.0.0-preview1-runtime-deps-jessie (2.0/runtime-deps/jessie/Dockerfile)
• 2.0.0-preview1-sdk, 2.0-sdk, 2-sdk:
  • 2.0.0-preview1-sdk-jessie (2.0/sdk/jessie/Dockerfile)
  • 2.0.0-preview1-sdk-nanoserver (2.0/sdk/nanoserver/Dockerfile)

This change has been in microsoft/dotnet-nightly for a little over a week. If you have feedback please file an issue on the .NET Core Docker GitHub repo.

.NET Core Docker Tools

The tooling to produce multi-arch tags is still evolving. As a result we found it necessary to create some tooling to build the images and produce the manifest that enables multi-arch. This tooling is open sourced as well.

[kendrahavens]

@leecow @MichaelSimons @richlander

[Jonathan34]

that simplifies image management and deployment!

[galvesribeiro]

Just wonder why WindowsServer Core images are not being published anymore, but good start! 😃

[MichaelSimons]

@galvesribeiro, The only .NET Core images we are producing for Windows is on Nano Server. The only .NET full framework images we are producing is on Windows Server Core. Nano Server is much lighter and thus provides the best docker experience for running your .NET Core apps on Windows.

[galvesribeiro]

@MichaelSimons hummm I may be wrong, but I could swear I saw windowsservercore images before. There are legitimate reasons on why you would use Windows Server Core over NanoServer even with .Net Core. For example, one would need PInvoke a Win32 API or a 3rd party native library which depends on it and that API would not be available on NanoServer.

I'm all up to use NanoServer, in fact I am using it. But I have cases where native code is required and NanoServer don't work with it...

[benaadams]

@galvesribeiro can still get the 5GB server core based images if that's your bag https://hub.docker.com/r/microsoft/windowsservercore/

[kendrahavens]

@galvesribeiro What do you mean? The lastest windowsservercore image was published just a 7 days ago. Are you referring to the .NET Framework images and windowsservercore not yet moving to 4.7? The full .NET Framework images were pushed just yesterday. We are still researching how moving the latest tag to 4.7 would affect users.

[kendrahavens]

Oh I see. Yes, @benaadams is right. You can always copy and paste layers from our nanoserver Dockerfile that install .NET Core and add them to a Dockerfile that uses the windowsservercore base image.

[MichaelSimons]

@galvesribeiro - you are correct in that we had .NET Core images based on windowsservercore for a short period while we were experimenting what made the most sense for everyone. These were removed under dotnet/dotnet-docker#129.

[galvesribeiro]

@benaadams I'm not saying it is impossible, I'm just saying it should be in the list of supported pre-baked .Net Core images. And it is not a matter of "my bag", it is a legitimate use-case where people with .Net Core applications must run it on Windows Server Core due to the bigger (native) API surface in it.

@kendrahavens Hey, I was saying that it should be on the list of .Net Core images since it is a valid scenario.

@MichaelSimons sure, I just saw that PR as well. Although I don't agree with the rationale that "it is better to use full framework with Server Core" I respect the decision. 😄

It was just a thought, don't want to make this a big case, just remember that almost everyone in corporate world that is migrating from .Net (full) Framework to .Net Core depends on that API to work and that would help migration paths.

Anyway, kudos for @kendrahavens on the announcement. Good work team!

[TerribleDev]

two things

1. Could announcements at dotnet/announcements get a separate thread on different repo, and have conversations in this repo get locked? Personally, I enjoy subscribing to announcements, but I'm not sure I want to be emailed for every comment, and reply.

2. While I would personally never consider running windows server. I'd think it would make sense to publish a servercore aspnetcore dockerfile. I work at a large e-commerce company, and I see many teams that want to move their existing apps to core. They like the programming model, and prefer the unified controllers. They want to eventually get off windows server, but parts of the API are still missing, or they are still dependent on other packages not yet core ready. Many of those missing api's are making a return in netstandard 2.0 (yuge kudos btw).

I think for many enterprises there is a transitory period, where an existing app is re-written ontop of mvc core, targeting full framework. They keep it on full framework, because much of their existing code relies on it. Then eventually the full framework training wheels are removed. I think it would make sense to provide a docker image for such a story, however its understandable if it seems unnecessary.

I do agree with @galvesribeiro thoughts, but as previously mentioned. We can easily roll our own.

[kendrahavens]

Moving conversation to dotnet-docker issue to clean up notifications for the announcement repo.