Module 18: Testing, Delivery, and Runtime Operations
Docker Images and Java Containerization
Containerize Java applications in a way that supports repeatable builds, reasonable image size, and predictable runtime behavior. You will cover Dockerfiles, multi-stage builds, configuration, and the difference between packaging an app and operating it safely.
Author
Java Learner Editorial Team
Reviewer
Technical review by Java Learner
Last reviewed
2026-04-17
Java version
Java 25 LTS
Learning goals
- Build a container image that packages the application cleanly
- Use multi-stage builds and layering ideas to keep images practical
- Pass runtime configuration into the container without hard-coding it into the image
Before you start
- You are comfortable building multi-class Java applications and reading project structure
Lesson roadmap: Start with the mental model, then follow the design choices, common pitfalls, and the practical workflow you should apply in a real project.
Containers package the application and its runtime environment in a repeatable form: That reduces “works on my machine” problems.
A Dockerfile defines how the image is built: It usually includes a base image, copied artifacts, and a startup command.
Multi-stage builds are especially useful for Java projects: One stage can build the app, and a later stage can run it in a smaller runtime image.
Operational mindset: Containerization is about repeatability and deployment consistency, not just about local convenience.
Container mindset: A container image is a repeatable runtime package. It should describe exactly what is needed to run the application, not inherit random state from one developer machine.
Multi-stage builds help: One stage can compile the app, while a later stage contains only what is needed to run it. That usually makes images smaller and clearer.
Runtime config stays external: Ports, database URLs, credentials, and environment-specific values should be supplied at run or deploy time, not baked into the image.
Operational concerns: Logging, health checks, startup time, and exposed ports matter just as much as “the container starts.”
How to study this module: Treat every tool here as part of one delivery pipeline. Tests, builds, containers, and CI are not separate checkboxes; together they decide whether other people can trust your code.
Code review mindset: Good engineering workflow reduces risk. Reviewers look for repeatable builds, focused tests, useful failure messages, and deploy steps that are automated rather than tribal knowledge.
Production habit: Make the safe path the default path. The easier it is to run tests, build images, and verify changes, the more often the team will actually do it.
Runnable examples
A runtime image starts from a built jar
FROM eclipse-temurin:25-jre
COPY app.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]Expected output
The container starts the Java application with a known runtime image.
A two-stage Dockerfile separates build and runtime
FROM eclipse-temurin:25-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw package -DskipTests
FROM eclipse-temurin:25-jre
WORKDIR /app
COPY --from=build /app/target/app.jar app.jar
ENTRYPOINT ["java","-jar","app.jar"]Expected output
The final image contains the runnable artifact without carrying the full build toolchain.
Common mistakes
Copying local build artifacts or secrets into the image casually
Build the image from a controlled context and keep sensitive configuration external.
Treating “it runs in Docker” as the end of the story
Also consider logs, health, environment variables, resource limits, and deployment workflow.
Mini exercise
Write a Docker plan for a Spring Boot jar: base image, working directory, jar copy step, entrypoint, and two environment variables you would pass at runtime instead of hard-coding.
Summary
- Containers improve environment consistency.
- Dockerfiles describe how app images are built and started.
- Multi-stage builds keep runtime images smaller and cleaner.
- Good containerization is about repeatability and runtime clarity, not just packaging.
- Multi-stage builds and externalized config are strong default habits.
Next step
Finish the module by automating code quality checks and deployment flow in CI/CD.
Sources used