5 ms·

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/ https://hub.docker.com/r/ortuma

• r_venkat 8y ago
  The image seems to have the code and dependencies copied into it+ `go build` run on it, instead of just copying the built artifact.
  • ihsw2 8y ago
    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.
    • SEJeff 8y ago
      Example golang multi-stage build: https://github.com/jaegertracing/jaeger/blob/master/cmd/query/Dockerfile https://github.com/jaegertracing/jaeger/blob/master/cmd/quer...
      • Boulth 8y ago
        With the caveat that it doesn't build the app inside container, so the multi stage build is kind of underutilized here.
        • e12e 8y ago
          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. ]
          • Boulth 8y ago
            Isn't this the purpose of multi stage builds? To have one stage for building it and another, from scratch, to run it?
            • SEJeff 8y ago
              It is one of the purposes, yes. The idea being that you don't need build artifacts in containers which run the application.
• true_religion 8y ago
  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.
• eximius 8y ago
  Why is it even using Docker at all? One of the features of Go is that it is statically linked with it's dependencies!?
  • kiliankoe 8y ago
    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.
    • chatmasta 8y ago
      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.
• mike-cardwell 8y ago
  I just downloaded the image it's based from "golang:1.10" according to the Dockerfile - https://github.com/ortuman/jackal/blob/master/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.
  • unfunco 8y ago
    FROM scratch ADD main / CMD ["/main"]