Docker

What is Docker?

Docker is the platform that popularized containers — a way to package an application together with all its dependencies (libraries, runtime, system tools, config) into a single portable image that runs identically on any machine with a container runtime. You define the image with a Dockerfile, build it once, and run it the same way on a laptop, a CI server, or production in the cloud. Docker didn’t invent the underlying Linux primitives (namespaces and cgroups), but it wrapped them in a developer experience so good that it became the foundation of modern application deployment and the reason “it works on my machine” stopped being an excuse.

Containers vs virtual machines — the distinction that matters

The concept to nail is containers versus VMs, because it explains why containers took over. A virtual machine virtualizes hardware and runs a full guest operating system on top of a hypervisor — strong isolation, but heavy: each VM carries a whole OS, takes gigabytes, and boots in minutes. A container virtualizes the operating system, not the hardware: containers share the host’s kernel and isolate only the process, filesystem, and network views. The result is dramatically lighter — containers are megabytes not gigabytes, start in milliseconds not minutes, and pack far more densely onto a host. The tradeoff is that containers share the host kernel, so their isolation is weaker than a VM’s hardware-level separation (which is why multi-tenant platforms sometimes run containers inside lightweight VMs for defense in depth). The mental model: a VM is a whole computer; a container is a well-isolated process with its dependencies bundled. This lightness is what made containers the practical unit of deployment for microservices, CI/CD, and cloud-native systems.

Docker vs Kubernetes, and the security realities

A pervasive confusion worth clearing up: Docker and Kubernetes are not competitors — Docker (or another runtime) builds and runs individual containers; Kubernetes orchestrates many containers across many machines (scheduling, scaling, healing, networking, service discovery). You use them together: Docker to package, Kubernetes to run at scale. (Kubernetes even dropped direct Docker-runtime support in favor of the standard CRI, but Docker-built images still run everywhere because they follow the OCI image standard.) On the practical side, the things teams get wrong are mostly about images: bloated images (starting from a full OS base instead of slim/distroless, or not using multi-stage builds, producing gigabyte images that are slow to pull and ship a large attack surface); security (running containers as root, embedding secrets in image layers where they’re permanently visible, or using unscanned base images full of known CVEs); and statefulness (treating containers as durable when they’re ephemeral — anything that must persist belongs in a volume or external store, since a container’s writable layer vanishes when it’s replaced). Image scanning, minimal base images, non-root users, and multi-stage builds are the baseline hygiene.

What people get wrong

• Thinking Docker and Kubernetes compete — Docker builds/runs containers; Kubernetes orchestrates them at scale; they’re complementary, used together.
• Bloated, insecure images: full-OS bases, root users, and embedded secrets produce huge, vulnerable images — use slim/distroless bases, multi-stage builds, non-root, and scanning.
• Treating containers as persistent — the writable layer is ephemeral and disappears on replacement; durable data must live in volumes or external stores.

Primary source: Docker documentation