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.
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.
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?.
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 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.
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".
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?