Docker Explained Without the Jargon: What Containers Actually Are

A Docker image is a static, layered snapshot — a blueprint. It contains the OS filesystem, installed packages, application code, and startup instructions, but it's not running. An image is like a class definition in programming. A container is a running instance of an image — it's the class instantiated. You can run multiple containers from the same image simultaneously, each isolated from the others. When you stop a container, it stops; when you remove it, it's gone, but the image persists. Building an image is a one-time (or occasional) step; running containers from it is the operational step.

Virtual machines emulate complete hardware and run a full guest operating system kernel. A VM for Ubuntu on a macOS host runs the entire Ubuntu kernel, which then runs your application on top. This provides strong isolation but consumes significant resources — a VM might use 1-2 GB of RAM before your application even starts. Docker containers share the host OS kernel and only package the application and its dependencies. A container might use 50 MB overhead instead of 2 GB. The tradeoff is that all containers on a host share the same kernel, so a kernel-level exploit affects all containers. VMs are more isolated; containers are more efficient.

A Dockerfile is a text file that specifies how to build a Docker image, one instruction at a time. Each instruction creates a new layer in the image. The most important instructions are: FROM (the base image to start from, like node:20-alpine or python:3.12-slim); WORKDIR (sets the working directory inside the container); COPY or ADD (copies files from your local machine into the image); RUN (executes a command during the build, like npm install or apt-get install); EXPOSE (documents which port the container listens on — doesn't actually publish the port); CMD or ENTRYPOINT (specifies what command to run when the container starts). Layer ordering matters: put frequently changing instructions (like COPY . .) after rarely changing ones (like RUN npm install) to maximize build cache reuse.