Why this matters
- This topic directly affects how reliably BookStore reaches production — multi-stage builds separate maven compile from slim jre runtime images for bookstore..
- Interviewers connect hands-on commands and manifests to real delivery stories, not buzzwords.
- Later modules assume you can explain both the why and the concrete file or command involved.
- Platform maturity shows up when teams automate this instead of relying on tribal knowledge.
Changing Layer 3 invalidates cache for layers 3 and 4 only
Build stage
Maven in builder image: BookStore engineers treat this as part of the standard path from laptop to multi stage docker builds readiness. Document decisions in the team runbook so on-call knows which knobs exist.
Key ideas
- Build stage — primary idea for multi-stage-docker-builds
- BookStore context — catalog API, checkout, and inventory services share the same pattern
- Automation — prefer pipeline jobs over manual SSH steps
- Verification — staging must prove the change before prod traffic
Runtime stage
Slim JRE artefact only: When staging matches production architecture, BookStore catches misconfigurations early. Pair this section's practice with observability dashboards to confirm behavior under load.
Key ideas
- Runtime stage — operational detail
- Rollback — know how to revert without rebuilding artefacts
- Security — least privilege for deploy roles
- Documentation — link runbooks from the service README
Production checklist
Before promoting BookStore changes tied to this topic, run automated tests, inspect artefact immutability (image digest or JAR checksum), execute a staging smoke test on /actuator/health, and watch error-rate dashboards for thirty minutes after prod rollout.
Key ideas
- Staging soak — validate under synthetic load
- Change ticket — attach pipeline URL and artefact digest
- On-call — page owner stays on dashboards during rollout
- Post-deploy — record metrics baseline for comparison
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom.xml .
COPY src ./src
RUN mvn -q -DskipTests package
FROM eclipse-temurin:21-jre-alpine
COPY --from=build /src/target/bookstore-api.jar /app/app.jar
Spring Boot trackAlready containerised BookStore in Spring Boot? Compare with this deeper multi-stage pattern
Quick recall
Everything you need if you only revisit this box.
- BookStore uses multi stage docker builds as a standard delivery practice.
- Prefer automation and versioned config over manual server changes.
- Staging proves changes before customer-facing promotion.
- Observability confirms success — do not rely on silence alone.
- Rollback plans must be tested, not invented during an outage.
- Security and least privilege apply to every pipeline and cluster role.
Test yourself
Answer these before moving on — recall is what makes it stick.