richlander commented 7 years ago

Docker Layering for .NET Framework

The .NET team produces Docker images for the .NET Framework, on top of the windowsservercore base image. The release of the .NET Framework 4.7 has caused us to re-think our approach to .NET Framework docker images. This document proposes the new plan.

Goals

The team has the following goals, which are motivating the new plan:

The .NET Framework is large. It should be added to the Docker graph at a single node.
The .NET Framework 4.7 should not replace 4.6.2; both versions should be available for compatibility reasons.
The .NET Framework 4.7 should become the latest version in all scenarios.

These goals are not specific to the .NET Framework 4.7. Same logic applies when .NET Framework 4.7.1 ships.

Context

Today, there are 4 layers to the .NET ecosystem (in order, from base to leaf-node image):

You have to study the various Dockerfile files for each tag to fully understand the way the layering works. It works differently for .NET Framework 3.5 and 4.6.2. This is, in part, because 4.6.2 is in the windowsservercore base image. This assymetry is part of the problem.

Plan

The plan has the following primary characteristics:

The dotnet-framework repo will be the single place where .NET Framework versions are exposed (excluding versions that come in the windowsservercore base image).
The aspnet and wcf repos will layer directly on top of the dotnet-framework repo and expose the dotnet-framework version tags. They will add IIS components, as needed.
The iis repo will switch to being primarily for non-.NET scenarios.

Docker layering will look like the following (each sub-bullet in the list "FROMs" its parent):

windowsservercore (includes .NET Framerwork 4.6.2)
- dotnet-framework:4.7, :latest
  - aspnet:4.7, :latest
  - wcf:4.7, :latest
- dotnet-framework:4.6.2
  - aspnet:4.6.2
  - wcf:4.6.2
- dotnet-framework:3.5
  - aspnet:3.5
  - wcf:3.5

iis images will continue to include the .NET Framework 4.6.2 by virtue of using windowsservercore as a base image. iis images will not include .NET Framework 3.5 or 4.7. Users will be directed to use the aspnet or wcf repos to use IIS and .NET together. We'd like feedback if there are IIS + .NET scenarios that are not satisfactorily served by these two repos.

Feedback

Please share your feedback.

erichexter commented 7 years ago

It would be nice for the aspnet image to install additional iis features like websockets.

richlander commented 7 years ago

@erichexter You can add those features yourself. If there specific value in those features being added, beyond removing a line from your Dockerfile?

erichexter commented 7 years ago

@richlander Yes, I can certainly keep it in my own builds, its more a mater of the aspnet functionality working by default, versus having a list of additional things that need to be flipped on to get the most out of the framework. I picked websockets because, signalr will work without it being enabled, it will just be less efficient on the server and browser. So I look at that as a pit of success thing. Can the microsoft image for aspnet be optimized for the best performance of the framework.

g0t4 commented 7 years ago

How about a signalr specific repo optimized for that framework? Or some sort of official docs / guidance for building an optimized image?

On Fri, Jun 16, 2017 at 3:12 PM Eric Hexter notifications@github.com wrote:

@richlander https://github.com/richlander Yes, I can certainly keep it in my own builds, its more a mater of the aspnet functionality working by default, versus having a list of additional things that need to be flipped on to get the most out of the framework. I picked websockets because, signalr will work without it being enabled, it will just be less efficient on the server and browser. So I look at that as a pit of success thing. Can the microsoft image for aspnet be optimized for the best performance of the framework.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dotnet/designs/issues/7#issuecomment-309111090, or mute the thread https://github.com/notifications/unsubscribe-auth/AAK_3aZ5oz0fJmWD61TWhj46RvKWLx9Aks5sEtO1gaJpZM4Nwnb_ .

riezebosch commented 6 years ago

I would like to build my sources using a multi stage dockerfile. To be able to multi target I'm using the dotnet core csproj format. Unfortunately it is not possible to build these sources using the official dotnet:sdk image because it does not have the .NET Framework 4.7.1 Developer Pack installed. It is also not possible to build the sources using the dotnet-framework image because it does not have the .NET Core 2.0 SDK installed.

It seemed impossible to install the Developer Pack in the dotnet:sdk container. Maybe adding the dotnet-core SDK to the 4.7.1 image is an option?

kendrahavens commented 6 years ago

@riezebosch We are actively working on providing a .NET Framework 4.7 image that includes the .NET Core sdk! You can follow issue 49 over in the .NET Framework Docker repo to track progress.

dogtail9 commented 6 years ago

It would be nice to have an image with both the 4.7 and the 3.5 versions of .NET framework. The senario I am thinking about are buildservers based on Docker. There are tools out there that require .NET 3.5. WIX Toolset for example. I can work around this today by copy and paste the dockerfile for the 4.7 and 3.5 image into my own but then I have to do that every time there is an updates. I understand that you want to minimize the image size and the images with just one .NET version are great but sometimes I need both the 4.x and the 3.5 at the sametime.

g0t4 commented 6 years ago

@dogtail9 Have you tried a multi stage build? Each stage can run a different tool.

like to think of this as an assembly line where your "code" moves down a conveyor belt and stops at a station for each tool (image) that you need to assemble the final product.

The only caveat is how you orchestrate the external tools, for example if you have a script/build tool that calls each tool then you'd need to split that script apart so it could be run in each stage when the given tool is available.

dogtail9 commented 6 years ago

@g0t4 Yes, I have tried mutistage builds and it works great if you do your builds in a container. My use case is a container with the build agent for Team Foundation Server. We have about 20 build servers and hundreds of build definitions at the company I work today. I created an image with all the tools required to build the projects in my organisation. That way I speed up the deployment of a new build server from several months (a lot of manual steps to get a new server) to seconds (one server acting as a Docker host). And I minimize the work I have to do by trying to always use the url for the latest version of the tools I add to the image. Today I use the .NET 3.5 image as my base image and then I add .NET 4.7.1 by copying the installation step from the official .NET 4.7.1 image Dockerfile on Github. Everytime the url change due to security updates I have to do a manual step (update my Dockerfile) to get the latest version of .NET 4.7.1. It would make my life easier maintaining the build server image and defending this solution when security department at my company do an audit if there where an official image with both .NET Frameworks/CLR versions.

stabiliser commented 6 years ago

Will MSMQ be available in .NET Framework image?

richlander commented 5 years ago

This plan was implemented about a year ago. It is now time to close this issue.

dotnet / runtime