Fig 1Containers & imagesBoot, build, push, run, then kill a hostno image yet · 0 running
FROM node:20-slim # base layer: a minimal OS userland, not a kernel
WORKDIR /app
COPY package*.json ./
RUN npm ci # dependencies: cached until package.json changes
COPY . . # your code: changes often, so it comes late
CMD ["node", "app.js"]
Layers: each Dockerfile instruction adds a read-only layer; unchanged layers come from cacheLamps: a VM or container that has finished startingDots: an image being pushed to the registry or pulled by a hostA virtual machine carries a whole operating system, so it is heavy and slow to start. A container is an isolated process that shares the host's kernel, so it starts in moments and many fit on one machine. It runs from an image: read-only layers built from a Dockerfile, cached so a rebuild only redoes what changed, and pushed to a registry so any host can pull and run it. Running containers on many machines by hand is imperative and fragile: when a host dies, nothing brings its containers back. An orchestrator like Kubernetes is declarative: you state what should run, and it keeps making that true.