What is the difference between alpine docker image and busybox docker image ?
When I check their dockfiles, alpine is like this (for Alpine v3.12 – 3.12.7)
FROM scratch
ADD alpine-minirootfs-3.12.7-x86_64.tar.gz /
CMD ["/bin/sh"]
FROM scratch
ADD busybox.tar.xz /
CMD ["sh"]
But as https://alpinelinux.org/about/ says
Alpine Linux is built around musl libc and busybox.
So what is exactly the difference ?
I am also curious that many docker images, (nodejs/nginx/php just name a few) provide images based on alpine but not on busybox. Why is that ? What is use case for busybox image then ? I need to emphasize that I am not looking for an answer about why A is better than B or vise versa or software recommendation.
I have been experiencing intermittent DNS lookup failure for my alpine docker, as here musl-libc – Alpine’s Greatest Weakness and here Does Alpine have known DNS issue within Kubernetes? said. That is one of reasons I asked my question.
PS, https://musl.libc.org/ says "musl is an implementation of the C standard library built on top of the Linux system call API" and https://en.wikipedia.org/wiki/Alpine_Linux mentioned
It previously used uClibc as its C standard library instead of the
traditional GNU C Library (glibc) most commonly used. Although it is
more lightweight, it does have the significant drawback of being
binary incompatible with glibc. Thus, all software must be compiled
for use with uClibc to work properly. As of 9 April 2014,[16] Alpine
Linux switched to musl, which is partially binary compatible with
glibc.
2
Answers
When I first asked the question I was not sure about the use case of busybox docker image and my link about busybox dockerfile was not entirely correct. This was the correct dockerfile link and it explains many things. So busybox provides 3 different versions, build on
glibc
,musl
,uclibc
A more appropriate question is what is the difference between alpine image and busybox image build based on musl? I still don't know the answer, except that alphine image is more actively maintained.
"Use Cases and Tips for Using the BusyBox Docker Official Image" was published Jul 14 2022 (so quite new) and it said "Maintaining the BusyBox image has also been an ongoing priority at Docker."
I still hope to see someone may provide answer about the use case of BusyBox image build on glibc or uclibc
--- update ---
As here discuss package manager for docker container running image busybox:uclibc "Anything based on Busybox doesn't have a package manager. It's a single binary with a bunch of symlinks into it, and the way to add software to it is to write C code and recompile." and here Package manager for Busybox also explained, busybox does NOT have package manager that is probably the reason why most poeple use alpine.
As for the DNS failure I experience randomly I find Why I Will Never Use Alpine Linux Ever Again explains it well
The key difference between these is that older versions of the
busybox
image statically linked busybox against glibc (current versions dynamically link busybox against glibc due to use of libnss even in static configuration), whereas thealpine
image dynamically links against musl libc.Going into the weighting factors used to choose between these in detail would be off-topic here (software recommendation requests), but some key points:
Comparing glibc against musl libc, a few salient points (though there are certainly many other factors as well):
Comparing the advantages of a static build against a dynamic build:
Honestly, these two images don’t between themselves cover the whole matrix space of possibilities; there are situations where neither of them is optimal. There would be value to having an image with only busybox that statically links against musl libc (if everything you’re going to add is in a non-C language), or an image with busybox that dynamically links against glibc (if you’re going to add more binaries that need libc and aren’t compatible with musl).