What Docker is, and why
The problem containers solve, in plain terms.
Almost every developer has hit the same wall: the app runs perfectly on your laptop and falls over on a colleague’s machine or in production. The cause is almost always the environment — a different language version, a missing library, a config that only exists on your box. Docker’s answer is to package the application together with everything it needs to run — the runtime, libraries, and settings — into a single unit called a container that behaves the same everywhere.
A container is just a process running on your machine, but one that has been given its own isolated view of the filesystem, network, and process list. It is not a virtual machine and it does not carry its own operating system; it borrows the kernel of the host it runs on, which is why it starts in a fraction of a second and weighs megabytes instead of gigabytes.
Why it caught on
Three properties made Docker take over. Consistency: the same image runs on a laptop, a CI runner, and a production server, so a whole class of environment bugs disappears. Speed and density: because containers share the host kernel, one machine can run dozens of them and each starts almost instantly. Isolation: each container has its own filesystem and process space, so two apps that need conflicting library versions can coexist without a fight.
# one command: fetch a web server image and run it, no install, no config$ docker run -d -p 8080:80 nginx:1.27Unable to find image 'nginx:1.27' locally1.27: Pulling from library/nginx ... donea1b2c3d4e5f6...$ curl -s localhost:8080 | head -1<!DOCTYPE html>