ENTRYPOINT vs CMD, and ARG vs ENV

Real-life example for CMD vs ENTRYPOINT: CMD is like a restaurant's 'suggested side dish' — the kitchen serves it by default, but you can ask for a different one instead. ENTRYPOINT is like the restaurant's actual cooking process — you can add ingredients (arguments) to it, but you can't tell the kitchen to stop cooking and do something completely unrelated without a special request.

CMD ["java", "-jar", "app.jar"] sets the DEFAULT command — docker run myimage runs exactly that, but docker run myimage --help REPLACES the entire CMD with --help, which is almost never what you want for an app image (it's ideal for a general-purpose image like python or ubuntu where the whole point IS letting the caller choose what to run).

ENTRYPOINT ["java", "-jar", "app.jar"] sets the process that ALWAYS runs — docker run myimage --spring.profiles.active=prod does NOT replace it; the extra text is APPENDED as arguments to the entrypoint instead, becoming java -jar app.jar --spring.profiles.active=prod. This is the right choice for an image that has exactly one job.

The genuinely powerful pattern combines both: ENTRYPOINT fixes the unchangeable command, CMD supplies DEFAULT arguments to it that a caller can still override — ENTRYPOINT ["java", "-jar", "app.jar"] plus CMD ["--spring.profiles.active=default"] means docker run myimage uses the default profile, while docker run myimage --spring.profiles.active=prod swaps in a different profile, and the underlying java -jar app.jar invocation itself can never be accidentally dropped.

Overriding a container's ENTRYPOINT entirely (rather than just its CMD arguments) IS still possible, deliberately, with the explicit --entrypoint flag — e.g. docker run --entrypoint bash myimage to get a shell inside an image that would normally always launch your app. This is the standard trick for debugging an image whose ENTRYPOINT would otherwise never let you in.

ARG defines a variable available ONLY during the image BUILD (inside the Dockerfile, resolved by docker build --build-arg KEY=value) — it does not exist in the final running container at all unless you deliberately copy its value into an ENV instruction. Use it for things like choosing a base image variant or a version number at build time.

ENV defines a variable that's baked into the image AND remains set in every container run from it — visible to your application at runtime via normal environment variable lookups (System.getenv("KEY") in Java). Use it for actual runtime configuration, like SPRING_PROFILES_ACTIVE.

A common, useful combination: ARG APP_VERSION (supplied at build time by your CI pipeline) followed by ENV APP_VERSION=$APP_VERSION — this takes a BUILD-time-only value and deliberately promotes it into a RUNTIME-visible one, so your running app can report its own version, something a bare ARG could never do.