This note based on the presentation of eldermoraes.
https://www.youtube.com/watch?v=R4kxLsXkAE4.
- Long build time
- Huge image size
- Hard maintainability
- Resource allocation
If we put changing layers at the top of the docker file and change these layers, it triggers to rebuild all the bottom layers that not been changed.
Bad practice:
COPY lib/* /deployment/lib/
COPY sample-runner.jar /deployment/
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk ssh vim
Best practice:
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk ssh vim
COPY lib/* /deployment/lib/
COPY sample-runner.jar /deployment/
Order of commands in the docker file is the matters!
Try to don't use the wildcard copy command because if you create a file in the directory with the target file, the cache will be broken.
Bad practice:
COPY *-runner.jar /deployment/
Best practice:
COPY sample-runner.jar /deployment/app.jar
Instead of having a list of commands, try to group your commands. It reduces cache size, images size and layers count.
Bad practice:
RUN apt-get update
RUN apt-get -y install openjdk-8-jdk ssh vim
Best practice:
RUN apt-get update \
&& apt-get -y install \
openjdk-8-jdk ssh vim
Don't install not necessary staff into your container.
Bad practice:
RUN apt-get -y install openjdk-8-jdk
Best practice:
RUN apt-get -y install --no-install-recommends openjdk-8-jdk
For apt-get command use rm -rf /var/lib/apt/lists/*
command.
Bad practice:
RUN apt-get update \
&& apt-get -y install --no-install-recommends openjdk-8-jdk
Best practice:
RUN apt-get update \
&& apt-get -y install --no-install-recommends openjdk-8-jdk
&& rm -rf /var/lib/apt/lists/*
No need to use the Debian base image if you deploy your java application. Use the official language/framework image (like openjdk-alpine).
Bad practice:
FROM debian:stretch
Best practice:
FROM openjdk
It didn't break your build and deploy in the case when the base image will be updated.
Bad practice:
FROM openjdk
Best practice:
FROM openjdk:8
Bad practice:
FROM openjdk:8
Best practice:
FROM openjdk:8-jre-alpine
Before Java 8u121 Java didn't know about process cgroups, therefore Java application didn't know about resource limitations.
It's not recommended to use Java version before 8u121 in the container environment.