Alpine vs Distroless vs Busybox
NOTE: This post is from 02.09.2021, I just recovered from my old blog
Let’s investigate in this post the most used(maybe) docker images busybox, alpine and google/distroless. In the cloud-native world, these images are widely used to containerize prod applications.
Why these images are so popular?
Here is the size of these images when you pulled in your local machine.
As you see the size of these images is incredibly small. Since if we start a busybox container:
There are hundreds of GNU commands in this 1.24MB image. How does this work/possible? That is the reason why it calls a Swiss army knife:) The magic behind is the Multi-Call binary. What is the Multi-Call binary?
Essentially, the multi-call binary is a program written in C which allows multiple calls to execute the binary. It contains functions and each function that perform a unique action can be invoked by a name, which is also a kind of symlink for multi-call binary. The best example is the Busybox.
Busybox function can be invoked in two ways:
busybox lsls
Obviously, these are not typical GNU binaries, as you see all binary has exactly the same properties like size, date, etc. We know these are not single binaries instead an alias for each function of a multi-call binary called Busybox.
Another important take is these Busybox commands sometimes do not perform the full functionality of the GNU command.
What about Alpine?
Did you recognize that the Alpine binaries are pointing to the Busybox binary? Apparently, the Alpine image uses busybox binary under the hood. Additionally, the Alpine contains the apk package manager and a few more executables that’s why the size is bigger than busybox.
Umm distroless?
These images are from google and :
“Distroless” images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.
GoogleContainerTools
Basically, these images are nearly empty except for containing timezone configs and a few ca-certificates.
I cannot even exec in this container, since the container has neither shell nor bash. Still, there are some options to shows like using dive or you can save the image as tar and extract it. I will use dive tool to inspect the image:
So there is only one layer and an image size 1.8MB:) On the right side, it is observable no binaries in the image and only some certs files, directories and if you scroll down you will see licenses, and timezone configs.
Small image has small attack surface and it is easy to maintain.
So you can investigate images with the dive tool and inspect your images in detail.
The end!
Credits:
- Ahmet for his excellent explanation.
- https://www.redbooks.ibm.com/abstracts/tips0092.html
- https://github.com/wagoodman/dive
- https://busybox.net/about.html
