Docker: Interview Set

Image

Read-only template/blueprint — packaged app code, dependencies, runtime, filesystem, built in layers

Container

A running instance of an image — isolated process, writable layer on top of the image's read-only layers

Registry

Storage/distribution service for images (Docker Hub, ECR, private registries)

Image Tag

Label identifying a specific version/variant of an image

docker run

Creates and starts a container from an image

docker run -d

Run container in detached/background mode

docker run -p

Map container port to host port (host:container)

docker run -v

Mount volume (host:container)

docker run -e

Set environment variable

docker run flag order

All docker run flags go BEFORE the image name

docker ps

List running containers

docker ps -a

List all containers, including stopped

docker exec -it

Run an interactive command in a running container

-i flag

Keeps STDIN open, lets container receive input

-t flag

Allocates a pseudo-terminal — makes output render as an interactive session

docker stop vs docker kill

stop sends SIGTERM (graceful), kill sends SIGKILL (immediate, no cleanup)

docker rm

Remove a stopped container permanently

docker rmi

Remove an image — must remove all containers using it first

docker logs

View a container's stdout/stderr output

Where logs are stored (default)

Host filesystem, /var/lib/docker/containers//, json-file driver

Production logging pattern

Configure a different log driver (awslogs, syslog, fluentd) to ship to centralized aggregation

FROM

Sets the base image everything else builds on

RUN

Executes a command at build time, result baked into a new layer

COPY

Copies files from build context into the image at build time

ENV

Sets an environment variable, available at build time and runtime

WORKDIR

Sets working directory for subsequent instructions

EXPOSE

Documents which port the container listens on — informational only, doesn't publish it

CMD

Default command/arguments — fully overridden if anything is passed at the end of docker run

ENTRYPOINT

Fixed command that always runs — runtime args get appended, not replaced

CMD + ENTRYPOINT together

ENTRYPOINT = fixed program, CMD = default (overridable) arguments to it

Exec form vs shell form

Exec form ["cmd","arg"] preserves signal handling

Build context

The directory docker build looks in for the Dockerfile and any COPY sources

docker build -t

Tags the built image with a name:version

Dockerfile instruction order and caching

Put least-frequently-changing steps first (e.g. dependency install before app code) to maximize layer cache reuse

Layer caching

Docker skips re-running a layer if it and everything above it are unchanged

Why separate layers exist

Enables caching, cross-image layer sharing/dedup, and copy-on-write

Copy-on-Write (CoW)

Layers stay read-only and shared

Multi-stage build

Multiple FROM stages in one Dockerfile

Why multi-stage builds

Keeps final image small — build tools/dependencies from earlier stages never ship in the final image

Parallel stages

Independent stages (no COPY --from= between them) build concurrently in BuildKit automatically

BuildKit cache mount

RUN --mount=type=cache — persists a directory (e.g. pip/apt cache) across builds, not included in final image

Cache mount scope

Applies only to the single RUN instruction it's attached to

Cache mounts in CI

Don't work by default on ephemeral runners (e.g. GitHub Actions) — need external backend like type=gha or type=registry

BuildKit secret mount

RUN --mount=type=secret — makes a credential available only during that one RUN step, never persisted in any layer

Why not use ENV for secrets

ENV creates a permanent, inspectable layer — visible via docker history/inspect forever

--platform flag

Specifies target architecture (linux/amd64, linux/arm64) for a build or base image

docker init

Scaffolds a starter Dockerfile, .dockerignore, and compose.yaml based on detected project type

Volume

Persistent storage outside a container's writable layer — mounted at a path, survives container removal

Named volume

Docker-managed storage location

Bind mount

Host path you specify directly

Volume vs bind mount use case

Volumes for production/persistent data (databases)

tmpfs mount

Stores data in host memory only, never touches disk, gone when container stops

docker system df

Shows actual disk usage, accounting for layer deduplication across images

docker images size vs system df

images shows each image's full logical size independently

docker ps -s (size column)

Shows container writable-layer size and virtual size (writable + all image layers, no dedup credit)

Storage driver

Mechanism implementing the layered filesystem — overlay2 is the modern default (uses OverlayFS)

Docker network purpose

Controls how containers communicate with each other, host, and outside world

bridge network (default)

Private virtual network on the host

Custom bridge network

Adds automatic DNS resolution by container/service name — default bridge does NOT have this

host network

No isolation — container shares host's network stack directly, no port mapping needed

none network

No networking beyond loopback

overlay network

Connects containers across multiple hosts (Docker Swarm)

macvlan network

Gives container its own MAC address, appears as physical device on host network

docker network create --subnet/--gateway

Defines custom IP range and exit-point address for a network — fixed at creation, can't be edited after

Docker Compose

Defines a multi-container app in one YAML file

Compose services

Each service = one container definition (image, ports, env, volumes, networks)

Compose networking

Containers on the same custom network resolve each other by service name automatically

Compose depends_on

Controls start order only — does NOT wait for the dependency to be actually ready

docker compose up

Builds/starts the full multi-container stack defined in the compose file

Compose vs Kubernetes

Compose = local dev/single-host

docker (CLI)

Client that translates commands into REST API requests

REST API

Interface dockerd exposes

dockerd

Daemon that receives API requests, coordinates Docker-specific logic, delegates lifecycle execution to containerd

containerd

Standalone runtime managing actual container lifecycle — image pulls, snapshotting, supervising running containers

runc

Creates the actual isolated container process using namespaces + cgroups, then exits

Namespaces

Kernel feature controlling what a process CAN SEE — isolated PIDs, network, mounts

cgroups

Kernel feature controlling what a process CAN USE — CPU/memory/IO resource limits

Why K8s uses containerd directly

containerd supports CRI (Container Runtime Interface) natively

gRPC

RPC framework (protobuf + HTTP/2) used for dockerd-to-containerd internal communication

docker exec -it cat /etc/os-release

Standard way to check a running container's OS/distro

VM vs Container

VM virtualizes hardware, full OS per guest, heavier