Skip to content

Portal | Level: L0: Entry | Topics: Docker / Containers | Domain: Kubernetes

Docker - Skill Check

Mental model (bottom-up)

Containers are just processes with namespaces (isolation) and cgroups (limits). Images are layers stacked by a union filesystem.

Visual stack

[Container     ]  a process with isolated view of files/net/pids
|
[Namespaces    ]  pid/net/mount/user isolation
|
[cgroups       ]  CPU/mem/io limits and accounting
|
[Image layers  ]  union FS layers + copy-on-write
|
[Host kernel   ]  shared kernel (not a VM)

Glossary

  • namespace - isolation boundary for processes
  • cgroup - resource limiting/accounting
  • image layer - filesystem diff added by a Dockerfile step
  • copy-on-write - writes go to top layer; lower layers stay immutable
  • volume - persistent storage outside container lifecycle
  • bridge network - default NATed container network

Roadmap core (easy -> hard)

  • What is a container (really)?
  • Isolated process via namespaces + cgroups (not a VM).
  • Image vs container?
  • Image = immutable template; container = running instance.
  • Why "works on my machine" happens?
  • Missing deps/env/config; container pins runtime and deps.
  • What is a volume used for?
  • Persist data outside container lifecycle.
  • Port mapping meaning?
  • Host port forwards to container port.

Builds & images (easy -> hard)

  • Why .dockerignore?
  • Shrinks build context; avoids leaking secrets; faster builds.
  • Layer caching: what breaks it?
  • Changing earlier steps or copying changing files too early.
  • Why multi-stage builds?
  • Smaller, safer runtime images by excluding build tools.
  • Base image choice matters because?
  • Size + CVE surface + libc/compatibility.
  • COPY vs ADD?
  • Prefer COPY; ADD has extra magic (tar/URL) you usually don't want.
  • Pin image versions?
  • Avoid surprise breakage; easier rollbacks.

Runtime, networking, storage (easy -> hard)

  • Bridge network does what?
  • NATed container network with port publishing.
  • Host network tradeoff?
  • Faster/simpler but less isolation.
  • Bind mount vs named volume?
  • Bind uses host path; named is Docker-managed.
  • Why containers "lose data"?
  • Container FS is ephemeral unless using volumes.
  • Healthcheck value?
  • Lets orchestrators detect unhealthy containers.

Security & reliability (easy -> hard)

  • Why run as non-root?
  • Reduce impact of container breakouts and app bugs.
  • What are Linux capabilities?
  • Fine-grained privileges; drop all then add minimal needed.
  • Read-only filesystem pattern?
  • Mount app FS read-only; writable dirs via tmpfs/volumes.
  • Secrets injection best practice?
  • Runtime secrets store; avoid baking secrets into images/env.
  • Supply chain baseline?
  • Scan images, pin digests, signed artifacts, minimal base.

Debugging (easy -> hard)

  • First 3 commands when a container fails?
  • docker ps -a, docker logs <id>, docker inspect <id>.
  • How do you "get a shell"?
  • docker exec -it <id> sh (or bash if present).
  • Why exit 137 shows up?
  • SIGKILL (often OOM-killed).
  • How do you reproduce locally?
  • Run the same image/tag with same env/volumes; compare.

Visual guide (multi-stage)

FROM build AS builder
# compile here
FROM runtime
COPY --from=builder /app/bin /app/bin

Cleanup / teardown

  • Remove resources you created:
  • docker rm -f <container>; docker rmi <image>; docker volume rm <vol>; docker network rm <net>
  • Nuke unused stuff (careful):
  • docker system prune -a (this is destructive).

Key correctness notes

  • Multi-stage builds let you use multiple FROM stages and copy only what you need into the final image.
  • The common outcome is a smaller, more secure final image — build-time tools and secrets from earlier stages are excluded.

Sources

  • Docker official docs: build best practices, multi-stage builds.
  • https://docs.docker.com/build/building/multi-stage/

Wiki Navigation

Related Content