Which Container Images To Use — Distroless Or Alpine?

Here is an experiment to understand this better

Photo by Ian Taylor on Unsplash

Using containers for application development and deployment is very common these days.

While containers certainly bring a lot of value, they also bring some challenges like —

• Bigger Images means increased build time, as well as increased cost
• More libraries included in the images can increase the scope of vulnerability scan tools
• etc.

The most common solution to this problem is — using smaller distros!

Using lightweight distros like Alpine is a very common technique amongst the developers to avoid making the container image bulky. Even though you can achieve that there is always a risk of open vulnerabilities caused by the underneath libraries.

Google solved this problem by introducing Distroless images.

“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.

After reading Gaurav Agarwal’s story about How to Harden Your Containers With Distroless Docker Images, I decided to give it try and get a first-hand experience.

In this article, I am going to create a Java Application container using Distroless and using Alpine image, run vulnerability scans on both, and compare things like build time, image size, etc.

So let’s get started.

Using Distroless Image

I created a simple Hello World Spring Boot Java application for this experiment.

First I created a Dockerfile using Distroless image as shown below —

FROM maven:3.5-jdk-8 AS build
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
RUN mvn -f /usr/src/app/pom.xml clean package
FROM gcr.io/distroless/java:8
ARG DEPENDENCY=/usr/src/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib