Purpose of alpine images

[palsivertsen]

When experimenting with different images for my build pipelines I noticed that the golang alpine images does not support some built in tools like go get:

$ docker run --rm -it golang:1.10-alpine sh -c "go get github.com/palsivertsen/sse"
go: missing Git command. See https://golang.org/s/gogetcmd
package github.com/palsivertsen/sse: exec: "git": executable file not found in $PATH

This is true for golang alpine image versions 1.5 - 1.10 which made me wonder what the purpose of the alpine images are if you can't use them to compile code without predownloading dependencies? Shouldn't it at least be a golang alpine image that supports the full go toolchain?

Sort of relates to #209

[tianon]

See the following note from the image description:

golang:alpine

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

[tianon]

So to elaborate a little bit, if you need go get to fetch your code, then you should install git, go get, and uninstall git all in one RUN line so that the small size of your image can be preserved.

Additionally, if your application uses a vendor directory or some other means of fetching dependencies (such as the upcoming vgo: https://github.com/golang/vgo), git isn't always necessary. 👍

[tianon]

See https://github.com/tianon/rawdns/blob/c08783223d7b01766cbe2b2f7ed70f8a69653cc1/Dockerfile.cross for an example Dockerfile which uses an Alpine variant of this image and doesn't even install git (so fetching the base image for building all those cross-compiled binaries is very fast and lightweight).

[palsivertsen]

So alpine version mainly for use when compiling?

In my case I was trying to use it for things that require the full go toolchain, like go get, dep, etc. But I guess it's faster to use the standard image, than downloading additional tools inside the alpine image.

[tianon]

"apk add --no-cache git" finishes very quickly, as does "apk del git". That's why they aren't included (they're quick _and_ trivial for users of the image to install, but if we include them by default, they're impossible to uninstall).