When running Java applications in containers, you need to be careful with your resources. If you’re not careful with layering your images (for example using Google’s Jib), you can quickly get into disk-space issues, especially when your base image and/or application gets updated regularly. One of the ways you can save resources is by using small base images. In this blog post I determined the uncompressed size of several base images containing OpenJDK 11.0.6 which are available on Docker Hub.
Used script
I used the following Bash script to determine the size of the downloaded images (uncompressed / on my disk) and version of bundled OS libraries. Be careful when running it for yourself! The script cleans your Docker environment.
strings=( adoptopenjdk:11.0.6_10-jdk-hotspot-bionic azul/zulu-openjdk-alpine:11.0.6 azul/zulu-openjdk:11.0.6 openjdk:11.0.6-slim openjdk:11.0.6-jdk-slim-buster adoptopenjdk/openjdk11:x86_64-ubi-minimal-jdk-11.0.6_10 adoptopenjdk/openjdk11:jdk-11.0.6_10-ubuntu-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-ubuntu adoptopenjdk/openjdk11:jdk-11.0.6_10 adoptopenjdk/openjdk11:jdk-11.0.6_10-ubi-minimal adoptopenjdk/openjdk11:jdk-11.0.6_10-ubi-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-ubi adoptopenjdk/openjdk11:jdk-11.0.6_10-debianslim-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-debianslim adoptopenjdk/openjdk11:jdk-11.0.6_10-debian-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-debian adoptopenjdk/openjdk11:jdk-11.0.6_10-centos-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-centos adoptopenjdk/openjdk11:jdk-11.0.6_10-alpine-slim adoptopenjdk/openjdk11:jdk-11.0.6_10-alpine mcr.microsoft.com/java/jdk:11u6-zulu-alpine mcr.microsoft.com/java/jdk:11u6-zulu-centos mcr.microsoft.com/java/jdk:11u6-zulu-debian10 mcr.microsoft.com/java/jdk:11u6-zulu-debian8 mcr.microsoft.com/java/jdk:11u6-zulu-debian9 mcr.microsoft.com/java/jdk:11u6-zulu-ubuntu ) for i in "${strings[@]}"; do echo "$i" >> output.txt docker run --name jdk -it "$i" cat /etc/os-release | grep PRETTY_NAME | tail -n1 >> output.txt docker images | awk '{print $NF}' | tail -n1 >> output.txt docker stop `docker ps -qa` docker rm `docker ps -qa` docker rmi -f `docker images -qa ` docker volume rm $(docker volume ls -qf) docker network rm `docker network ls -q` done dos2unix output.txt cat output.txt | paste -d, - - -;
For the JRE variants I used the same script with the following list of images:
openjdk:11.0.6-jre-buster
openjdk:11.0.6-jre
openjdk:11.0.6-jre-slim-buster
openjdk:11.0.6-jre-slim
openjdk:11.0.6-jre-stretch
adoptopenjdk:11.0.6_10-jre-openj9-0.18.1
adoptopenjdk:11.0.6_10-jre-hotspot
adoptopenjdk:11.0.6_10-jre-openj9-0.18.1-bionic
adoptopenjdk:11.0.6_10-jre-hotspot-bionic
adoptopenjdk/openjdk11:jre-11.0.6_10-ubuntu
adoptopenjdk/openjdk11:jre-11.0.6_10
adoptopenjdk/openjdk11:jre-11.0.6_10-ubi-minimal
adoptopenjdk/openjdk11:jre-11.0.6_10-ubi
adoptopenjdk/openjdk11:jre-11.0.6_10-debianslim
adoptopenjdk/openjdk11:jre-11.0.6_10-debian
adoptopenjdk/openjdk11:jre-11.0.6_10-centos
adoptopenjdk/openjdk11:jre-11.0.6_10-alpine
adoptopenjdk/openjdk11:x86_64-alpine-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-debian-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-debianslim-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-ubi-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-ubi-minimal-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-centos-jre-11.0.6_10
adoptopenjdk/openjdk11:x86_64-ubuntu-jre-11.0.6_10
mcr.microsoft.com/java/jre:11u6-zulu-alpine
mcr.microsoft.com/java/jre:11u6-zulu-centos
mcr.microsoft.com/java/jre:11u6-zulu-debian8
mcr.microsoft.com/java/jre:11u6-zulu-debian9
mcr.microsoft.com/java/jre:11u6-zulu-debian10
mcr.microsoft.com/java/jre:11u6-zulu-ubuntu
azul/zulu-openjdk-alpine:11.0.6-jre
Results
As you can see
- The Alpine Linux based images are smallest.
- The JRE images are smaller than the JDK images
- The RHEL/CentOS based images are (generally) largest.
- The Microsoft images are generally larger than images with the same OS libraries from other suppliers which have been looked at.
- The difference between the largest and smallest image is about 3 times.
- The slim images, as their name implies, are smaller than their not so slim siblings.
Of course the images, although they all contain the same JDK, differ in functionality. The bigger ones probably have more tools available inside of them. Having a smaller image however, likely also makes it safer to use since there is less inside which can be abused.
