Docker images - types. Slim vs slim-stretch vs stretch vs alpine

I am looking to pick up a docker image to build a java app and looking at the variants of the OpenJDK images available. I am looking here https://github.com/docker-library/openjdk/tree/master/8/jdk and see alpine, slim and windows. What are the differences between these and what does each variant give?

Per docker library docs (quote and links below), here's a summary:

• openjdk:<version>

The defacto image. Use it if unsure.

• openjdk:<version>-buster, openjdk:<version>-stretch and openjdk:<version>-jessie

buster, jessie or stretch are the suite code names for releases of Debian and indicate which release the image is based on.

• openjdk:<version>-alpine

Similarly, this image is based on the Alpine Linux, thus being a very small base image. It is recommended if you need an image size is as small as possible. The caveat is that it uses some unusual libs, but shouldn't be a problem for most software. In doubt, check the official docs below.

• openjdk:<version> (from 12 onwards), openjdk:<version>-oracle and openjdk:<version>-oraclelinux7

Starting with openjdk:12 the default image as well as the -oracle and -oraclelinux7 variants are based on the official Oracle Linux 7 image. The OpenJDK binaries in the default image as well as the -oracle and -oraclelinux7 variants are built by Oracle and are sourced from the OpenJDK community.

• openjdk:<version>-slim

This image only contains the minimal packages needed to run Java (and is missing many of the UI-related Java libraries, for instance). Unless you are working in an environment where only the openjdk image will be deployed and you have space constraints, the default image is recommended over this one.

• openjdk:<version>-windowsservercore

This image is based on Windows Server Core (microsoft/windowsservercore).

Full docs (version shown below here, latest version here):

Image Variants

The openjdk images come in many flavors, each designed for a specific use case.

openjdk:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.

Some of these tags may have names like jessie or stretch in them. These are the suite code names for releases of Debian and indicate which release the image is based on.

openjdk:<version>-alpine

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

openjdk:<version>-windowsservercore

This image is based on Windows Server Core (microsoft/windowsservercore). As such, it only works in places which that image does, such as Windows 10 Professional/Enterprise (Anniversary Edition) or Windows Server 2016.

For information about how to get Docker running on Windows, please see the relevant "Quick Start" guide provided by Microsoft:

• Windows Server Quick Start
• Windows 10 Quick Start

openjdk:<version>-slim

This image installs the -headless package of OpenJDK and so is missing many of the UI-related Java libraries and some common packages contained in the default tag. It only contains the minimal packages needed to run Java. Unless you are working in an environment where only the openjdk image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

Choose a base docker image that fits your needs and please keep in mind that Image size is an important aspect also.

Image can be considered as a set of instructions on how to create the container. In Docker, one image could be inherited from (or based on) another image, adding additional instructions on top of base ones. Each image consists of multiple layers, which are effectively immutable.

Plase read Crafting the perfect Java Docker build flow article.

Docker image size is actually very important. The size has an impact on:

• network latency: need to transfer Docker image over the web
• storage: need to store all these bits somewhere
• service availability and elasticity: when using a Docker scheduler, like Kubernetes, Swarm, Nomad, DC/OS or other (the scheduler can move containers between hosts)
• security: do you really, I mean really need the libpng package with all its CVE vulnerabilities for your Java application?
• development agility: small Docker images == faster build time and faster deployment

To run a java application you need JRE at least. For example, for a spring project your image can be based on slim Alpine Linux with OpenJDK JRE:

#simple dockerFile for java app:

#here we are using Base Alpine Linux based image with OpenJDK JRE only
#For Java 8, try this
FROM openjdk:8-jre-alpine

#For Java 11, try this
#FROM adoptopenjdk/openjdk11:alpine-jre

#copy application WAR/JAR (with libraries inside)
COPY target/spring-boot-*.war/jar yourName.war/jar
# specify default command
CMD ["/usr/bin/java", "-jar", "/yourName.war/jar"]

Also you can use docker history yourImageName to see all layers (and their size) that makes your image.