Docker: Use multi-stage build

[shaderecker]

• First stage: Compile the go binary from source

• Second stage:

  • alpine linux as base image
  • only copy the compiled go binary over from the first stage
  • install libc6-compat for compatibility between musl and glibc

• Final local image size is only 9.1 MB (for comparison: previously it was 1.04 GB)

• Compressed image size on Docker Hub is only 4.37 MB (for comparison: previously it was 495.98 MB)

Also: Fix entrypoint syntax to use exec form to call the binary directly (previously it used shell form, which always calls /bin/sh)

btw @pwaller: Do you intend to publish the image on e.g. Docker Hub? Then the users could save the step of building the image locally. For testing I used https://hub.docker.com/repository/docker/shaderecker/docker-show-context but maybe you want to publish it under your own user (setting up automated builds from the GitHub repo is pretty easy).

[pwaller]

Thanks for taking the time to contribute.

Re: PR as a whole: "Why not", though the value doesn't seem terribly high to me since if you're using docker you're probably normally pulling down large things and building them, and the build is not so big. The benefit to the user is that they know they're running what's in the repository, and not something which has diverged, which seems reasonable to me given the use case of the tool.

That said I could be persuaded if it seems significant enough to you.

Do you intend to publish the image on e.g. Docker Hub?

If you can persuade me it's super easy and worth while, why not, but I don't have much time to spare, so let's say, if I can do it in 10 minutes with a little guidance, or if it is obviously valuable (edit: in some way I had not considered before this conversation), I will, but otherwise not.

[shaderecker]

The size of the image is debatable. Since the compiled binary is pretty small I would also tend to keep the image size as small as possible.

The benefit to the user is that they know they're running what's in the repository, and not something which has diverged

The user still gets what is in the repository, the binary is still compiled from source. The alpine image in the second stage is merely a wrapper around the compiled go binary.

So the main point of the multi-stage build is to reduce the image size and to only have the final artifact (our go binary) in the final image.

If you can persuade me it's super easy and worth while

Ok let me try :D Here is the official guide: https://docs.docker.com/docker-hub/builds/ In short:

• You link your Docker Hub & GitHub accounts
• Create a new repository in Docker Hub (best named the same as the GitHub repository)
• Under Build Settings click on the GitHub icon
• Select the source repository from GitHub
• Under Buld Rules click the + button (this creates a default rule which builds from the master branch)
• Finish by clicking Create & Build