Repo structure with multiple dockerfiles

[glennc]

We have #84 adding CoreCLR support for this dockerfile, and we will soon have Windows based Dockerfiles for windows containers.

Do we think that a Dockerfile for each image should be in this repository or that we should make a repo for Windows and a Repo for Linux?

Seems something like this would probably work in this repo:

/Windows/1.0.0-beta7/Dockerfile
/Linux/1.0.0-beta7/Dockerfile

or alternatively if we want the CLR to be a different image instead of a tag on the same image:

/Windows/CLR/1.0.0-beta7/Dockerfile
/Linux/CLR/1.0.0-beta7/Dockerfile

What are peoples thoughts on how this should work? I am thinking a single repo with everything at the moment since we will generally want to update all of the dockerfiles at the same time. So it would be convenient for maintenance to have them all in the same place. Are there reasons to split them that I am missing though?

[glennc]

@ahmetalpbalkan @anurse

[ahmetb]

Also #83...

I think for now we should not think much about Windows because Docker Hub to host windows images is still a bit far away. Looks like no one explored that land of publishing cross-platform Docker images either, therefore it's up to us at this point.

To me it looks like, different platform images should live at different GitHub/Docker Hub repos. Hosting Windows vs Linux on the same repo sounds like a bad idea to me... Changes on one will trigger a rebuild on other platform (b/c docker hub commit hooks).

Immediate problem we need to solve is (#83 #84), how do we host coreclr images... I think for those Linux flavors (CoreCLR vs Mono) they can stay here, we just prefix them with coreclr- (we actually have a single example of that) and they can happily live together in this repo.

cc: @vlesierse @friism @akoeplinger @jchannon what do you think?

[friism]

The way that the Docker registry people are thinking about this is here: distribution/distribution#200

I'd also wait and see how that shakes out in the public registry, specifically whether images for different platforms are supposed to live as different tags on the same repository or as different repositories.

[ahmetb]

+1 good idea. What do you think about mono vs coreclr @friism?

[friism]

Hm, good question. I think the situation is somewhat similar to PHP vs. PHP Zendserver and Ruby vs. JRuby (all official images): they're different ways to run the same programs. Those are in different repos.

For my purposes, I need the mono image right now because npgsql doesn't work on coreclr. If I were you, I'd factor out the mono-aspnet image into a separate repo. It seems like the coreclr one is going to be very simple: install libuv and dnvm and you're done.

[vlesierse]

I like the idea of having a separate repo for different platforms. What I know is that Linux container cannot run on Windows and vice versa because they are sharing the kernel. Both of them gets different readme files anyway

Mono vs CoreCLR is a different story I think. The images are quite similar. As a developer I would prefer the CoreCLR version, but when I would like to have more functionality that isn't part of CoreCLR or I have libraries that aren't ported to CoreCLR yet I would choose for the Mono image.

Prefixing with coreclr- (and later perhaps mono-) makes sense.

[muratg]

Also, do we have to use folders for DNX releases? Can we use git tags instead?

[ahmetb]

Also, do we have to use folders for DNX releases? Can we use git tags instead?

@muratg Tags are way hard to maintain. For instance if we try to upgrade the libuv version or base mono image version in beta3 tag, we need to go back there and fix it. Tags in git are more like for snapshotting purposes whereas we're maintaining many versions simultaneously in this case.

Also a common practice in Docker world, you can find more examples of this at https://github.com/docker-library/

[glennc]

I am good with all of these being different DockerHub repos, but do they have to equate 1:1 with GitHub repos? Seems like we could have a single GH repo with several DH repos building different sets of Dockerfiles.

I am leaning towards that because it seems like we need to change them together more often than not and having them in a single repo makes that much easier.