Docker

Docker is a platform for building, shipping, and running applications in containers.

A lightweight isolated process with its own filesystem, network, and runtime settings.

Containers share host kernel; VMs emulate full OS with separate kernels.

Fast startup, portability, efficient resource usage, and consistent environments.

Immutable template containing app code, runtime, libraries, and metadata.

A running (or stopped) instantiation of an image.

Core runtime (daemon + APIs) managing images, containers, networks, and volumes.

Background service (dockerd) handling container lifecycle operations.

Command-line client that talks to Docker daemon API.

Text file with instructions to build a Docker image.

Sets base image for subsequent build steps.

Executes commands at build time, creating image layers.

Copies files from build context into image.

Like COPY plus extra features (URL/tar auto-extract), used more cautiously.

Prefer COPY unless ADD-specific behavior is truly needed.

Sets working directory for subsequent instructions.

Defines default command/args when container starts (overridable).

Defines main executable for container (harder to override semantics).

ENTRYPOINT sets executable; CMD provides default arguments.

Documents intended listening ports (does not publish by itself).

Sets environment variables in image/container.

Defines build-time variables available during image build.

ARG build-time only (unless copied into ENV); ENV available at runtime.

Read-only filesystem delta created by each Dockerfile instruction.

Enable caching, reuse, and smaller incremental image transfers.

Directory/files sent to daemon for image build.

Faster builds and less accidental file leakage.

File listing paths excluded from build context.

Public registry for hosting and distributing container images.

Repository service storing versioned container images.

Human-friendly image version label (e.g., myapp:1.2.0).

Just a tag name, not guaranteed newest unless maintained that way.

Downloads image from registry.

Creates and starts a new container from image.

Lists running containers (= -a= includes stopped).

Gracefully stops running container.

Forcibly terminates container process.

Removes stopped container.

Removes image from local cache.

Publishing container port to host port (e.g., -p 8080:80).

Shows container stdout/stderr logs.

Runs command inside running container.

Runs container in background.

Attaches terminal input/output for interactive sessions.

Assigns stable container name for easier management.

Rules for auto-restarting containers (e.g., unless-stopped).

Mount host path into container.

Managed persistent storage independent from container lifecycle.

Bind uses explicit host path; volume managed by Docker abstraction.

Container writable layer is ephemeral and removed with container.

Bridge network for local container connectivity.

Yes, on user-defined bridge networks via embedded DNS.

Tool for defining/running multi-container applications declaratively.

YAML describing services, networks, volumes, env, and dependencies.

Reproducible local stacks with one command.

Running everything as root with oversized images.

Hardcoding secrets directly in Dockerfile/image.

Minimal base image, non-root user, trusted image sources.

Use build cache, .dockerignore, and multi-stage builds.

Keep images small, explicit, versioned, and reproducible.

Dockerfile pattern using multiple FROM stages to separate build/runtime artifacts.

Smaller final images and reduced attack surface.

Modern Docker build backend with advanced caching and features.

Faster builds, better cache control, secret mounts, parallelism.

Changing one step invalidates cache for subsequent dependent layers.

Place rarely changed steps (deps install) before frequently changed code copy.

Reproducibility and supply-chain safety.

Tags can move; digests are immutable content addresses.

Cryptographically verifying image origin/integrity.

Software Bill of Materials listing components in image.

Vulnerability management and compliance visibility.

Checking image layers/dependencies for known vulnerabilities.

No, but it significantly reduces known exposure.

Common Vulnerabilities and Exposures identifier for disclosed security flaws.

Minimal runtime image without package manager/shell.

Better security/smaller size but harder interactive debugging.

Small size, but musl-based environment may cause compatibility/perf differences for some apps.

Command Docker runs to determine container health.

Enable orchestrators/scripts to detect unhealthy instances.

JSON-array syntax preferred for signal handling and argument safety.

Shell form runs through shell; exec form runs process directly.

PID 1 has special signal/reaping responsibilities.

Small init helps forward signals and reap zombies.

Can alter buffering/signal behavior unexpectedly.

Process return code indicating success/failure cause.

In-memory filesystem mount for ephemeral sensitive/temp data.

Security hardening by preventing writes to image filesystem.

Use writable volumes/tmpfs for required paths.

Fine-grained kernel privileges assignable to containers.

Principle of least privilege reduces exploit impact.

Syscall filtering policy for container processes.

Mandatory access control policies restricting container actions.

Maps container root to non-root host UID range.

Running Docker daemon/containers without root privileges.

Improved security with some networking/storage feature constraints.

Kernel mechanism limiting CPU, memory, I/O resources.

Prevents container from exhausting host memory.

Kernel may kill process/container (OOMKill).

Controls CPU time allocation across containers.

NATed local network for containers on single host.

Container shares host network namespace (less isolation).

Multi-host network abstraction (commonly with orchestrators).

Assign near-native network identity to containers in specific environments.

Docker provides embedded DNS for service/container name resolution on user-defined networks.

Plugin/system enabling different volume backends.

Persists beyond container deletion until explicitly removed.

Unnamed volume created automatically (harder to manage).

Can accumulate orphaned storage.

Removes unused resources (images/containers/networks/build cache, optionally volumes).

Accidental deletion of needed cache/data if used carelessly.

Mechanism for routing container logs (json-file, journald, fluentd, etc.).

Prevent disks filling from unbounded logs.

Live resource usage metrics per container.

Low-level JSON metadata for container/image/network/volume.

Environment-specific extension to base compose config.

Controls startup order, not full service readiness by itself.

Explicitly wait for dependent service availability before start logic.

Using one giant mutable “pet” container instead of immutable rebuilds.

Immutable versioned images + recreate containers from new image.

Build, scan, test, sign, push, deploy with rollback path.

Non-reproducible image creation outside source-controlled Dockerfile.

Single image tag supporting multiple CPU architectures.

Buildx with platform targets and manifest lists.

Team can explain image hardening, cache strategy, and runtime limits.

Logs + inspect + exec + metrics + reproducible local compose.

Assume containers are ephemeral and design statelessly where possible.

Trust but verify images via scanning, signatures, and least privilege.

Optimize image size, build time, and host density.

Standardize Dockerfiles and runtime policies across services.

Balance developer speed with strong supply-chain and runtime controls.

Protecting build sources, dependencies, images, registries, and deployment artifacts.

Attestable build provenance proving how/where artifact was produced.

Same source should yield same artifact for trust and debugging.

Build isolated from uncontrolled external network/state dependencies.

Untrusted cache layers introducing compromised artifacts.

Trusted builders, signed caches, isolated CI, provenance verification.

Move same tested digest through envs (dev→staging→prod) without rebuild.

Avoid tag drift and ensure exact artifact parity.

Running container config/image diverges from declared desired state.

Continuous reconciliation and policy/audit checks.

Automated enforcement of security/compliance rules on Dockerfiles/images/runtime specs.

No root user, pinned base image, no latest tag, resource limits required.

Securely bootstrapping first credential needed to fetch other secrets.

May leak via logs, process listings, crash dumps, or debug endpoints.

External secret manager + short-lived credentials + mounted files/tokens.

Restrict outbound network to necessary destinations only.

Limits data exfiltration and command-and-control channels.

Use hardened seccomp/capability profiles and minimal binaries.

Never patch running containers; rebuild and redeploy new images.

Curated hardened base images reused organization-wide.

Centralized updates can create broad coordinated upgrade needs.

One workload consumes disproportionate resources affecting others.

Resource quotas, isolation classes, scheduling policies, autoscaling.

Higher density improves cost efficiency but may reduce isolation headroom.

Smaller images, lazy loading, pre-pulled layers, fast init paths.

Layered FS adds abstraction costs; workload-dependent performance impact.

Small writes can trigger larger underlying operations.

Use volumes for data paths rather than container writable layer.

Structured logs, centralized aggregation, correlation IDs, retention controls.

Visibility into resource saturation, latency, and dependency behavior.

Treat containers as replaceable units, not manually curated long-lived pets.

Image registry availability, backup of persistent volumes/config/secrets.

Improve pull speed and resilience against upstream outages.

Offline image import/sign/scan/deploy pipelines for restricted environments.

Strong isolation, rootless where possible, strict policies, continuous auditing.

SBOMs, scan reports, signed artifacts, deployment attestations, audit logs.

Inject container crashes/network faults/resource pressure to test resilience.

Common real-world failure modes for container hosts.

Run old/new versions concurrently and switch traffic safely.

Gradually route traffic to new version while monitoring risk indicators.

Fast revert to previous known-good image digest and config.

Orchestrators (Kubernetes/Swarm/etc.) manage container fleets at scale.

Usually orchestration is needed for scheduling, self-healing, and scaling.

Using privileged containers broadly to “make things work.”

It effectively removes many isolation boundaries and increases host compromise risk.

Design for container replacement, failure, and rapid recovery.

Harden every stage: build, registry, runtime, and operations.

Benchmark real workloads; tune images, limits, and storage/network paths empirically.

Standardize policies/templates and enforce continuously in CI/CD.

Docker excellence is reproducible, secure, observable, and operable container delivery at scale.

# Build stage
FROM eclipse-temurin:21-jdk AS build
WORKDIR /app
COPY . .
RUN ./mvnw -q -DskipTests package

# Runtime stage
FROM eclipse-temurin:21-jre
WORKDIR /app

# Create non-root user
RUN useradd -r -u 10001 appuser
USER 10001

COPY --from=build /app/target/*.jar app.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]