1. Concept library
  2. Java & Spring Boot
  3. Module 13: Observability and deployment

Concept

Containerising with Docker

A container image bundles the JVM, your jar and its configuration so it runs identically everywhere. A multi-stage Dockerfile builds in one stage and ships only the runtime in the other.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

  1. Explain what a container image bundles and why it runs the same everywhere
  2. Write a multi-stage Dockerfile for a Spring Boot jar
  3. Spot the JDK runtime image and the root user

In practice

A few lines that show Containerising with Docker doing its job.

dockerfile
FROM eclipse-temurin:21-jdk AS build
WORKDIR /src
COPY . .
RUN ./mvnw -q package -DskipTests

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /src/target/*.jar app.jar
USER 1000
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]

The common mistake

Watch for

Shipping the JDK build image as the runtime, or running as root. The image is hundreds of megabytes larger than it needs to be, and a compromise in the container has root.

What to know first

Your roadmap puts these before Containerising with Docker, unless you already know them.

How it stays learned

Once a session shows you understand Containerising with Docker, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

  1. Day 3First recall, while it is fresh
  2. Day 7Second, a week on
  3. Day 18Last, when it has settled

Where it leads

Topics that build on Containerising with Docker.

Previous in the module← Actuator and metrics