How does a typical Docker workflow look for a Spring Boot application?

Direct Answer

Build your Spring Boot JAR with ./mvnw test && ./mvnw package, write a Dockerfile specifying the base JDK image and startup command, build the Docker image with docker build, test locally with docker run, then push to a registry like Docker Hub with docker push for deployment to staging or production.

Code Example

// Step 1: Build the Spring Boot JAR
// Command: ./mvnw test && ./mvnw package -DskipTests
// Output: target/customer-service-1.0.0.jar

// Step 2: Create Dockerfile
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/customer-service-1.0.0.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

// Step 3: Build the Docker image
// Command: docker build -t customer-service:1.0 .
// Tags the image as customer-service version 1.0

// Step 4: Test locally
// Command: docker run -p 8080:8080 customer-service:1.0
// Maps container port 8080 to host port 8080
// Test: curl http://localhost:8080/customers

// Step 5: Push to registry
// docker tag customer-service:1.0 myuser/customer-service:1.0
// docker push myuser/customer-service:1.0
// Now available for deployment anywhere

Common Mistakes & Pitfalls

• Building the Docker image before the JAR: Freshers write the Dockerfile and run docker build before running mvn package, so the COPY instruction fails because the JAR doesn't exist yet. Always compile first.
• Including unnecessary files in the image: Using COPY . /app copies your entire project—source code, .git folder, IDE configs—into the image. Only copy the JAR. Use a .dockerignore file to exclude everything except the target directory.
• Forgetting to expose the port: If your Dockerfile doesn't have EXPOSE 8080 and you don't map ports with -p when running, you can't reach the application from outside the container. The app runs but is inaccessible.