Hacker News new | ask | show | jobs
by joshpadnick 3464 days ago
Now that the official Ubuntu containers have gotten down to around 50MB for an image [1], can the case still be made for using Alpine?

Admittedly, Alpine images are just 2MB [2], but I kept running into so many edge cases with musl, apk didn't always have the packages I wanted and often lagged behind critical security updates, and documentation/community was much smaller than I'd like. It's a genuine question. I'm wondering if the case can be made to prefer Alpine as your default Docker base image.

[1] https://hub.docker.com/r/library/ubuntu/tags/

[2] https://hub.docker.com/r/library/alpine/tags/

4 comments

I personally find the package system on Alpine to be much more suited for container-like environments compared to Ubuntu. For one thing, it's trivial in Alpine to install a package without having to 'apt update' and remove the cache after installing. Additionally, the process of installing a bunch of build dependencies under a temporary namespace and uninstalling them after the build process is really streamlined.

Mostly for these reasons I prefer a (slightly modified) Alpine base. I do at times run into musl compatibility issues, in those cases I most often fall back to Ubuntu.

I don't think Alpine uses systemd, so there's that.

I attempted Alpine for my router, but at the time there was no UEFI support (grub2-efi was in the unstable tree). That made me turn to Void Linux, which is totally worth checking out. I use it on my current x86 based router:

http://penguindreams.org/blog/building-a-thin-itx-router/

edit: sorry didn't read you comment entirely; init system doesn't make a difference for a docker base :-P

Well 48MB is a lot. Also Musl Libc has advantages, eg it has an emphasis on correctness, it is easy to understand (read the code, it is great, Glibc is very hard to understand). Plus if you want to make statically linked binaries you pretty much need to use Musl, as Glibc has many cases that do not work.

Which security updates? Generally these are pretty quick, and the processes are improving.

I hope the processes keep improving. They recently introduced Alpine SecDB[0], which is their database (YAML files) of CVEs. I've been told from one of their developers that it may not be actively maintained. I hope they stick with it since now we can use that in Clair[1] to improve the transparency of containers.

[0]: http://git.alpinelinux.org/cgit/alpine-secdb/

[1]: https://github.com/coreos/clair

If you're serving using repo software (and rebuilding often to pick up the security updates) then Ubuntu (or Debian) starts to make sense.

If you're purely running your own application/service (or non-repo software, e.g. rwasa) then Alpine seems perfect.