121 Docker Interview Questions and Answers (2026)

An image is a read-only template (a blueprint) packaging your app and its dependencies; a container is a running (or stopped) instance created from that image with a writable layer on top.

• Image: immutable, layered artifact:

  • Built from a Dockerfile, stored in a registry, shareable and versioned by tags/digests.

  • Composed of stacked read-only layers.

• Container: a runtime instance of an image:

  • Adds a thin writable layer on top of the image's read-only layers.

  • Has its own process, network namespace, and filesystem view.

• Analogy: image is to container as a class is to an object, or a program on disk to a running process.

• One image, many containers: you can launch many independent containers from a single image.

Docker packages the application together with its entire runtime environment (libraries, dependencies, config) into one image, so the same artifact runs identically on a laptop, CI, and production. The environment travels with the app instead of being assumed to exist on the host.

• The root cause of the problem: Different machines have different OS libs, language versions, and config, so code behaves differently.

• Docker's fix: ship the environment, not just the code:

  • The image bundles dependencies and a pinned base OS layer.

  • Isolation via namespaces/cgroups means the container barely relies on host specifics.

• Same artifact everywhere: The exact image built and tested in CI is the one that runs in prod (by digest).

• The one host dependency: Only a compatible container runtime/kernel is needed, not the app's dependency tree.

A Docker image is a stack of read-only layers, each produced by one instruction in the Dockerfile; the build cache reuses a layer if its instruction and inputs are unchanged, so only the first altered layer and everything after it are rebuilt.

• Layers are stacked and immutable: Each RUN, COPY, ADD creates a layer; the union filesystem presents them as one merged view, and a thin writable layer is added at container runtime.

• Cache keys per instruction: Docker hashes the instruction text plus its context (for COPY/ADD, the file contents/checksums) to decide if a cached layer is valid.

• Cache invalidation cascades: Once one layer misses, every layer after it is rebuilt, since each depends on the parent's state.

• Ordering matters for build speed: Put rarely-changing steps first (install deps) and frequently-changing steps last (copy source) so the cache survives most edits.

A VM virtualizes hardware and runs a full guest OS with its own kernel via a hypervisor, while a container virtualizes the OS: it shares the host kernel and isolates only the process and its userspace, which makes containers far lighter.

• Virtual Machine: Hypervisor runs multiple guest OSes, each with its own kernel and virtual hardware; strong isolation but heavy (GBs, slow boot).

• Container: A isolated process on the host kernel, bounded by Linux namespaces (what it can see) and cgroups (what it can use); packages just app + userspace.

• Why containers are lightweight:

  • No guest OS/kernel to boot, so they start in milliseconds and are measured in MBs.

  • Higher density: many containers share one kernel, so more fit per host than VMs.

• Trade-off: Shared kernel means weaker isolation than a VM, and containers can't run a different OS kernel than the host.

Docker uses a client-server architecture: the Client sends commands, the Daemon (dockerd) does the actual work of building and running containers, and the Registry stores and distributes images.

• Docker Client:

  • The CLI (docker) you type into; translates commands into REST API calls.

  • Talks to the daemon over a Unix socket or TCP, so it can be local or remote.

• Docker Daemon (dockerd):

  • A long-running background process that manages images, containers, networks, and volumes.

  • Listens on the Docker API and delegates running containers to containerd.

• Registry:

  • A store for images (e.g. Docker Hub, or a private registry); the daemon pulls from and pushes to it.

  • Referenced by docker pull / docker push.

WORKDIR sets the working directory for subsequent instructions (RUN, CMD, COPY, ENTRYPOINT), creating it if needed. It is preferred over RUN cd because the directory change actually persists across layers.

• Why RUN cd fails: Each RUN is a separate shell/layer, so a cd in one is lost by the next.

• What WORKDIR gives you:

  • A persistent, declarative current directory for all following instructions.

  • Auto-creates the path and supports relative chaining across multiple WORKDIR lines.

  • More readable and less error-prone than repeated absolute paths.

LABEL adds key-value metadata to an image. It doesn't affect runtime behavior but is invaluable for documentation, automation, and tooling that inspects images.

• Purpose: Attaches descriptive info queryable via docker inspect and filterable with docker images --filter.

• Common metadata:

  • Maintainer/author, version, description, source repo, license, build date.

  • Prefer the OCI standard keys like org.opencontainers.image.source and org.opencontainers.image.version.

• Best practice: Combine multiple labels into one instruction to avoid extra layers.

A .dockerignore file lists paths excluded from the build context sent to the Docker daemon. It keeps unnecessary files out of the build, which speeds up builds and prevents bloating or leaking sensitive data into images.

• What it controls:

  • Before building, the CLI packages the context and ships it to the daemon; ignored patterns are never sent.

  • Uses glob patterns similar to .gitignore, e.g. node_modules, .git, *.log.

• Impact on build performance:

  • Smaller context transfers faster to the daemon, especially with large local dirs.

  • Prevents cache busting: excluding volatile files means COPY . . won't invalidate cache on unrelated changes.

• Security benefit: Stops secrets like .env or credential files from accidentally landing in the image.

Restart policies tell the Docker daemon whether and when to automatically restart a container after it exits or the daemon restarts. You set them with --restart on docker run (or restart: in Compose).

• no: The default: never restart automatically, whatever the exit reason.

• on-failure[:N]: Restart only if the container exits with a non-zero code; optional :N caps the number of retries.

• always:

  • Restart regardless of exit code, and also start the container when the daemon starts.

  • Even a manual docker stop is overridden on daemon restart (it will come back up).

• unless-stopped: Like always, but if you manually stopped it, it stays stopped across daemon restarts.

• Key nuance: Restarts use an exponential backoff delay, and the policy applies to the daemon, not orchestrators like Kubernetes which manage restarts themselves.

Attached mode ties your terminal to the container's process so you see its output (and can send input); detached mode runs it in the background and returns you to your shell. It's about whether your terminal is connected to the container's streams.

• Attached (default):

  • Your terminal is connected to the container's STDOUT/STDERR; logs stream live.

  • Ctrl+C sends a signal to the process, typically stopping it.

• Detached (-d):

  • Container runs in the background; the command prints the ID and returns immediately.

  • View output later with docker logs and reconnect with docker attach.

• Rule of thumb: Attached for short-lived / debugging runs; detached for long-running services.

They are independent flags often combined as -it: -i keeps STDIN open so you can send input, and -t allocates a pseudo-TTY so the session behaves like a real terminal.

• -i (interactive):

  • Keeps STDIN open so you can type or pipe data into the process.

  • Without it, the process gets EOF on stdin immediately.

• -t (TTY):

  • Allocates a pseudo-terminal, giving line editing, prompts, colors, and job control.

  • Alone it looks like a terminal but you can't reliably send input.

• Combinations:

  • -it = an interactive shell for humans.

  • -i alone = piping data in scripts (echo hi | docker run -i ...); no TTY so output isn't mangled.

Use -it when a human needs to interact with the process (a shell, a REPL, a prompt); use -d when the container is a long-running service you want in the background. They serve opposite purposes and are rarely combined meaningfully.

• Interactive -it:

  • Debugging or exploring: docker run -it ubuntu bash.

  • Running CLIs, migrations, or anything that prompts for input.

• Detached -d:

  • Web servers, databases, workers: things that should keep running after you close the terminal.

  • Monitor via docker logs, docker exec, and health checks.

• Combining them: -dit keeps a container alive with a TTY in the background (e.g. a base image whose command would otherwise exit) so you can exec in later.

A Dockerfile defines how to build a single image; Docker Compose defines and runs a multi-container application from existing or built images. They're complementary: Compose orchestrates containers, and a Dockerfile builds one of the images it uses.

• Dockerfile:

  • A build recipe: base image, dependencies, code, and the run command for one image.

  • Produces an artifact via docker build.

• Compose (docker-compose.yml):

  • Declares multiple services, networks, and volumes, then runs them together with docker compose up.

  • Can reference a Dockerfile via build: or a prebuilt image via image:.

• Primary developer use case:

  • Spin up a whole local stack (app + database + cache) with one command, reproducibly.

  • Auto-creates a shared network so services reach each other by name.

Compose offers several ways to inject env vars into a service: inline environment, an env_file of key/value pairs passed into the container, and the special .env file used for variable substitution in the Compose file itself.

• Inline environment: List or map of vars set directly in the container; can reference host vars.

• env_file:

  • Points to a file of KEY=VALUE lines loaded into the container's environment at runtime.

  • Values here do NOT do substitution inside the Compose file; they go into the process.

• The .env file (special):

  • Auto-loaded from the project directory and used to substitute ${VAR} placeholders in the Compose YAML itself (e.g. image tags, ports).

  • It does not automatically pass those vars into containers unless you reference them.

• Precedence: inline environment overrides env_file; shell/host vars override .env for substitution.

A fully qualified image name is registry/repository:tag (or @digest), where each part identifies the host, the image path, and the specific version.

• Registry (host): The server hosting the image (e.g. registry-1.docker.io, ghcr.io); defaults to Docker Hub if omitted.

• Repository: The namespace plus image name (e.g. library/nginx or grafana/grafana); official images use the implicit library namespace.

• Tag or digest: A tag is a mutable label after : (defaults to latest); a digest after @sha256: is an immutable content hash.

• Docker fills in defaults: nginx expands to docker.io/library/nginx:latest.

Use the targeted prune commands per resource type, or docker system prune for a broad sweep, being careful about the -a and volume flags since they delete more aggressively.

• By resource:

  1. docker container prune: removes all stopped containers.

  2. docker image prune: removes dangling images (-a removes all unused).

  3. docker volume prune: removes unused volumes (careful: can be real data).

  4. docker network prune: removes unused networks.

• All at once:

  • docker system prune clears stopped containers, dangling images, unused networks, and build cache.

  • Add -a --volumes to also remove all unused images and volumes.

• Safety: Volumes hold persistent data: prune them only when you're sure, and prefer filters like --filter until=24h in automation.

docker stats streams a live, top-like view of per-container resource usage, letting you spot memory leaks, CPU hogs, or throttling in real time.

• Metrics shown:

  • CPU %, memory usage/limit and memory %.

  • Network I/O and block (disk) I/O totals.

  • PIDs: number of processes/threads in the container.

• Behavior:

  • Live-updating by default; use --no-stream for a single snapshot.

  • Shows all running containers, or specific ones by name/ID.

  • Format output with --format for scripting.

• Use case: Quick runtime diagnostics; for historical data use a real monitoring stack (cAdvisor, Prometheus).

docker inspect returns the full low-level configuration and state of a container or image as JSON, the authoritative source for how an object was created and how it's currently running.

• For a container:

  • State (running, exit code, PID, start time), restart policy, and health status.

  • Network settings: IP address, ports, attached networks.

  • Mounts (volumes/binds), environment variables, entrypoint/cmd, and resource limits.

• For an image: Layers, architecture/OS, default config (env, cmd, exposed ports), and creation history metadata.

• Targeted queries: Use --format with Go templates to extract a single field for scripting.

docker cp copies files and directories between the host filesystem and a container's filesystem (in either direction), letting you move data without rebuilding an image or mounting a volume.

• Bidirectional copy:

  • Host to container: docker cp ./config.yml mycontainer:/app/config.yml

  • Container to host: docker cp mycontainer:/var/log/app.log ./

• Works on stopped containers too: Useful to extract artifacts or logs from a crashed container that won't start.

• Common use cases:

  • Grabbing logs, dumps, or generated files for debugging.

  • Quick one-off config injection during development or troubleshooting.

• Caveat: it's a manual, imperative action, not a reproducible one: Files copied in are lost on container recreation. For persistent or repeatable data use volumes or COPY in the Dockerfile.

docker logs fetches whatever a container wrote to stdout and stderr, as captured by the logging driver, and prints it. It only works when the driver stores logs locally (json-file or local).

• How it works:

  • Reads the log files the driver wrote for that container ID.

  • Useful flags: -f to follow live, --tail for the last N lines, --since/--until for time ranges.

• Limitations in production:

  • Only captures stdout/stderr: apps that log to a file inside the container show nothing.

  • Unbounded growth: without rotation the JSON files can fill the disk over a long-running container's life.

  • Ephemeral: logs are tied to the container and are gone when it's removed.

  • No aggregation or search: single-container, single-host only, no querying across a fleet.

  • Doesn't work with remote drivers like syslog or fluentd.

• Takeaway: Fine for debugging; production needs centralized logging plus rotation.

docker top displays the processes running inside a container, similar to the ps command, but resolved from the host's perspective.

• What it shows:

  • The processes in the container's PID namespace, with columns like PID, user, and command.

  • Accepts ps-style options to customize the columns.

• Why it's useful:

  • Inspect what's actually running without needing ps installed inside the (possibly minimal) image.

  • Confirm the expected process is PID 1 and spot rogue or extra processes.

• Key detail: host PIDs: The PIDs shown are the host-level PIDs, which differ from the PIDs seen inside the container's namespace.

Immutable infrastructure means servers/components are never modified in place: to change something you build a new versioned image and replace the running instance. Docker makes this natural because the image is the fixed, versioned unit of deployment.

• Images are immutable, versioned artifacts:

  • Tagged/digested so a given version always produces the same runtime.

  • Changes mean rebuild and redeploy, not SSH-in-and-patch.

• Replace, don't mutate:

  • Deploy = stop old container, start new one from the new image.

  • Rollback = redeploy the previous image tag.

• Eliminates configuration drift: No accumulated ad-hoc changes across servers; every instance is identical.

• State lives outside: Persistent data goes in volumes or external stores so throwaway containers stay disposable.

Immutability means a container's image content never changes after build; statelessness means the container holds no important data that must survive its lifecycle. Together they make containers interchangeable and disposable.

• Immutability:

  • The underlying image layers are read-only and fixed by version.

  • You change behavior by rebuilding the image, not editing a running container.

• Statelessness:

  • The container keeps no unique data locally that you'd be sad to lose.

  • Any state (DB rows, uploads, sessions) is externalized to volumes, databases, or caches.

• Why it matters:

  • Enables horizontal scaling: spin up N identical replicas behind a load balancer.

  • Enables safe restarts, self-healing, and clean rollbacks.

• Caveat: containers can write locally, but that data is ephemeral, so stateless design treats it as disposable.

An immutable container is one whose contents you never modify after it starts: to update, you deploy a fresh container from a new image rather than patching the running one. This predictability is what makes automated scaling and deployments reliable.

• What 'immutable' means in practice:

  • No in-place patches, config edits, or manual hotfixes on a live container.

  • Every instance from image v1.2 is byte-for-byte the same runtime.

• Why it helps scaling:

  • Replicas are identical and interchangeable, so a load balancer can add/remove them freely.

  • No snowflake instance that behaves differently under load.

• Why it helps deployments:

  • Enables blue-green and rolling updates: bring up new image, shift traffic, retire old.

  • Rollback is just redeploying a previous, known-good image tag.

  • Reproducible: what you tested is exactly what runs.

• Requirement: keep state external (volumes/DBs) so replacing a container loses nothing.

Data written inside a container lives in its writable layer, which is destroyed when the container is removed, so that data is lost. It's called ephemeral because its lifetime is tied to the container, not persisted independently.

• Where writes go: Into the thin writable (CoW) layer on top of the read-only image layers.

• What deletion does:

  • docker rm removes the container and its writable layer, discarding any data there.

  • Note: stopping/restarting a container keeps the layer; only removal destroys it.

• Why 'ephemeral': The data's existence is bound to a disposable, replaceable container instance.

• How to persist data: Use volumes or bind mounts, which live outside the writable layer and survive removal.

Use docker history <image> to list each layer with the instruction that created it, its size, and age: it helps you find bloat, understand cache behavior, and audit what went into an image.

• What it shows: One row per layer, with CREATED BY (the Dockerfile command) and SIZE; add --no-trunc to see full commands.

• Why you'd want it:

  • Spot the fat layers to optimize image size.

  • Understand which step busts the cache during builds.

  • Audit provenance: verify what commands built an image you didn't create.

• Caveat: Layers marked <missing> are intermediate layers whose metadata isn't held locally (common for pulled images).

An image digest is a content-addressable SHA-256 hash of the image's manifest, so it uniquely and immutably identifies exact content; a tag is a mutable, human-friendly label that can be moved to point at different images over time.

• Digest is immutable: Written as repo@sha256:...; if the content changes, the digest changes, so it always resolves to identical bytes.

• Tag is mutable: A name like nginx:1.25 or latest can be re-pushed to point at new content anytime.

• Why it matters: Pinning by digest guarantees reproducible, tamper-evident deploys, whereas pinning by tag can silently pull a different image.

They're related but not identical: the parent image is whatever image your Dockerfile's FROM line directly builds on, while the base image is the root of the chain that started from scratch (no parent).

• Parent image: The immediate image referenced in FROM; your layers stack on top of it.

• Base image: An image built with FROM scratch (an empty starting point), so it has no parent of its own.

• How they relate: If your FROM is itself a minimal image like alpine (built from scratch), then it's both your parent and the base of the chain; the terms are often used loosely as synonyms.

A dangling image is an untagged, unreferenced image layer, shown as <none>:<none>; it typically appears when a rebuild moves a tag to a new image, leaving the old one nameless but still on disk.

• Why it happens in development: Rebuilding with the same tag (e.g. myapp:latest) reassigns that tag to the new image, orphaning the previous one.

• Why it matters: Dangling images accumulate and waste disk space, though they're not automatically referenced by anything.

• Cleanup: Remove them with docker image prune (dangling only) or list them with docker images -f dangling=true.

When you run docker run nginx, the Client sends the request to the Daemon over the API; the Daemon checks for the image locally, pulls it from the Registry if missing, then creates and starts the container.

• Step by step:

  1. The Client (docker) turns the command into a REST call and sends it to dockerd via the socket.

  2. The Daemon looks for the image in its local cache.

  3. If not present, the Daemon pulls the image layers from the Registry (e.g. Docker Hub).

  4. The Daemon (through containerd and runc) creates a container from the image and starts its process.

  5. The Daemon streams output/logs back to the Client.

• Key point: The Client does no container work itself: it's a thin frontend, and the Registry is only contacted on a cache miss (or explicit pull).

On Linux, Docker Engine runs natively directly on the host kernel; on macOS/Windows, Docker Desktop runs the same Linux engine inside a lightweight Linux VM because those OSes lack a Linux kernel.

• Docker Engine on Linux:

  • Containers share the host's own kernel directly: no VM, minimal overhead.

  • Just the dockerd daemon and CLI, no GUI.

• Docker Desktop on macOS/Windows:

  • Runs a small Linux VM (via Apple's Virtualization framework or WSL 2 on Windows) that hosts the real engine.

  • Bundles a GUI, Kubernetes, and file/port sharing between host and VM.

  • Implications: slight performance overhead, especially for bind-mounted filesystem I/O across the VM boundary.

• Bottom line: Same container images and CLI everywhere; the difference is whether there's a VM providing the Linux kernel underneath.

Both define what a container runs, but ENTRYPOINT sets the fixed executable while CMD provides default arguments (or a default command): the key difference is how docker run arguments override them.

• CMD alone: Provides a default command that is completely replaced if you pass arguments to docker run.

• ENTRYPOINT alone: Sets the executable that always runs; docker run arguments are appended to it, not replacing it.

• Combined (the common pattern): ENTRYPOINT is the fixed command; CMD supplies default args a user can override.

• Override at runtime: You can still replace ENTRYPOINT with the --entrypoint flag.

COPY is preferred because it does exactly one predictable thing: copy local files into the image. ADD does that too but adds magic behaviors (URL fetching, auto-extraction) that are easy to trigger accidentally and make Dockerfiles less transparent.

• COPY: simple and explicit:

  • Copies files/directories from build context into the image, nothing more.

  • Clarity makes it the recommended default.

• ADD's extra features:

  • Auto-extracts a local tar archive into the destination.

  • Can fetch from a remote URL (discouraged: no checksum, extra layer weight).

• Rule of thumb: Use COPY unless you specifically want local tar extraction; for URLs prefer RUN curl so you can verify and clean up in one layer.

ARG is a build-time variable available only while the image is being built; ENV sets an environment variable baked into the image and present in the running container. For a database URL that changes at runtime you would use ENV (as a default) but actually supply the value at docker run time.

• ARG (build-time):

  • Set with --build-arg; not present in the final running container.

  • Good for versions, build flags; not for secrets (visible in history).

• ENV (build + runtime):

  • Persists into the container and is readable by the process.

  • Can be overridden at launch with -e / --env-file.

• For a runtime DB URL: Use ENV DATABASE_URL (optional default) and inject the real value with docker run -e DATABASE_URL=..., keeping the image environment-agnostic.

The exec form is a JSON array that runs the command directly as the process, while the shell form runs it through /bin/sh -c. Exec form is preferred because the container process becomes PID 1 and receives signals correctly.

• Exec form:

  • Written as ["executable", "arg1"]; no shell involved.

  • Your process is PID 1, so SIGTERM from docker stop reaches it (clean shutdown).

  • No shell means no variable expansion or && piping.

• Shell form:

  • Written as plain text; runs via sh -c, giving variable expansion, pipes, chaining.

  • The shell is PID 1 and may not forward signals, so the app can miss SIGTERM.

• Guidance: Use exec form for ENTRYPOINT/CMD; use shell form (or an explicit shell) when you need shell features.

VOLUME marks a directory in the image as a mount point for external, persistent storage, so data written there lives outside the container's writable layer and survives container removal.

• What it does:

  • At run time Docker creates an anonymous volume (unless you bind/name one) backing that path.

  • Writes go to the host-managed volume, not the copy-on-write layer.

• Implications to watch:

  • Anonymous volumes accumulate silently and clutter the host if not pruned.

  • Once a path is declared a volume, later RUN steps writing there are discarded (changes don't persist into the image layer).

  • It reduces portability of intent: many teams prefer declaring volumes at runtime (-v) or in Compose for explicit control.

When both are present, ENTRYPOINT defines the executable that always runs, and CMD supplies the default arguments passed to it: CMD acts as overridable defaults for the fixed entrypoint.

• Combined behavior: The container runs ENTRYPOINT + CMD concatenated, e.g. entrypoint ["ping"] plus cmd ["localhost"] runs ping localhost.

• Overriding at runtime:

  • Args passed to docker run replace CMD but keep ENTRYPOINT, so docker run img 8.8.8.8 runs ping 8.8.8.8.

  • ENTRYPOINT itself is overridden only with --entrypoint.

• Use exec form: Prefer JSON array (exec) form for both so signals reach the process directly and args concatenate correctly (shell form breaks this).

A multi-stage build uses multiple FROM stages in one Dockerfile, letting you build/compile in a heavy stage and copy only the finished artifacts into a lean final stage. Everything not copied forward is discarded.

• How it works: Name a stage with FROM ... AS build, then pull results with COPY --from=build into the final image.

• Reduces size: Compilers, SDKs, build caches, and dev dependencies stay in the discarded build stage, never shipping.

• Improves security:

  • Fewer packages means a smaller attack surface and fewer CVEs to patch.

  • Source code, secrets used at build time, and build tools don't leak into production.

You minimize image size by choosing lean base images, shipping only runtime artifacts, and reducing the number and content of layers. The goal is fewer, smaller layers carrying only what the app needs at runtime.

• Pick a small base: Use alpine, slim, distroless, or scratch instead of full OS images.

• Use multi-stage builds: Leave compilers and dev dependencies behind, copying only final artifacts.

• Minimize layers: Chain related commands with && and clean up in the same RUN (e.g. rm -rf /var/lib/apt/lists/*).

• Reduce what you copy: Use a .dockerignore and install only production dependencies (npm ci --omit=dev).

• Avoid cleanup traps: Deleting files in a later layer doesn't shrink the image because earlier layers still hold them.

Docker builds images layer by layer and caches each layer. For a given instruction, if the instruction and its inputs are unchanged, Docker reuses the cached layer; the first layer that changes forces a rebuild of it and every layer after it (a cache bust).

• How caching works:

  • Each instruction produces a layer keyed by the instruction text plus context (for COPY/ADD, a checksum of the copied files).

  • Caching is sequential: once a layer misses, all subsequent layers rebuild too.

• What causes a cache bust:

  • Changing an instruction's text.

  • Changing any file referenced by COPY or ADD (checksum differs).

  • A busted earlier layer invalidating everything downstream.

• Optimization strategy: Order instructions least-to-most volatile: copy dependency manifests and install before copying source code.

Both are minimal base images that shrink the container down to (mostly) just your app: Alpine is a tiny full Linux distro (~5MB) built on musl libc and BusyBox, while distroless images (from Google) contain only your app and its runtime dependencies, with no shell or package manager at all.

• Alpine:

  • Very small, uses apk and includes a shell (/bin/sh), so it's easy to debug.

  • Caveat: uses musl instead of glibc, which can break some prebuilt binaries or cause subtle bugs (e.g. DNS, Python wheels).

• Distroless:

  • No shell, no package manager, no coreutils: just the runtime and your app.

  • Debugging is harder (you can't exec into a shell), often needing a :debug variant.

• Why production prefers them:

  • Smaller attack surface: fewer packages and no shell means fewer CVEs and fewer tools for an attacker to exploit.

  • Faster pulls and less storage due to small size.

  • Usually paired with a multi-stage build: compile in a full image, copy only the artifact into the minimal final image.

Docker builds images as a stack of cached layers, and any change invalidates that layer and every layer after it. Copying dependency manifests and installing dependencies before copying source code keeps the expensive install step cached across the frequent source-code changes.

• Layers cache top-to-bottom: Once an instruction's inputs change, its cache is busted and all following instructions re-run.

• Order by change frequency: Put things that rarely change (dependency install) early, and things that change constantly (your code) late.

• Split the COPY:

  • Copy only the manifest (package.json, requirements.txt) first, run the install, then copy the rest of the source.

  • Editing source now reuses the cached dependency layer, so npm install doesn't re-run.

Docker checks, for each instruction, whether it has an identical cached layer built from the same parent layer and the same inputs. If yes it reuses it; if not, that layer and everything below it are rebuilt, which is why instruction order drives build speed.

• Cache key inputs:

  • The instruction text itself (e.g. the exact RUN command string).

  • The parent layer: if a previous layer changed, cache breaks here regardless.

  • For COPY/ADD, a checksum of the file contents being copied, not just the filename.

• Cache invalidation cascades: Once one layer misses, no layer after it can be reused, even if unchanged.

• Why order matters:

  • Place stable, expensive steps early and volatile steps (source copy) late to maximize cache hits.

  • Note: RUN is cached by its literal text, so apt-get update can serve stale results unless combined with the install in one layer.

The build context is the set of files (the directory you pass to docker build) that the Docker client packages and sends to the daemon before building. A .dockerignore excludes files from that transfer, keeping builds fast and images clean.

• What it is: Everything under the context path is tarred and sent to the daemon; COPY and ADD can only reference files inside it.

• Why it can hurt:

  • A bloated context (e.g. node_modules, .git, build artifacts) slows every build with a large upload.

  • A broad COPY . . can leak secrets (.env, keys) into the image.

• What .dockerignore does:

  • Excludes paths from the context, similar to .gitignore syntax.

  • Also improves cache stability: ignored files can't accidentally bust a COPY layer's checksum.

docker commit creates a new image from the current state of a running or stopped container, snapshotting its filesystem changes into a layer. It's handy for quick experimentation but discouraged for real images because the result is opaque and not reproducible.

• What it does: Captures the container's writable layer (installed packages, edited files) as a new image tag.

• Why it's discouraged:

  • Not reproducible: there's no recorded recipe, so no one can rebuild it from source.

  • Opaque: the image's contents and history aren't reviewable like a Dockerfile.

  • Often bloated and drift-prone, carrying leftover temp files, logs, or secrets from manual tinkering.

• Preferred alternative:

  • Use a Dockerfile: it's version-controlled, self-documenting, and rebuildable in CI.

  • Legitimate niche: capturing a debugging snapshot for later inspection.

Both stop a running container, but docker stop asks politely then forces, while docker kill forces immediately. The difference is the signal sent to PID 1 and whether a grace period is given.

• docker stop is graceful:

  • Sends SIGTERM first so the app can flush, close connections, and exit cleanly.

  • Waits a grace period (default 10s, tunable with -t), then sends SIGKILL if still alive.

• docker kill is immediate:

  • Sends SIGKILL by default (no grace period), so the process is terminated abruptly with no cleanup.

  • You can override the signal with --signal (e.g. docker kill --signal=SIGINT).

• Signals go to PID 1 only:

  • The main container process must actually handle SIGTERM; if it ignores it, docker stop falls back to SIGKILL after the timeout.

  • Shell-form CMD wraps the process in /bin/sh, which may not forward signals; use exec form to receive them.

A HEALTHCHECK tells Docker how to test that the app inside is actually working, not just that the process exists. A process can be running yet unresponsive (deadlocked, DB down, still warming up), and only a health check catches that.

• "Running" is just process liveness: Docker only knows PID 1 hasn't exited; it says nothing about whether requests succeed.

• HEALTHCHECK probes real functionality:

  • Runs a command periodically; exit code 0 = healthy, 1 = unhealthy.

  • Container status becomes healthy, unhealthy, or starting, visible in docker ps.

• Tunable timing: --interval, --timeout, --retries, and --start-period (grace time during slow startup).

• Drives orchestration: Compose depends_on: condition: service_healthy and swarm/orchestrators use it to gate traffic or restart.

A container that exits immediately almost always means its main process crashed or finished, so the fix is to read what that process said before dying. Work from logs to exit code to interactive reproduction.

• Read the logs first: docker logs <container> (use --tail / docker ps -a to find exited ones) shows the stack trace or missing-config error.

• Check the exit code: docker inspect --format='{{.State.ExitCode}}'; 137 = SIGKILL/OOM, 139 = segfault, 0 = the process simply completed and there's nothing to keep running.

• Override the entrypoint to poke inside: Run docker run -it --entrypoint sh <image> to explore the filesystem, config, and run the command manually.

• Common root causes:

  • Wrong CMD/ENTRYPOINT, missing env vars or files, foreground vs background (the process daemonizes and PID 1 exits).

  • OOM kills, permission errors, or a dependency (DB) not yet reachable.

• Keep it alive to debug (temporarily): Override with sleep infinity then docker exec -it in, but never ship that.

docker run creates a brand new container from an image and starts it; docker start restarts an existing, stopped container. The key point: run always builds a fresh writable layer, while start reuses the same container and preserves its filesystem changes.

• docker run = create + start:

  • Allocates a new container ID with a fresh writable layer on top of the image.

  • This is where you pass config: ports, volumes, env, name (they're fixed at creation).

• docker start = restart an existing container:

  • Reuses the same container and its writable layer, so any files written before it stopped are still there.

  • Cannot change run-time options like ports or env; those were set by run.

• Filesystem in between:

  • Stopping a container does not delete its writable layer; only docker rm (or --rm) destroys it.

  • So run twice gives two independent filesystems; stop then start continues one.

A container's exit code is the status code of its main process (PID 1) when it stops, and it tells you why the container ended. 137 specifically means the process was killed by SIGKILL (128 + 9), most often an OOM kill or a forced stop.

• The convention: 128 + signal number:

  • Codes above 128 mean the process was terminated by a signal; subtract 128 to get the signal.

  • 137 = 128 + 9 (SIGKILL), 143 = 128 + 15 (SIGTERM).

• Common codes:

  • 0: clean exit, no error.

  • 1 / other small numbers: application error (defined by the program).

  • 125: the Docker daemon itself failed to run the container.

  • 126: command found but not executable; 127: command not found.

• Why 137 usually means OOM:

  • The kernel OOM killer sends SIGKILL when a container exceeds its memory limit; docker inspect will show OOMKilled: true.

  • It can also just be a forced docker kill, so check the OOM flag to be sure.

• Inspect with docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>.

docker exec starts a new process inside a running container, while docker attach connects your terminal to the container's already-running main process (PID 1).

• docker exec runs a separate command:

  • Spawns a new process (e.g. a shell) alongside the main one: docker exec -it web bash.

  • Exiting that process does not stop the container.

  • This is the normal way to debug or inspect a live container.

• docker attach reconnects to PID 1:

  • You see the main process's stdout/stderr and can send input to it.

  • Pressing Ctrl+C sends a signal to that process and can stop the container; detach safely with Ctrl+P Ctrl+Q.

• Rule of thumb: use exec to poke around, use attach to watch or interact with the container's foreground process.

You cap resources with runtime flags on docker run that map to Linux cgroup controls: --memory for RAM and --cpus (or shares/quota flags) for CPU.

• Memory limits:

  • --memory (-m): hard cap; exceeding it triggers an OOM kill.

  • --memory-reservation: soft limit enforced under host pressure.

  • --memory-swap: total memory plus swap allowed.

• CPU limits:

  • --cpus: simplest, a hard fraction of cores (e.g. --cpus=1.5).

  • --cpu-shares: relative weight, only matters under contention.

  • --cpuset-cpus: pin the container to specific cores.

• In Compose use deploy.resources.limits (or mem_limit/cpus in v2).

Limits are essential in shared environments to prevent the "noisy neighbor" problem: without them one container can consume all host CPU or RAM and starve every other container. If a container exceeds its memory limit, the kernel OOM-kills it (exit 137), isolating the failure to that container.

• Why limits matter:

  • Fairness: prevents one workload from monopolizing shared resources.

  • Stability: an unbounded memory leak could exhaust host RAM and take down the whole node.

  • Predictability: schedulers and capacity planning rely on known per-container ceilings.

• What happens on OOM:

  • The kernel kills a process (usually PID 1), the container exits, and OOMKilled: true is set.

  • Other containers keep running because the limit contained the damage.

  • A restart policy can bring it back, but a persistent leak will just be killed again.

• Best practice: set both requests/reservations and hard limits so the scheduler places workloads sensibly and no container runs unbounded.

EXPOSE is documentation metadata: it declares which ports the container listens on but does not open anything. -p (--publish) actually maps a container port to a host port and makes it reachable from outside.

• EXPOSE in the Dockerfile:

  • Declares intent, so image users know the app listens on, say, port 8080.

  • Does not publish or bind; by itself the port is only reachable on the container's own network.

  • Enables docker run -P (uppercase) to auto-publish all exposed ports to random host ports.

• -p at run time:

  • Creates the actual host-to-container mapping via iptables rules.

  • Format -p host:container, e.g. -p 8080:80.

  • Works whether or not the port was declared with EXPOSE.

• Bottom line: EXPOSE is a hint; -p is what makes the port accessible from the host.

On a single host, containers on the same network communicate over a virtual bridge using internal IPs. On a user-defined bridge network Docker also runs an embedded DNS server so containers can reach each other by name instead of IP.

• Default networking:

  • New containers attach to the default bridge network and each gets a private IP (e.g. 172.17.x.x).

  • They can reach each other by IP, but the default bridge has no automatic name resolution (only legacy --link).

• User-defined networks and DNS:

  • Docker runs an embedded DNS resolver at 127.0.0.11 inside each container.

  • It resolves container names and network aliases to current IPs, so ping api works by service name.

  • Resolution is scoped to the network, giving isolation between separate user-defined networks.

• Practical takeaway: create a user-defined network so DNS-based service discovery works, which is exactly what Docker Compose does automatically.

The default bridge gives each container its own isolated network namespace with a private IP behind NAT, while host mode removes that isolation and shares the host's network stack directly. Use host mode when you need maximum network performance or dynamic port ranges and can accept losing isolation.

• Bridge network:

  • Container gets its own IP; you reach services via published ports (-p) through NAT.

  • Provides isolation and lets many containers use the same internal port without conflict.

• Host mode (--network host):

  • Container shares the host's network namespace: no separate IP, no NAT, port binds directly on the host.

  • -p is ignored, and two containers can't bind the same host port.

  • Lower latency and no NAT overhead, but weaker isolation and port conflict risk (Linux only).

• When to use host mode:

  • High-throughput / low-latency networking where NAT overhead matters.

  • Apps needing many or dynamic ports (e.g. some monitoring agents, VoIP) that are awkward to publish individually.

These are Docker's built-in network drivers that control how a container's network stack is wired: bridge gives isolated NAT connectivity, host shares the host's stack directly, and none gives no networking at all.

• bridge:

  • Default for standalone containers: each gets a private IP on a virtual bridge and reaches the outside via NAT.

  • Ports must be published (-p 8080:80) to be reachable from the host.

• host:

  • Container shares the host's network namespace: no isolation, no NAT, and no port mapping needed.

  • Best for max network performance; Linux-only in practice.

• none:

  • Container gets only a loopback interface: fully isolated from all networking.

  • Used for batch jobs or when you attach a custom network manually.

The default bridge (named bridge, backed by the docker0 interface) is where containers land automatically if you don't specify a network. Containers on it can talk over IP, but it lacks the automatic DNS of user-defined bridges.

• What it provides:

  • Each container gets a private IP on the docker0 subnet and can reach others on the same bridge by IP.

  • Outbound traffic is NAT'd through the host.

• Its limitation: No built-in name resolution: containers can only find each other by IP address (or the deprecated --link).

• Why prefer a user-defined bridge: It adds automatic DNS so containers reach each other by name, plus better isolation.

On user-defined networks, Docker runs an embedded DNS server at 127.0.0.11 inside each container that resolves container and service names to their current IPs, giving automatic service discovery without hardcoding addresses.

• How resolution works:

  • Each container's resolv.conf points at 127.0.0.11; Docker intercepts lookups and answers with the target's IP.

  • You can resolve by container name, network alias, or (in Compose/Swarm) service name.

• Why it matters:

  • IPs change on restart, but names stay stable, so apps connect by name reliably.

  • Unknown names are forwarded to the host's configured DNS for external lookups.

• Not on the default bridge: this DNS-by-name feature only exists on user-defined networks.

Legacy links (--link) were the old way to connect containers on the default bridge: they injected the target's connection info into the source container. User-defined networks replaced them because they offer the same discovery more cleanly and dynamically.

• What links did: Added the linked container's name/IP into /etc/hosts and exported its ports as environment variables.

• Why they were problematic:

  • One-directional and static: entries didn't update if the target restarted with a new IP.

  • Leaked environment variables (including secrets) between containers.

  • Tightly coupled and awkward to manage at scale.

• Why user-defined networks win:

  • Automatic embedded DNS resolves names dynamically, in both directions, no env-var leakage.

  • Containers can be attached/detached at runtime and share isolated network segments.

depends_on controls startup order: it starts dependencies first, but by default it only waits until they're started, not until they're actually ready to serve requests. You must add a real readiness check to guarantee availability.

• What it does guarantee: Dependencies are created and started before the dependent container, and stopped after it.

• What it does NOT guarantee: That the dependency's process (e.g. a database accepting connections) is fully initialized: "started" is not "ready".

• How to solve readiness:

  • Define a healthcheck on the dependency and use condition: service_healthy in depends_on.

  • Or make the app resilient: retry connections with backoff, or use a wait-for-it style entrypoint script.

You scale by running multiple replicas of one service, either with docker compose up --scale or via a deploy.replicas key; Compose creates several identical containers that share the same config and network.

• Command-line scaling: docker compose up --scale web=3 launches three instances of web.

• Declarative scaling: deploy.replicas: 3 in the file (honored by docker compose up in recent versions and by Swarm).

• Constraints to respect:

  • Don't publish a fixed host port (ports: "8080:80") on a scaled service: only one container can bind it. Use a range or an upstream load balancer.

  • Replicas should be stateless; share state via a DB or volume, not local disk.

• Load distribution: Compose's internal DNS round-robins the service name across replicas, so other services reach them via the service name.

Override files let you layer environment-specific changes on top of a base file: Compose automatically merges docker-compose.yml with docker-compose.override.yml, so the base holds shared config and the override adjusts it per environment.

• Automatic merge: If both docker-compose.yml and docker-compose.override.yml exist, docker compose up loads both by default, override winning.

• Merge rules:

  • Scalar/mapping values (image, environment) are overridden or added.

  • Lists (like ports, volumes) are concatenated, not replaced.

• Explicit files for other environments:

  • Use -f chains: docker compose -f docker-compose.yml -f docker-compose.prod.yml up. Later files override earlier ones.

  • When you pass -f explicitly, the automatic override file is NOT loaded.

• Common pattern: base = shared, override.yml = local dev conveniences (bind mounts, debug ports), prod.yml = production tuning.

A healthcheck defines a command Docker runs to mark a container healthy or unhealthy; combined with depends_on using condition: service_healthy, a dependent service waits to start until its dependency is actually ready, not just running.

• Why it matters: Plain depends_on only waits for the container to start, not for the app inside (e.g. Postgres accepting connections) to be ready.

• Defining the check: test runs a command; exit 0 = healthy. Tune with interval, timeout, retries, and start_period.

• Gating startup: Use the long-form depends_on with condition: service_healthy so the dependent waits for a passing check.

• Caveat: this only helps at orchestration startup; app code should still retry connections, since dependencies can restart later.

Both persist data outside a container's writable layer, but a volume is managed by Docker in its own storage area, while a bind mount maps an exact host path into the container. Volumes are the portable, Docker-managed default; bind mounts give direct host access.

• Docker Volume:

  • Stored under Docker's area (/var/lib/docker/volumes) and managed by docker volume commands.

  • Host-path independent, easy to back up, and supports volume drivers (e.g. network storage).

  • Best for: databases and app state you want Docker to own and keep portable.

• Bind Mount:

  • Maps a specific host directory/file into the container; you control the exact path.

  • Reflects host changes live, but ties the container to the host's filesystem layout and permissions.

  • Best for: local dev (mount source code for hot reload), or sharing host config files.

• Rule of thumb: volumes for persistent production data, bind mounts for development and host-specific files.

Two containers share data by mounting the same volume (or the same host path via bind mount) at their respective mount points; the underlying storage is a single location on the host, so writes from one container are visible to the other.

• Shared named volume: Both services list the same volume, e.g. shared-data:/app/data; Docker points both at the same directory on the host.

• Shared bind mount: Both containers mount the same host path, e.g. /host/dir:/data.

• Mechanism:

  • The mount makes the container see the host directory at its mount point; there is one copy of the bytes, referenced by multiple containers.

  • Access can be tuned read-only with a :ro suffix.

• Caveat: concurrent writes are not coordinated by Docker; the apps must handle locking/consistency themselves.

Both are Docker-managed volumes, but a named volume has an explicit name you assign and reuse, while an anonymous volume gets a random generated ID and is tied to the container that created it, making it hard to reference later.

• Named volume:

  • Created with a chosen name (-v mydata:/data or a volumes: entry).

  • Easy to reuse across containers, inspect, and back up; persists intentionally.

• Anonymous volume:

  • Created without a name, e.g. -v /data or a bare VOLUME in a Dockerfile; Docker assigns a long hash ID.

  • Meant for one container; awkward to identify and often orphaned.

• Lifecycle difference: docker rm -v or docker compose down -v removes anonymous volumes; named ones are typically kept unless explicitly targeted.

• Prefer named volumes for anything you want to persist and manage deliberately.

Use a tmpfs mount when you need fast, ephemeral storage that lives only in the host's memory and never touches disk, typically for sensitive or throwaway data.

• Memory-backed and ephemeral: Data exists only while the container runs; it disappears on stop and is never persisted to the host filesystem.

• Common use cases:

  • Secrets, credentials, or tokens you don't want written to disk.

  • Scratch space or temporary files where speed matters and durability doesn't.

• Linux-only: Unlike volumes and bind mounts, tmpfs mounts work only on a Linux host.

• How to use it: Add --tmpfs or --mount type=tmpfs on docker run.

You back up a named volume by running a temporary helper container that mounts the volume and tars its contents to a host directory, then restore by extracting that tarball back into a fresh volume.

• Why a helper container: A named volume isn't a normal host path, so you attach it to a throwaway container to read/write its data.

• Backup: Mount the volume plus a host bind mount, then tar the volume contents into the bind-mounted directory.

• Restore: Create (or reuse) the target volume and untar the archive into it.

• Consistency caveat: For databases, stop the app or use its dump tool to avoid backing up a file mid-write.

Pinning a specific tag or an immutable digest guarantees every build and deploy pulls the exact same image, whereas :latest is a moving pointer that can silently change under you.

• :latest is mutable: It's just a tag that maintainers reassign; the same command can yield different images on different days.

• Reproducibility and debugging: Pinned versions mean CI, staging, and production run identical bits, so "works on my machine" bugs shrink.

• Digests are strongest: A @sha256:... digest is content-addressed and immutable: it can never point to different content.

• Tags balance safety and readability: A version tag like nginx:1.25.3 is human-friendly; combine with a digest for maximum guarantee.

• Security and rollback: Pinning avoids pulling an unreviewed image and makes rollbacks precise.

These are trust tiers on Docker Hub: official images are curated by Docker, verified publisher images come from vetted commercial vendors, and community images are uploaded by any user with no guarantee.

• Official images:

  • Maintained by Docker in partnership with upstream projects, following best practices and security review.

  • Live at the root namespace with no user prefix (e.g. nginx, postgres).

• Verified Publisher images:

  • Published by known organizations whose identity Docker has verified, shown with a badge.

  • Namespaced under the vendor (e.g. grafana/grafana); also exempt from some rate limits.

• Community images:

  • Any account can push them; quality and security vary and are unverified.

  • Inspect them (contents, Dockerfile, popularity) before trusting them in production.

Docker Hub rate limits cap how many image pulls a client can make in a time window based on account tier, so shared CI runners or NAT'd production hosts can hit the limit and get pull failures.

• Limits by account tier: Anonymous users are limited by source IP; authenticated free accounts get a higher quota; paid plans get more or unlimited.

• Why CI is vulnerable: Many runners often share one egress IP, so their pulls count against a single anonymous bucket and exhaust it quickly.

• The symptom: A 429 Too Many Requests ("toomanyrequests") error mid-pipeline or deploy.

• Mitigations:

  • Authenticate with docker login to raise the quota.

  • Run a pull-through cache / mirror registry, or mirror images into your own registry (ECR, GHCR).

Use immutable, traceable tags for what actually ships and mutable convenience tags only as pointers: never rely on latest for deployment because it hides which build is running.

• Immutable, unique tags for real builds:

  • Tag with the Git commit SHA or a semantic version (v1.4.2, app:sha-a1b2c3d) so an image maps to exact source.

  • Never overwrite an existing tag: a given tag always means the same bytes, which makes rollbacks and audits reliable.

• Environment is a deploy-time concern, not a build-time one:

  • Promote the same immutable image dev to staging to prod rather than rebuilding per environment, so you test the exact artifact you ship.

  • Use moving pointers (staging, prod) that are re-pointed to a proven SHA during promotion.

• Treat latest as a convenience only: Fine for local pulls, dangerous in production because it is ambiguous and can silently change.

• Pin by digest for the strongest guarantee: Deploy image@sha256:... so even a re-tagged image can't change what runs.

Inject secrets at runtime from outside the image (orchestrator secrets, mounted files, or a secrets manager) so they never become part of an immutable, shareable layer.

• Why not bake them in: Anything in a COPY, ENV, or ARG persists in the layer history and is readable by anyone who pulls the image, even if a later layer deletes it.

• Runtime injection options:

  • Environment variables at run: docker run --env-file (convenient, but visible via docker inspect and process env).

  • Orchestrator secrets: docker secret (Swarm) or Kubernetes Secret objects mounted as tmpfs files, kept out of the image.

  • External secret managers: Vault, AWS Secrets Manager, etc., fetched by the app at startup for rotation and audit.

• Files beat env vars for sensitive values: Mounted secret files aren't exposed to child processes or crash dumps as easily as env vars.

• Keep secrets out of source control too: Add .env to .gitignore and .dockerignore so they aren't committed or sent to the build context.

Containers run as root by default, and that root maps to real root on the host kernel; using USER to drop to a non-privileged account limits the damage if the process or container is compromised.

• Principle of least privilege: A process should have only the permissions it needs; a web app rarely needs root.

• Container root is host root: Without user namespaces, an attacker who escapes a root container has root on the host; a non-root user makes breakout much harder.

• Reduces attack surface inside the container: Non-root can't modify system files, install packages, or bind to privileged ports (<1024), limiting what a compromise can do.

• How to do it: Create a user, fix file ownership, then switch before the app runs; combine with a read-only filesystem and dropped capabilities for defense in depth.

Image scanning is the automated inspection of an image's layers, OS packages, and application dependencies against known vulnerability (CVE) databases; it catches insecure components before they reach production.

• What it inspects:

  • OS packages, language dependencies, and sometimes misconfigurations, exposed secrets, or non-root violations.

  • Tools include Trivy, Grype, Snyk, and registry-native scanners.

• Why it's critical:

  • Images inherit vulnerabilities from base images and transitive dependencies you didn't write.

  • Finding issues early (shift-left) is far cheaper than patching in production.

• Where it fits in the lifecycle: In CI to fail builds above a severity threshold, at the registry to block bad pushes, and continuously since new CVEs appear for already-shipped images.

• Limits: Scanners only know published CVEs and can produce false positives; pair with minimal base images to shrink what there is to scan.

--privileged gives a container nearly all host kernel capabilities and access to host devices, essentially disabling the isolation that makes containers safe, so it should be avoided except for rare, tightly controlled cases.

• What it actually grants: All Linux capabilities, access to all host devices under /dev, and it lifts seccomp/AppArmor and cgroup device restrictions.

• Why it's dangerous: A privileged container can manipulate the host kernel, mount host filesystems, and load modules, making container breakout trivial.

• The right approach:

  • Grant only the specific capabilities needed with --cap-add, and drop the rest via --cap-drop=ALL.

  • Expose a single device with --device instead of all of them.

• When it may be justified: Docker-in-Docker or low-level hardware tooling, and even then prefer scoped capabilities or rootless alternatives.

Running one main process per container keeps containers simple, observable, and independently scalable, and it matches how Docker manages lifecycle through a single foreground process (PID 1).

• Why it's recommended:

  • Clean lifecycle: Docker starts/stops based on PID 1, and logs/health map to one concern.

  • Independent scaling and updates: scale the web tier without touching the database.

  • Better isolation and simpler debugging: one responsibility per container.

• When you might break it:

  • A helper sidecar-like process (log shipper, metrics exporter) tightly coupled to the main app.

  • Legacy apps needing several coordinated processes: use a proper init like tini or a supervisor.

• Caveat: Multiple processes still need an init to reap zombies and forward signals; PID 1 has special responsibilities.

A dangling image is a layer with no tag and no repository (shown as <none>:<none>), usually an old build superseded by a rebuild; an unused image is any tagged or untagged image not currently referenced by a container.

• Dangling image:

  • Created when a rebuild reassigns a tag to a new image, orphaning the old one.

  • List with docker images -f dangling=true.

• Unused image:

  • A complete, possibly tagged image that no container is using, but still valid to run.

  • All dangling images are unused, but not all unused images are dangling.

• Cleanup difference: docker image prune removes only dangling; docker image prune -a removes all unused.

docker diff lists the filesystem changes a container has made to its writable layer compared to the image it was started from, so you can see exactly what a running container touched.

• Three change markers:

  1. A: a file or directory was added.

  2. C: an existing file or directory was changed.

  3. D: a file or directory was deleted.

• Why it helps debugging:

  • Reveals where an app writes at runtime (logs, temp files, caches) that you may need to persist with a volume.

  • Confirms whether a process modified unexpected paths, useful for spotting misconfiguration or security concerns.

  • Helps decide what to include when building an image from a container's state.

• Scope: It reports only the container's writable layer diff against the image, not changes inside mounted volumes.

Logging drivers are pluggable backends that determine where a container's stdout/stderr output is sent. The default json-file writes logs to JSON files on the host, but you switch drivers to centralize logs, control disk usage, or integrate with external log systems.

• Common drivers:

  • json-file: default, local JSON files, readable via docker logs.

  • local: more efficient local storage with built-in rotation.

  • syslog, journald, fluentd, gelf, awslogs, splunk: ship logs to external/centralized systems.

• Why change from the default:

  • Disk safety: json-file has no rotation by default and can fill the disk; drivers with rotation or remote shipping avoid that.

  • Centralization: aggregate logs from many hosts/containers into one searchable place (ELK, CloudWatch, Splunk).

  • Compliance and retention: forward to systems that handle long-term storage and audit.

• Trade-off: Most non-local drivers break docker logs, since output no longer lives on the host.

docker system df reports how much disk space Docker is using, broken down by object type, and docker system prune reclaims that space by removing unused objects.

• What docker system df shows:

  • Space used by images, containers, local volumes, and the build cache.

  • How much is reclaimable (dangling images, stopped containers, unused volumes/cache).

  • Add -v for a per-object breakdown.

• What docker system prune removes:

  • By default: stopped containers, dangling images, unused networks, and build cache.

  • --volumes: also removes unused volumes (careful, this deletes data).

  • -a: removes all unused images, not just dangling ones.

• Why it matters:

  • CI hosts and dev machines accumulate old layers and cache that silently consume disk; prune reclaims it.

  • Caution: prune is irreversible, so verify with df before running it in shared environments.

Docker Swarm is Docker's built-in container orchestrator: it turns a group of Docker hosts into a single logical cluster and schedules containers (as services) across them, adding clustering, scaling, and self-healing on top of plain container runs.

• Standalone containers are imperative and single-host: You run and manage each container yourself with docker run; if it dies or the host fails, nothing brings it back.

• Swarm is declarative and cluster-wide:

  • You declare a desired state (a service with N replicas of an image) and the swarm continuously reconciles reality to match it.

  • Manager nodes hold cluster state and schedule tasks; worker nodes run them.

• Built-in orchestration features:

  • Self-healing: failed tasks are rescheduled to keep the replica count.

  • Scaling: docker service scale adjusts replicas.

  • Load balancing across replicas via a routing mesh, plus rolling updates.

• Positioning: Simpler than Kubernetes and native to the Docker CLI, but far less common in production today.

Compose defines and runs a multi-container app on a single host for development and testing; Swarm is a clustering/orchestration mode that runs services across many hosts in production. They are complementary, not competing: you can describe an app in a Compose file and deploy it to a Swarm.

• Docker Compose:

  • A tool to define multiple containers in a YAML file and start them together with docker compose up.

  • Single host by default: great for local dev, no clustering, healing, or multi-node scheduling.

• Docker Swarm:

  • A built-in orchestrator that turns multiple Docker hosts into one cluster (docker swarm init).

  • Provides services, replicas, scheduling across nodes, rolling updates, and self-healing.

• They connect via stacks: A Compose file can be deployed to a Swarm with docker stack deploy, using the deploy: section that Compose alone ignores.

A service in Swarm is the declarative definition of how a containerized application should run across the cluster: which image, how many replicas, ports, networks, and update policy. Swarm's job is to continuously reconcile the cluster to match that desired state.

• It is the unit of deployment in Swarm mode: You declare intent (docker service create --replicas 3 nginx), not individual containers.

• A service is realized as tasks:

  • Each task is a slot that the scheduler runs as one container on a node.

  • If a task dies, Swarm creates a replacement to restore the replica count.

• It provides built-in networking features: Service discovery via a virtual IP and DNS name, plus routing-mesh load balancing across replicas.

• Compare to a plain container: a container is one running instance; a service manages the lifecycle of many across the cluster.

A container is a single running instance of an image on one node; a service is the higher-level, declarative object that describes and manages a set of containers (as tasks) across the whole Swarm. The service is the desired state; containers are the running reality that Swarm keeps matching it.

• Container:

  • A concrete process/instance created from an image, living on a specific node.

  • If it crashes and nothing manages it, it simply stops.

• Service:

  • A declarative spec (image, replicas, update policy) reconciled by Swarm.

  • It maps to tasks, and each task runs one container; failed tasks are recreated automatically.

• The hierarchy: service defines tasks, and each task is one container.

• Practical takeaway: you manage a service; Swarm manages the containers on your behalf.

Manager nodes run the control plane (they accept commands, maintain cluster state, and schedule work), while worker nodes just execute the tasks assigned to them. Managers can also run workloads, but workers can never manage the cluster.

• Manager nodes:

  • Maintain the desired state and cluster store using the Raft consensus algorithm.

  • Handle scheduling, orchestration, and the API (docker service commands run against managers).

  • Run an odd number (3 or 5) for fault tolerance; a majority quorum must be available to make decisions.

• Worker nodes:

  • Run the tasks (containers) the managers assign, reporting status back.

  • Have no say in cluster management and cannot view or change cluster state.

• Notes:

  • Managers are workers too by default; you can drain them with availability settings to keep them control-plane only.

  • Quorum math: with N managers you tolerate (N-1)/2 failures, which is why an odd count is recommended.

A stack is a group of related services deployed together to a Swarm from a single Compose file. It is essentially Compose syntax used at cluster scale: docker stack deploy reads the YAML and creates the services, networks, and volumes as one managed application.

• What it is:

  • A named collection of services (plus their networks/volumes) treated as one unit.

  • Deployed and removed together: docker stack deploy -c docker-compose.yml myapp and docker stack rm myapp.

• Relation to Compose:

  • Reuses the same Compose file format (v3+), so one definition works for dev and cluster.

  • The deploy: section (replicas, placement, update policy) is honored by stacks but ignored by plain docker compose.

• Relation to Swarm:

  • Requires Swarm mode; each service in the stack becomes a Swarm service with tasks scheduled across nodes.

  • Build directives aren't used: stacks require pre-built images from a registry.

Copy-on-Write (CoW) lets all containers share the same read-only image layers; a container only copies a file up into its own writable layer at the moment it modifies that file. Until then, everyone reads the shared copy, saving disk and speeding startup.

• Reads are shared: Containers see the base image layers directly; no duplication for unchanged files.

• Writes trigger a copy:

  • On first modification, the file is copied from the read-only layer into the container's writable layer, then edited there.

  • The original layer stays untouched, so other containers are unaffected.

• Isolation between containers: Each container has its own writable layer, so their changes never collide.

• Benefits:

  • Fast container creation and low disk usage: only deltas cost space.

  • Implemented by storage drivers like overlay2.