DevOps

Containerization

A lightweight virtualization method that packages applications with their dependencies into isolated containers, ensuring consistent behavior across environments.

Containerization packages an application and all its dependencies (libraries, runtime, config files) into a standardized unit called a container. Unlike virtual machines, containers share the host OS kernel, making them lightweight and fast to start.

Docker is the most popular containerization platform. A Dockerfile defines the container image — the base OS, dependencies to install, files to copy, and the command to run. Images are stored in registries (Docker Hub, GitHub Container Registry, AWS ECR).

Key benefits include environment consistency ("works on my machine" → works everywhere), isolation (each container is independent), portability (run anywhere Docker is installed), and efficient resource usage (containers are much lighter than VMs).

Docker Compose manages multi-container applications locally (e.g., app + database + cache). For production, container orchestration platforms like Kubernetes handle scaling, networking, health checks, and rolling deployments across clusters.

How it works

A container is an ordinary process on the host with isolation applied. Docker's own documentation describes it as simply an isolated process with all of the files it needs to run.

On Linux the isolation comes from kernel namespaces, each of which wraps a global resource so the processes inside see their own instance of it: PID (process IDs), network (devices, stacks, ports), mount (mount points), UTS (hostname), IPC, user (user and group IDs), cgroup and time. Control groups (cgroups) separately cap how much CPU and memory the process may use.

The files come from an image: a read-only, layered filesystem built from a Dockerfile, where each instruction produces a layer. Layers are cached and shared, so a rebuild after a code change only redoes the layers after the changed line, and images that share a base only download the layers they do not already have.

Because every container on a host shares that host's kernel, starting one costs about as much as starting a process, and many fit on one machine. It also means a Linux container needs a Linux kernel, which is why Docker Desktop on macOS and Windows runs Linux containers inside a lightweight virtual machine.

Example

A Dockerfile for a small Node.js service, ordered so that dependency installs are cached between builds.

FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
docker build -t my-api .
docker run --rm -p 3000:3000 my-api

The package files are copied and installed before the rest of the source. When only application code changes, Docker reuses the cached npm ci layer and rebuilds in seconds; copying everything first would reinstall dependencies on every build.

Common confusion

What is the difference between a container and a virtual machine?

A virtual machine runs a full operating system with its own kernel and drivers on virtualised hardware. A container is an isolated process that shares the host's kernel. Containers are lighter and start faster; virtual machines give a stronger isolation boundary and can run a different operating system from the host. The two are often combined, with containers running inside cloud VMs.

Is Docker the same thing as a container?

No. Docker is one popular set of tools for building, sharing and running containers. Container images follow the open OCI image format, so the same image can be run by other runtimes, and Kubernetes runs containers through a container runtime without needing the Docker command-line tool.

Further reading

Want to learn more?

Explore more developer terms or read in-depth articles on the blog.

Browse all terms