What is Docker and how does it work?

Why it exists. Docker lets you package an application with all of its dependencies (libraries, config, runtime) into a single artifact — an image — and run it identically on a developer laptop, in CI, and in production. This solves the classic "works on my machine" problem.

Containers vs. virtual machines. A VM virtualizes hardware and ships an entire guest OS with its own kernel. A container is an isolated process that uses the host's kernel. As a result, containers are lighter, start in fractions of a second, and use fewer resources. But a container is not a lightweight VM: it is tied to the host kernel, and its isolation boundary is weaker than a VM's. A VM has hardware-enforced isolation, whereas a vulnerability in the shared kernel can potentially be escaped from a container — that's the trade-off for the speed and density. The host must match the container type: Linux containers need a Linux kernel, Windows containers need a Windows kernel. On macOS and Windows, Docker Desktop transparently runs a small Linux VM (e.g. via WSL2), so Linux containers there share that VM's kernel, not your OS's kernel.

Architecture (client-server). Per Docker's documentation:

• The docker client is the primary way users interact with Docker; commands like docker run are sent to the daemon.
• The dockerd daemon "does the heavy lifting" of building, running, and distributing containers and manages objects such as images, containers, networks, and volumes.
• The client talks to the daemon over a REST API via a UNIX socket or a network interface, so they can run on different machines.
• A registry stores images; the default public one is Docker Hub.

Images and containers. A handy analogy: an image is like a class (or a program on disk), and a container is an instance of it (a running process); you can start many containers from one image.

• An image is a read-only template with instructions for creating a container, built from layers. It's defined by a Dockerfile; when you change it, only the changed layers are rebuilt.
• A container is a runnable instance of an image. On top of the image's read-only layers it adds a thin writable layer (copy-on-write); anything written there is lost when the container is removed — which is exactly why persistent data needs volumes.

How isolation works (under the hood). dockerd doesn't call the kernel directly — it delegates container lifecycle management to containerd, which invokes an OCI runtime; in Docker the default is runc, but the runtime is pluggable (crun, gVisor, Kata, etc.). The actual isolation comes from Linux kernel features:

• namespaces isolate resources (per the man7 page there are 8 types: PID, network, mount, UTS, IPC, user, cgroup, time). A process only "sees" its own PIDs, its own network stack, and so on.
• cgroups (control groups) limit and account for resource usage (CPU, memory, I/O).

Common follow-ups. Image layers are cached; docker compose runs multi-container apps; data persists via volumes (a container is ephemeral by default); and OCI standardizes the image format (image-spec), the runtime (runtime-spec), and the registry distribution protocol (distribution-spec) — these three specifications keep the ecosystem interoperable.