Phase 6Intermediate7 of 11 in Docker

Dockerizing Java & Spring Boot

Everything from Phases 1-5, applied specifically to the JVM's quirks and Spring Boot's conventions.

The JVM was designed decades before containers existed and has memory/CPU defaults that assume it owns the whole machine. This phase is entirely about the gap between 'a Dockerfile that runs a JAR' and 'a Dockerfile that runs a JAR correctly inside a resource-constrained container.'

0/4 · 0%

4 topics ~54 min 6 code blocks & diagrams

Start with the first topic

6.1

Multi-Stage Builds for Maven/Gradle

Compile your app INSIDE Docker (so nobody needs Maven/Java installed locally to build it) while keeping the final shipped image free of the entire build toolchain.

14 min 1 diagram 1 code practice

6.2

The JVM Doesn't Know It's in a Container (Unless You Tell It)

For years, the JVM sized its default heap based on the HOST machine's total memory, even when running inside a container with a much smaller limit — this single fact has caused more production container crashes than almost any other Java-specific Docker issue.

14 min 1 code practice

6.3

Spring Boot's Built-In Docker Support

Spring Boot has native, first-class Docker tooling built directly into Maven/Gradle — you don't always need to hand-write a Dockerfile at all.

13 min 2 code practice

6.4

Testcontainers: Real Dependencies in Your JUnit Tests

Everything in this course so far runs Docker containers for an APP — Testcontainers runs them for your TEST SUITE, giving JUnit tests a real Postgres/Kafka/Redis instead of a mock, then throwing it away when the test finishes.

13 min 1 code practice

Command Palette

Multi-Stage Builds for Maven/Gradle

The JVM Doesn't Know It's in a Container (Unless You Tell It)

Spring Boot's Built-In Docker Support

Testcontainers: Real Dependencies in Your JUnit Tests