Container

A container is just a normal Linux process that the kernel has fenced off so it behaves as if it has the machine to itself. It sees its own filesystem, its own process tree, its own network interface, and a capped slice of CPU and memory, but it is still running directly on the host kernel. There is no second operating system inside it.

This is the key difference from a virtual machine. A VM runs a full guest OS on top of a hypervisor, so it carries its own kernel, system services, and gigabytes of disk. A container ships only the application and its dependencies, often 10 to 200 MB, and reuses the kernel already running on the host. That is why a container can start in under a second while a VM takes tens of seconds to boot.

A container starts from an image, which is a read-only, layered snapshot of a filesystem. The image is built once and runs the same way on a laptop, a CI server, or production. This is what people mean when they say containers solve the works on my machine problem.

Isolation comes from two Linux kernel features. Namespaces give each container its own view of system resources: the PID namespace makes the container's first process look like PID 1, the mount namespace gives it a private filesystem, and the network namespace gives it its own IP stack. Cgroups (control groups) enforce limits, so a container can be capped at, say, 0.5 CPU and 256 MB of RAM and cannot starve its neighbors.

The image itself is built in layers. Each instruction in a Dockerfile (install a package, copy your code) creates a new layer stacked on the previous one using a union filesystem like overlayfs. Layers are content-addressed and cached, so if two images both start from the same Ubuntu base, that base is stored and pulled only once.

At runtime a container engine such as containerd or CRI-O talks to a low-level runtime like runc, which calls the kernel to set up the namespaces and cgroups and then execs your process. Docker is the most familiar tool, but it is a friendly wrapper around these same standardized pieces defined by the Open Container Initiative (OCI).

Containers are the right tool when you want fast, repeatable deployments, dense packing of many services onto one host, and a clean handoff between development and operations. They are the foundation of microservices and the unit that orchestrators like Kubernetes schedule, scale, and restart.

The trade-offs are real. Because containers share the host kernel, a kernel-level exploit can in theory break out of the isolation, which is weaker than a VM's hardware-enforced boundary. Multi-tenant platforms that need stronger separation use lightweight VMs such as Firecracker or gVisor underneath. Containers are also designed to be stateless and disposable, so stateful workloads like databases need explicit volumes and care.

A container should run one main process and write logs to stdout rather than acting like a tiny server you SSH into. If you find yourself running an init system and three daemons inside one container, you probably want either separate containers or a VM.

Say you have a Node.js API. You write a Dockerfile that starts FROM node:20-slim, copies in your package.json, runs npm install, copies your source, and sets the start command. You run docker build to produce an image, push it to a registry like Docker Hub or Amazon ECR, and now any machine can pull and run that exact image.

On your laptop you run one copy with docker run. In production, Kubernetes pulls the same image and runs twenty copies across several nodes, restarts any that crash, and rolls out a new version by swapping the image tag with zero downtime. The application code never changed between those environments; only the number of running copies did.