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.

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

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

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

Comments

Projects
None yet
8 participants
@kendrahavens
Collaborator

kendrahavens commented May 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kendrahavens
Collaborator

kendrahavens commented May 16, 2017

@Jonathan34

This comment has been minimized.

Show comment
Hide comment
@Jonathan34

Jonathan34 May 16, 2017

that simplifies image management and deployment!

Jonathan34 commented May 16, 2017

that simplifies image management and deployment!

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro May 16, 2017

Member

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

Member

galvesribeiro commented May 16, 2017

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

@MichaelSimons

This comment has been minimized.

Show comment
Hide comment
@MichaelSimons

MichaelSimons May 16, 2017

Collaborator

@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.

Collaborator

MichaelSimons commented May 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro May 16, 2017

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...

Member

galvesribeiro commented May 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@benaadams

benaadams May 16, 2017

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

benaadams commented May 16, 2017

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

@kendrahavens

This comment has been minimized.

Show comment
Hide comment
@kendrahavens

kendrahavens May 16, 2017

Collaborator

@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.

Collaborator

kendrahavens commented May 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kendrahavens

kendrahavens May 16, 2017

Collaborator

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.

Collaborator

kendrahavens commented May 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@MichaelSimons

MichaelSimons May 16, 2017

Collaborator

@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.

Collaborator

MichaelSimons commented May 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro May 16, 2017

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!

Member

galvesribeiro commented May 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@TerribleDev

TerribleDev May 16, 2017

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.

TerribleDev commented May 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kendrahavens

kendrahavens May 16, 2017

Collaborator

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

Collaborator

kendrahavens commented May 16, 2017

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 terrajobst closed this Nov 8, 2017

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Nov 10, 2017

Member

Reopening according to process.

Member

terrajobst commented Nov 10, 2017

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.