Docker & Containers
Study Guide

Image is an immutable, layered filesystem snapshot plus metadata (entrypoint, env, config). A container is a running instance of an image: writable thin layer on top, isolated process namespace, cgroup limits. Many containers can share the same image.

ENTRYPOINT defines the fixed executable; CMD supplies default arguments to that entrypoint (or the full command if no ENTRYPOINT). If both exist, CMD args are appended to ENTRYPOINT. Override: docker run --entrypoint replaces ENTRYPOINT; trailing args replace CMD.

Copy only build artifacts into a final slim image. Earlier stages can include compilers, dev dependencies, and secrets used only at build time. Smaller attack surface, faster pulls, lower registry storage. Final stage often uses FROM scratch or distroless for Go/static binaries.

Each Dockerfile instruction creates a layer; unchanged layers reuse cache. Put rarely changing steps first (base image, package installs), frequently changing last (copy app source). Copy package.json before source so dependency install caches when only code changes.

Tags are mutable pointers (e.g. latest can change). Digest (SHA256) identifies an exact image content. Pinning by digest ensures reproducible deploys and prevents supply-chain surprises when a tag is retagged. Trade-off: you must bump digest explicitly for updates.

Docker Engine historically bundled higher-level UX (API, CLI, swarm). containerd is a CNCF runtime that manages image pull, storage, and container lifecycle; Kubernetes and modern Docker use containerd (or CRI-O) under the hood.

Common namespaces: PID (process tree), NET (network interfaces), MNT (filesystem mounts), UTS (hostname), IPC, USER (UID mapping). Combined with cgroups for CPU/memory limits and capabilities/seccomp/AppArmor for syscall restriction.

PID 1 is the init process for the container; when it exits, the container stops. Zombie reaping: naive PID 1 may not reap child processes - use a minimal init (tini, dumb-init) or ensure the app handles signals and children correctly.

Docker: --cpus, --memory, or in Compose/Kubernetes: resources.limits. cgroups enforce limits. Without limits, a container can starve the host. Set requests (guaranteed) and limits (cap) in orchestrators for scheduling and stability.

Rootful daemon runs as root on the host - simpler but larger blast radius if compromised. Rootless maps UIDs with user namespaces so container root is unprivileged on host; better security, occasional compatibility issues with certain volume mounts, networking modes, or legacy images expecting real root.

Containers on the default bridge can reach each other by IP but not by container name unless on a user-defined bridge. User-defined networks enable DNS resolution of service names. host mode shares the host network stack (no isolation). none disables external networking.

Docker sets up iptables (or nftables) rules on the host to NAT traffic from host port 8080 to container port 80 on the bridge network. The app inside still listens on 80; clients use the host IP and 8080.

An overlay encapsulates container traffic across hosts (VXLAN, etc.) so pods/tasks on different nodes share a virtual L2/L3 network. Required for multi-node service discovery and load balancing in clusters.

EXPOSE is documentation/metadata only - it does not open firewall or publish ports. Publishing requires -p or Compose ports:. EXPOSE helps humans and orchestrators understand intended ports.

Verify same network (docker network inspect), DNS names, correct listen address inside app (0.0.0.0 not only localhost). Use docker exec ping/nslookup, tcpdump, check iptables and whether firewalld blocks published ports.

Bind mount maps a host path into the container - explicit, good for dev, host-dependent paths. Named volume is managed by Docker in a storage location - portable, easier backup plugins. Both persist data beyond container lifecycle.

No - the writable container layer is deleted with docker rm unless data is in a volume or bind mount. Images stay; anonymous volumes may be orphaned unless removed with -v.

tmpfs stores data in memory - fast, ephemeral, never hits disk. Good for sensitive temp files, cache, or reducing disk I/O. Lost on container restart - not for durable data.

Mount root as read-only so malware or RCE cannot persist binaries in /. Pair with tmpfs for /tmp and writable volumes only where needed. Kubernetes: readOnlyRootFilesystem: true in security context.

Container user may not match host file ownership - permission denied or security leaks. Fix with consistent UIDs in image, user namespaces, or adjusting host permissions. On rootless Docker, subuid/subgid mapping matters.

Declarative multi-container apps: networks, volumes, env, dependencies, scale profiles. One file for local dev parity with production-ish topology. docker compose up orchestrates lifecycle on a single host (or Swarm with legacy compose v3 deploy).

depends_on only orders start - not readiness. A DB container may start before it accepts connections. Use healthcheck + depends_on: condition: service_healthy (Compose v2+) or retry logic in apps.

Use env files excluded from Git, Docker/Kubernetes secrets, Vault agents, or runtime injection from CI. Never ARG for secrets in layers that persist - build args can leak in image history.

Excludes files from build context sent to the daemon - faster builds, smaller context, avoids copying .git, secrets, or node_modules when not needed. Same idea as .gitignore for Docker builds.

Same Dockerfile multi-target or separate stages: dev stage with debug tools, hot reload; prod minimal runtime only. Or docker-compose overrides (docker-compose.override.yml) mounting source for dev. Avoid running dev images in production.

Run as non-root user (USER), drop Linux capabilities, read-only root FS, no privileged mode, minimal base images (Alpine/distroless), scan images for CVEs (Trivy, Grype), pin base image digests.

Grants almost all host capabilities, disables many isolations - equivalent to near-root on host. Breaks container security model. Only for rare cases (certain device drivers); prefer specific device/capability grants.

Known CVEs in OS packages and libraries. Pitfalls: base image noise, unfixed upstream, devDependencies flagged in prod images, version pinning vs distro patches. Combine scanning with runtime policy (OPA, admission control).

Risks: compromised base images, typosquat registries, malicious layers, build cache poisoning. Mitigations: verify image signatures (cosign), use private registry, SBOM, reproducible builds, minimal bases, audit Dockerfile FROM lines, pin digests.

K8s adds scheduling, self-healing, rolling updates, service discovery, ConfigMaps/Secrets, network policies, RBAC, and horizontal scaling across nodes. Docker alone is one host; production usually needs orchestration or a managed platform.