Why is it even using Docker at all? One of the features of Go is that it is statically linked with it's dependencies!?
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.
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. FROM scratch
ADD main /
CMD ["/main"]The image seems to have the code and dependencies copied into it+ `go build` run on it, instead of just copying the built artifact.
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.
Example golang multi-stage build:
https://github.com/jaegertracing/jaeger/blob/master/cmd/quer...
With the caveat that it doesn't build the app inside container, so the multi stage build is kind of underutilized here.
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. ]
Isn't this the purpose of multi stage builds? To have one stage for building it and another, from scratch, to run it?
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.
https://hub.docker.com/r/ortuman/jackal/tags/