Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
kendrahavens opened this issue May 16, 2017 · 13 comments
Open

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

kendrahavens opened this issue May 16, 2017 · 13 comments
Labels
Docker

Comments

@kendrahavens
Copy link

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:

New multi-arch microsoft/dotnet-nightly tags:

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
Copy link
Author

@leecow @MichaelSimons @richlander

@Jonathan34
Copy link

that simplifies image management and deployment!

@galvesribeiro
Copy link
Member

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

@MichaelSimons
Copy link
Member

@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
Copy link
Member

@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
Copy link
Member

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

@kendrahavens
Copy link
Author

@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
Copy link
Author

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
Copy link
Member

@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
Copy link
Member

@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
Copy link

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
Copy link
Author

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

@dotnet dotnet locked and limited conversation to collaborators May 16, 2017
@terrajobst
Copy link
Contributor

Reopening according to process.

@terrajobst terrajobst reopened this Nov 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Docker
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@benaadams @richlander @TerribleDev @Jonathan34 @galvesribeiro @terrajobst @MichaelSimons @kendrahavens