This project is an example of the different possible methods of producing increasingly smaller docker images from Kotlin applications. It is inspired from this talk by Shaun Smith.

The goal was to have a concrete example with a Kotlin application using some reflection, threads, coroutines and IO.

The application itself is a simple Ktor application which does the following:

• wait 2 seconds,
• start the server,
• receive all incoming HTTP post requests and write them in a file,
• shutdown if it receives "STOP" or after 20 seconds passed.

Although shrinking the image size brings quite a few benefits, it also has its own set of disadvantages. The main one here is that we tend to sacrifice layers re-usability, which would be very useful in companies with many variants of the same base application and slight changes between each iteration, for example.

In such cases, stopping at the custom JRE step could be better, on top of making the process easier since we don't need to "sacrifice" reflection (more on that in this part).

Bellsoft images are mentioned a few times. They create minimalistic, java-optimized images for the exact purpose we pursue here, you can learn more about them by following this link.

"Distroless" images are images that are made to contain the bare minimum so that your application can run. It is a project maintained by Google, you can learn more about those images here.

Chainguard also provides images designed for security and minimalism. They are similar to Google "distroless" images as most don't have a shell or package manager and are build using Wolfi, a linux "undistro" made specifically for containers. They also provides a tool called Apko, giving you the possibility of creating your own minimalistic image. Learn more about them here.

Both libraries are implementations of the C standard library for Unix-like systems. It is the interface between the application and the kernel (file interactions, network communications, ...). You can learn more about libc libraries here and here. In the statistics, both will be counted as libraries.

• under the GNU Lesser General Public License (LGPL)
• found in most linux distributions

• under the MIT license
• lightweight and efficient

To run this project, you will need to have Docker installed and running (Podman may also work, but it hasn't been tested).

To build all the images locally, you can use the build_image script in this repository. It will build and tag all the .dockerfile, so that you can see the differences for yourself.

In each section, you will find a measurement of the size of the various parts of each image and their final size. Those numbers may change depending on a few factors, like the version of the base image used, and should only be used as a comparison. Sometimes since the base image and libraries are bundled in a single layer they are either estimated via an archive if available or are counted together (indicated with ... (+ libraries) in the base image size column, and --- in the libraries size column). Also, you may find that sometimes the individual numbers don't exactly add up to the total size. That is because of rounding, as the total is what you will see with docker image ls and the individual numbers were calculated from the individual layers.

The jar itself has a size of 16.9 KB and the fatJar has a size of 10.7 MB.

Here is the simplest but heaviest alternative, we build and run the application in a container with all the tools:

A simpler, but still heavy alternative is to use the bundled gradle wrapper. Thus, we just need an image with a JDK.

We now create 2 distincts step:

• We first build a fatJar (jar with dependencies)
• We then move it to a more minimalist container with only the java runtime

From this point, the size of the builder image (first step) isn't considered, as it doesn't impact the final image size.

We still use the 2 steps model, but rather than using a generic JRE, we generate our own with only the necessary modules.

To see which modules you need, you can use jdeps --print-module-deps --ignore-missing-deps <FAT_JAR_PATH> and plug the output in the baseModules property.

For all builds, I will use the Eclipse Temurin JDK to generate our custom JRE.

At this point we don't need an image with a JDK or JRE anymore, so we have a lot of options. In this example, I chose to test with debian, which is one of the most used linux distribution image, and alpine, which is known for being a very minimalistic linux distribution. I am also using the alpaquita linux distribution by Bellsoft, which is an alpine-like linux distribution tailored for JVM-based applications.

You can also play with the JLink options (jlinkOptions in gradle.properties).

As you can see, in most case it is not a good idea to use general purpose images like the debian image, which bundle a bunch of tools with it (git, curl, ...), which we don't need to run our application. Those images also come with an increased attack surface, which we should always try to minimize.

This is a major shift to the deployment process. Contrarily to the previous steps which didn't need any change to the code itself, this will need some preparation. The major difference is that instead of compiling a jar file and running it with a java runtime, we compile to a native executable with an ahead-of-time (AOT) compiler. This means that everything that uses reflection will have to either be removed or clearly declared via the configuration options so that the compiler knows what to do with it.

In our case, you can see the type options provided in a JSON file and the flags passed to the native-image tool.

For images including the native-image tool, please refer to the graalvm registry containing the native-image image and the native-image-community image.

You can also use Liberica Native Image Kit (NIK) which is based on GraalVM Open Source and might sometimes create more compact executables. If you want to learn more, see this page.

One important difference between those tools is that most image you will find for GraalVM images are Linux-based, while Liberica Native Image Kit images are Alpine Linux based.

For both of those tools, you will need an image containing a few things (on top of the chosen tool):

• a 64-bits musl toolchain, make and configure
• the zlib library

In the next tables I will also specify the builder image, as it does influence the resulting application size.

This is pretty similar to the previous step, but in this step we also statically link all libraries, except for libc. This lets us run the application on any Linux libc-based distribution.

The issue here with mostly static images in alpine-linux is that it is hard to find a base image having just glibc or musl lib, but if you were to find one, it would be a small decrease from the dynamically linked native image.

This is the very last step (excluding executable compression and such things that also impact performance).

Instead of relaying on the OS providing the libc library, we also package it with the executable to create a completely static image.

What is scratch ? It is the smallest possible image, as described here.

Why use gcr.io/distroless/static then ? It includes :

• CA certificates: no need to copy them from build stage
• /etc/passwd: contains users and groups such as nonroot
• /tmp
• tzdata: in case you want to set a timezone other than UTC

The graphs resume the differences between each step. The first 2 steps are not included as they have a far bigger size than the others (3 to 5 times compared to the next step), making the charts a lot less readable.

For easier comparison, there is a graph with Linux-based images and another with Alpine-Linux-based images. Please note that for images that don't have distinct base image and libraries sizes, both are counted as base image size.