Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Hub Official Repos: Announcing Language Stacks

blog.docker.com

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Docker Hub Official Repos: Announcing Language Stacks

#21

Post by cpuguy83 »

danielbln wrote: post #15
pandog wrote: post #14

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 image…

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.

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

Re: Docker Hub Official Repos: Announcing Language Stacks

#23

Post by levosmetalo »

farslan wrote: post #19

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.

Re: Docker Hub Official Repos: Announcing Language Stacks

#26

Post by TeMPOraL »

farslan wrote: post #19

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

> And they built Docker with Go.

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

Re: Docker Hub Official Repos: Announcing Language Stacks

#27

Post by peterwwillis »

skrebbel wrote: post #25

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.

Re: Docker Hub Official Repos: Announcing Language Stacks

#28

Post by zimbatm »

0x006A wrote: post #16
zimbatm wrote: post #13

Earlier quoted context omitted.

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.

Re: Docker Hub Official Repos: Announcing Language Stacks

#29

Post by snupples »

farslan wrote: post #19

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

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

Re: Docker Hub Official Repos: Announcing Language Stacks

#30

Post by voltagex_ »

zimbatm wrote: post #28
0x006A wrote: post #16

Earlier quoted context omitted.

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.
Post reply on HN