Docker: Images, Containers, Multi-Stage

Build in a throwaway JDK stage, ship a slim JRE image with layered dependencies cached below your code, run as non-root, and let MaxRAMPercentage size the heap to the container.

Ship every service's structured logs to one searchable store, and stamp every request with a propagated trace ID so you can reconstruct its whole cross-service journey.

A multi-stage build compiles in a heavy toolchain stage and copies only the finished artifact into a slim runtime stage, so the shipped image contains the app but none of the build tools.

Shrink an image by picking a minimal base, building in multiple stages, keeping layers clean, and using .dockerignore so only the app and its runtime ship.

COPY copies local files exactly as-is, ADD auto-extracts archives and can fetch URLs, so prefer COPY for predictability and reserve ADD for intentional archive extraction.

Scan images for known CVEs with Trivy or Grype and block severe findings before deploy, and never bake secrets into layers; inject them at runtime from a secret manager.

A restarting container is a dying or probe-failing process, so read its previous logs and exit code, check for OOMKilled, check probe configuration, and verify the entrypoint and config.

CrashLoopBackOff is the app crashing after start, ImagePullBackOff is the image not pulling, Pending is the scheduler finding no room, and ContainerCreating is setup in progress, each diagnosed from describe events and logs.

An image is the immutable layered template built once, and a container is a running instance of that image with a thin writable layer on top.

A VM runs a full guest OS on virtualized hardware via a hypervisor for strong isolation, while a container shares the host kernel using namespaces and cgroups for speed and density at the cost of a thinner boundary.