Docker

Docker is a tool for building and running containers. A container is a process that runs in its own isolated view of the filesystem, network, and process tree, but shares the host machine's kernel. You describe what goes inside with a Dockerfile, build that into an image, and run the image to get a container.

An image is a read-only template: a stack of filesystem layers holding your code, the language runtime, system packages, and a startup command. A container is a running instance of an image with a thin writable layer on top. The same nginx image you pull on a Mac runs byte-for-byte the same on a Linux server, which is what kills the 'works on my machine' problem.

Docker is often confused with virtual machines. A VM ships an entire guest operating system and boots in tens of seconds, often using gigabytes of RAM. A container ships only your app and its dependencies, shares the host kernel, starts in well under a second, and a typical Alpine-based image is 10 to 50 MB instead of several gigabytes.

On Linux, Docker leans on three kernel features. Namespaces give each container its own isolated view of process IDs, network interfaces, mount points, and hostnames, so a process inside thinks it owns the machine. Control groups, called cgroups, cap how much CPU, memory, and I/O a container can use. Union filesystems like OverlayFS stack the read-only image layers and the writable container layer into one view.

Images are built layer by layer. Each instruction in a Dockerfile, such as RUN apt-get install or COPY, creates a new layer that is cached and content-addressed by a SHA-256 hash. If a layer has not changed, Docker reuses the cache and skips the work, which is why a rebuild after a one-line code change finishes in seconds instead of minutes. Layers are also shared across images, so ten images built on the same base only store that base once.

On macOS and Windows there is no Linux kernel, so Docker Desktop runs a lightweight Linux VM in the background and your containers run inside it. The day-to-day commands are the same: docker build, docker run, docker push to a registry like Docker Hub, and docker pull to fetch an image somewhere else.

Reach for Docker when you want one artifact that runs the same everywhere: local development, continuous integration, staging, and production. It shines for microservices where each service has different dependency versions, for reproducible CI builds, and as the unit that orchestrators like Kubernetes schedule and scale.

The trade-offs are real. Containers share the host kernel, so isolation is weaker than a VM; a kernel exploit can cross the boundary, which is why untrusted multi-tenant workloads sometimes add a sandbox like gVisor or Firecracker. Persistent data needs deliberate handling through volumes because a container's writable layer is thrown away when it stops. Stateful services and GPU or kernel-module workloads need extra care.

Docker by itself runs containers on one host. Running them across a fleet, restarting failed ones, rolling out new versions, and load balancing is the job of an orchestrator. In practice teams build images with Docker and then hand them to Kubernetes, AWS ECS, or Nomad to run at scale.

Say you have a Node.js API. A Dockerfile starts FROM node:20-alpine, copies package.json, runs npm install, copies the source, and ends with CMD node server.js. You run docker build -t my-api:1.0 . and get an image. docker run -p 3000:3000 my-api:1.0 starts it and maps port 3000 to your machine. A teammate on Windows pulls the same image and gets an identical runtime, no Node version mismatch and no missing system library.

Push that image to a registry and your CI pipeline pulls the exact same bytes to run tests, then production pulls the exact same bytes to serve traffic. There is no separate build for each environment, which removes a whole class of deployment bugs.

This is the model behind nearly every modern deployment. A 50 MB image starting in under a second lets a platform pack hundreds of containers onto one server and spin up new copies in response to traffic spikes far faster than booting new virtual machines.