Added onbuild Dockerfile

[vlesierse]

First of all, great to see that Microsoft helps to run ASP.NET 5 application on Docker. This opens up a ton of possibilities. The last days I was creating images on my own to test out ASP.NET vNext on CoreOS, but this make things a bit easier.

Personally when I deploy an application using a Docker container I like doing this using a onbuild version of the Docker image. An example of using this onbuild image could be found here. This is not something new and you see that for instance Node is also doing this.

Next thing this pull request addresses is the fact the Kestrel isn't running on Linux at the moment. There is already a issue reported, but it could help people getting the images and there code working correctly.

This pull request isn't really to contribute the code directly but start the discussion and ask for feedback.

PS. I love the direction Microsoft is moving to.

[ahmetb]

@vlesierse great work!

I'm not sure if we should provide onbuild images right now. ASP.NET 5 is still in preview and has many moving everyday. Since building an ONBUILD image restricts flexibility in certain areas, it requires deep understanding of everybody's use cases as any change in onbuild images may break every single user. This is something we might choose to avoid until aspnet-5 goes out of preview.

However, libuv parts are certainly needed. I suggest sending Kestrel fixes separately from ONBUILD images. We can merge those much easier.

[muojp]

@vlesierse great and fast. Yes, Kestrel support is important regardless of its stability at this time (because it's in very early preview stage). I'm eager to work on aspnet/KestrelHttpServer#34 for resolving certain dead-lock issue inside the framework (not yet tracked it's a Kestrel issue or Mono issue or even a libuv issue).

It seems your "Install libuv for Kestrel" part is copied from my recent work ( https://github.com/muojp/docker-asp.net/blob/18e779223f96dd79afcf563319003d1320c09a31/Dockerfile#L13-L19 ). It's a good mash-up I think. I already put the polished (avoided codeload.* hardcode for considering host name change) version of libuv build and sent PR #8.

[vlesierse]

@muojp That is correct. Compiling libuv when building the image was a great move although it didn't cover the whole fix for me somehow. I see that the ldconfig should solve this, but somehow it didn't with my onbuild scenario. That is why I copied the build output to the package created by the kpm restore.
find ~/.kpm/packages -name libuv.dylib | xargs -n 1 cp /usr/local/lib/libuv.so.1

@ahmetalpbalkan I agree. Also the k command needs to be executed in the folder containing the project.json which requires the WORKDIR to be set. It doesn't seems like a elegant solution. Perhaps some adjustment to the global.json to specify a startup project from the solution folder?

[ahmetb]

@vlesierse please squash into one commit and git push -f

[vlesierse]

Done

[vlesierse]

Closed this pull request for now and I will create a new one when we have concluded issue.
Proposal: ONBUILD image #19