Containerization with Docker
The JAR from Module 18 now becomes a portable, versioned artifact that runs identically anywhere Docker does — the prerequisite for Module 20's Kubernetes deployment.
Learning objectives
- Beginner: Write a Dockerfile that packages a Kafka producer or consumer service as a runnable image.
- Intermediate: Run the same Docker image unmodified against different environments by varying only its configuration.
- Advanced: Publish a versioned image to Docker Hub as part of a repeatable build/release process.
FROM eclipse-temurin:21-jre-alpine WORKDIR /app COPY build/libs/library-events-producer-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]
An image is the immutable, layered result of building this file — each instruction (FROM, COPY) adds a cached layer. A container is a running instance of that image, with its own writable filesystem layer on top and its own process namespace.
💻 Code example
FROM eclipse-temurin:21-jre-alpine WORKDIR /app COPY build/libs/library-events-producer-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]
docker build -t library-events-producer:1.0 . docker run -p 8080:8080 \ -e SPRING_KAFKA_PRODUCER_BOOTSTRAP_SERVERS=host.docker.internal:29092 \ library-events-producer:1.0
▲ Common mistake
--network=host is NOT the answer here, and it's easy to reach for by instinct — it also behaves inconsistently across platforms (Docker Desktop on Mac/Windows runs containers inside a Linux VM, so host networking doesn't mean what it means on native Linux). Standard bridged networking (the default — just -p for port mapping) plus host.docker.internal, a hostname Docker itself resolves to the host machine, is the reliable, cross-platform way for a containerized app to reach a Kafka broker running on your host machine's Docker Compose setup.
💻 Code example
docker build -t library-events-producer:1.0 . docker run -p 8080:8080 \ -e SPRING_KAFKA_PRODUCER_BOOTSTRAP_SERVERS=host.docker.internal:29092 \ library-events-producer:1.0
Directly reusing Module 18's environment-variable override mechanism, the identical image runs against a local broker, a staging cluster, or production — only the env vars change, never the image contents. This is the core promise of containerization: build once, configure per-environment at runtime.
docker run -p 8080:8080 \ -e SPRING_KAFKA_PRODUCER_BOOTSTRAP_SERVERS=kafka-staging:9092 \ library-events-producer:1.0
💻 Code example
docker run -p 8080:8080 \ -e SPRING_KAFKA_PRODUCER_BOOTSTRAP_SERVERS=kafka-staging:9092 \ library-events-producer:1.0
docker tag library-events-producer:1.0 yourorg/library-events-producer:1.0 docker push yourorg/library-events-producer:1.0
Publishing to a registry is what makes the image pullable from anywhere — including a Kubernetes cluster (Module 20), which schedules pods by pulling a named, tagged image, not by copying files from your laptop.
▲ Pitfall
Tagging (or worse, re-pushing) with:latest in anything beyond local experimentation makes deployments non-reproducible — you lose the ability to say precisely which image version is running where, and a rollback has nothing concrete to roll back to. Use immutable, meaningful tags (a version number or commit SHA).
✓ Quick recap
What's the difference between a Docker image and a container? The image is the immutable built template; a container is a running instance of it with its own writable layer. What changes between running the same image locally vs. against staging? Only the environment variables passed at run time — the image itself never changes.
💻 Code example
docker tag library-events-producer:1.0 yourorg/library-events-producer:1.0 docker push yourorg/library-events-producer:1.0
Want a visual for this concept?
Generate a diagram tailored to “Containerization with Docker” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →