aspnetDocker.md

This proposal captures the potential use of an ASP.NET specific Docker image that builds on what microsoft/dotnet already provides.

We could build 2 images:

###microsoft/aspnet: This image would be optimised for you to load your already compiled ASP.NET applications into.

• Contains the same as the microsoft/dotnet:1.0.0-core, just a runtime and OS pre-reqs.
• Contains a runtime cache of native assembly images. This cache would contain the closure of all or most of the packages that the ASP.NET team ships. ASP.NET packages + all their dependencies.
• In benchmarks we have shown that including all ASP.NET assemblies in a runtime cache increase the image size-on-disk by ~10mb whilst improving the start time of a container running MVC Music Store by ~32% (around a 3 second improvement). This improvement represents the time taken to JIT the applications dependencies.

###microsoft/aspnet-build: This image would be optimised for compiling ASP.NET applications inside a container. Though it could run apps as well.

• Contains everything in the microsoft/aspnet image
• Pre-restore a set of ASP.NET packages to make the restore/build process faster. This is another disk/time trade off where we would use more disk space on NuGet packages to speed up the restore inside the container.
• NPM + Bower so that the default templates can be built.

###Potential Extension

1. Another idea is for the runtime image to contain a proxy, probably HAProxy or Nginx. The proxy would by default listen on a port and direct to localhost:5000 (the default port if you do nothing else in a new web app). By doing this we are doing two things:
2. Codifying the current guidance to put something in-front of Kestrel doing things like HTTP and TCP normalization.
3. Avoiding the common problem of Kestrel only listening on localhost by default, as the proxy could always be the publically accessable port and it maps to a local port.
4. Changing the proxy would be possible when building the app image, if ports need to be different or something of that sort.

how about a container that has the basics and then allows a dotnet restore to be run as part of starting up the instance?

@julielerman Not sure I follow what you're thinking. You mean the build image has some of the packages, so restore is a bit faster, but not all of them so the size isn't too large?