News for hackers. Stuff that matters.
Re:Show HN: Jackal – XMPP server in Go by sofaofthedamned on Tuesday May 08, 2018 @10:32AM (#17021125)
I've just checked the Docker image and it's 417mb. How on earth is it this large?

https://hub.docker.com/r/ortuman/jackal/tags/

Re:Show HN: Jackal – XMPP server in Go by eximius on Tuesday May 08, 2018 @04:33PM (#17024749)
Why is it even using Docker at all? One of the features of Go is that it is statically linked with it's dependencies!?
Re:Show HN: Jackal – XMPP server in Go by kiliankoe on Tuesday May 08, 2018 @06:51PM (#17026044)
Docker has a few more upsides than just bundling an app with its dependencies, orchestration being one of them. Also, a go app wouldn't have to be cross-compiled for whatever architecture as long as Docker runs there. Go makes that easy and effortless, sure, and there's nothing stopping you from doing so.
Re:Show HN: Jackal – XMPP server in Go by chatmasta on Thursday May 10, 2018 @03:48PM (#17042360)
Docker containers inherit the architecture of the host system. There is no CPU virtualization involved. So you still need to cross compile if you want to run the binary on another architecture, regardless of whether or not the binary is running inside a docker container.
Re:Show HN: Jackal – XMPP server in Go by mike-cardwell on Tuesday May 08, 2018 @05:58PM (#17025614)
I just downloaded the image it's based from "golang:1.10" according to the Dockerfile - https://github.com/ortuman/jackal/blob/master/Dockerfile

  mike@ung:~$ sudo docker image ls|grep golang
  golang              1.10                6b369f7eed80        3 days ago          794MB
  mike@ung:~$ 
794MB...

Should probably base it off an Alpine image instead. Would make it many times smaller.

[edit] In fact, there is a "golang:1.10-alpine" Docker image:

  mike@ung:~$ sudo docker image ls|grep alpine
  golang              1.10-alpine         05fe62871090        4 days ago          376MB
  mike@ung:~$ 
Hmm. even that one is bigger than I expected.
Re:Show HN: Jackal – XMPP server in Go by unfunco on Tuesday May 08, 2018 @11:06PM (#17027166)

  FROM scratch   
  ADD main /  
  CMD ["/main"]
Re:Show HN: Jackal – XMPP server in Go by r_venkat on Tuesday May 08, 2018 @10:37AM (#17021164)
The image seems to have the code and dependencies copied into it+ `go build` run on it, instead of just copying the built artifact.
Re:Show HN: Jackal – XMPP server in Go by ihsw2 on Tuesday May 08, 2018 @11:20AM (#17021525)
This is an opportunity for enterprising OSS contributors -- by virtue of being written in Go, converting their current Dockerfile to one that uses multi-stage builds should be simple and the resulting image would be as minimal as they come.
Re:Show HN: Jackal – XMPP server in Go by SEJeff on Tuesday May 08, 2018 @11:39AM (#17021724)
Re:Show HN: Jackal – XMPP server in Go by Boulth on Tuesday May 08, 2018 @12:10PM (#17022023)
With the caveat that it doesn't build the app inside container, so the multi stage build is kind of underutilized here.
Re:Show HN: Jackal – XMPP server in Go by e12e on Tuesday May 08, 2018 @12:43PM (#17022347)
You almost certainly want to build the app inside a container, but probably not the same container that result from the build.

[ed: well maybe not for a simple go project, as go has great cross compilation support. But if there's a bit of Javascript/(s)css/static resource munging - a container with a predictable build environment might become appealing. ]

Re:Show HN: Jackal – XMPP server in Go by Boulth on Tuesday May 08, 2018 @01:03PM (#17022527)
Isn't this the purpose of multi stage builds? To have one stage for building it and another, from scratch, to run it?
Re:Show HN: Jackal – XMPP server in Go by SEJeff on Tuesday May 08, 2018 @01:31PM (#17022779)
It is one of the purposes, yes. The idea being that you don't need build artifacts in containers which run the application.
Re:Show HN: Jackal – XMPP server in Go by true_religion on Tuesday May 08, 2018 @01:11PM (#17022602)
It probably bakes in the dependencies.

I do that on CI as well, since building dependencies often takes longer than just downloading a full VM.