Maybe I'm missing something here but I don't see this as being particularly useful?

It's a nice quick way to get an application running in Docker but realistically would you want to be depending upon these images in production?

The power I see in Docker is the ability to create portable images that contain everything my application needs. I don't want to depend upon Docker (the company) to figure out what these images should look like.

Am I looking at this the wrong way?

I understand where you're coming from. At first glance I thought it would be the return of the dreaded virtual appliance giving people no clue on how developer X got to end result Y.

However, this is not that. Docker simply gives more emphasis to officially maintained docker images of popular projects, all of which have Dockerfiles available for your inspection!

If the Dockerfiles were available, I would feel better about it. Just glancing around I couldn't find the stacks Dockerfiles, so not sure those are available.

I think they're here: https://github.com/docker-library

There are links to all the dockerfiles on the repo pages on Dockerhub.

Does anyone know why debian was chosen as the source for these repos? I thought they were defaulting to ubuntu.

ie. https://github.com/docker-library/golang/blob/master/1.3/Doc...

This question was asked on https://github.com/docker-library/golang/issues/11#issuecomm... too, but the main reason is that the "debian" base images are tightly controlled and kept really minimal, so it's easy to make the new images as minimal as they can be too. The Ubuntu images are also great, but they include more stuff as part of keeping a consistent experience, so they don't have the same focus on minimalism that the Debian images can.

Note that the image maintainers (starting with tianon above) reserve the right to change the base distro they use for the images. So they can truly use the best tool for the job, now and in the future.

Changing the distro underneath would break all other Dockerfiles that assume they are running on a certain distro. How do we have to deal with cases when the distro is switched from debian to centos for example?.

If you don't want things to get broken further down the line, you should use tags. It's the same with any dependency.

Taking that a step further - why not a busybox image to get even smaller?

How would you install the build dependencies with busybox? Go requires some packages to build, from the Dockerfile:

apt-get install -y ca-certificates curl gcc libc6-dev bzr git mercurial

It's possible to install another package manager like opkg. See https://github.com/progrium/busybox

right, that would be an option, if opkg had packages for python mercurial or bzr. (those are needed for go get to work). Don't see those in http://downloads.openwrt.org/snapshots/trunk/x86_64/packages...

Another solution is to build your go executable in a different container and import it into a busybox container. That changes the layering from:

    debian
    add go, bzr, mercurial, python, ...
    build executable

to:

    busybox
    executable

That reduces the amount of data that needs to be downloaded on new boxes by a factor of ten or so.

Yeah, that looks good - I'm in Australia so anything that reduces the amount I need to download is excellent.

I'm very happy to see Hy language among the official repos! I think more people should know about it.

For people not aware, "Hy transforms its Lisp code into the Python Abstract Syntax Tree"[0].

[0]: http://hy.readthedocs.org/en/latest/index.html

This is quite huge. A transpiled LISP in a trendy mainstream project ... I need to sit.

ps: while they're at it, there's also http://scriptor.github.io/pharen/ (php)

Can someone explain to me what the fuss is about? I mean, e.g. the Java 7 dockerfile is 3 lines. Why is it better for me to FROM these images instead of copying those three lines into my own dockerfile?

Well from a practical sense it's just making it more modular for you to mix and match without duplicating configuration. But the fuss is about PR. If this were Gentoo or something there'd just be a big directory of ebuilds and you'd just use them as you needed. But an announcement like this always makes it to the front page of HN, and then other sites, and they get more eyeballs on their site. So it's half useful, half business-as-usual.

Pity they choose "Golang" instead of "Go" for their default Go image. It's called "Go". And they built Docker with Go.

Pity Google choose "Go" instead of "Golang" for their programming language. There were already another "Go!". And they built it from scratch so they could choose whatever name instead of a common English word.

Go isn't very search friendly, Golang is A LOT better for identifying and searching anything related to it.

Yes, and silly Google for making the URL for Go "golang.org". Someone should let them know it's called Go, not golang!

This is like the new "It's GNU/Linux - NOT LINUX!" Except with less validity. It's totally interchangeable in common usage, and in fact much more explicit to use the term "golang".

> And they built Docker with Go.

That's why they know "Go" is very often called "Golang", for search-engine-related reasons.