For a long time, Docker felt for me like a collection of mysterious commands copied from StackOverflow.
I knew the basics:
docker build
docker run
docker ps
But if someone asked me what Docker actually was, I would probably say something vague like:
“It packages your app so it runs everywhere.”
Technically correct.
Not very helpful.
Docker finally clicked when I understood one simple mental model.
The Real Problem Docker Solves
If you’ve worked on any team project long enough, you’ve probably heard this conversation:
“It works on my machine.”
“Well… it doesn’t work on mine.”
Different operating systems.
Different library versions.
Different runtime environments.
A Node project might work perfectly on one laptop but fail on another because someone installed a slightly different version.
Multiply that problem across teams, staging servers, CI pipelines, and production infrastructure.
That’s where Docker comes in.
Docker lets you package everything your application needs:
- the runtime
- system libraries
- dependencies
- configuration
- the application itself
All of it goes into a single isolated unit.
That unit is called a container.
The Mental Model That Made Docker Click
The analogy that made this make sense for me comes from the shipping industry.
Before standardized containers existed, cargo shipping was chaotic.
Ships carried:
- wooden crates
- barrels
- sacks
- oddly shaped equipment
Every time cargo moved from a ship to a truck or train, workers had to handle each item individually.
Then shipping containers were introduced.
Everything goes into the same standardized box.
Ships move the box.
Trucks move the box.
Trains move the box.
Nobody touches what’s inside.
Docker applies that exact idea to software.
Instead of shipping code and hoping the environment matches, you ship a container that already includes the entire environment.
Your laptop.
Your teammate’s machine.
A cloud server.
Same container. Same behavior.
The Three Docker Concepts That Matter
Once the mental model clicked, the core pieces of Docker became much easier to understand.
1. Images
A Docker image is the blueprint.
It describes everything needed to run an application:
- which base system to start from
- which packages to install
- which files to copy into the environment
- what command should run when the container starts
Think of an image as a template.
2. Containers
A container is a running instance of an image.
One image can create many containers.
A simple analogy:
- Image → cookie cutter
- Container → cookie
3. Registries
A registry is where Docker images are stored.
The most popular one is Docker Hub, which acts like a huge library of prebuilt environments.
Need a database?
There’s an image for that.
Need a web server?
There’s an image for that too.
The Moment Docker Usually Clicks
Docker usually makes sense when you run your first real container.
For example, this single command launches a full web server:
docker run -d -p 8080:80 nginx
Let’s break that down.
docker run
Creates and starts a container.
d
Runs it in the background.
p 8080:80
Maps port 8080 on your machine to port 80 inside the container.
nginx
The image that contains the web server.
Once it starts, open your browser and go to:
localhost:8080
And just like that, you’re running a real Nginx server.
No manual installs.
No system configuration.
One command.
That’s when Docker usually clicks.
What Happens Behind the Scenes
When you run a container, Docker automatically:
- checks if the image exists locally
- downloads it if needed
- creates the container environment
- starts the process inside the container
The container runs until the process stops or you shut it down.
You can inspect running containers with:
docker ps
And see all containers, including stopped ones, with:
docker ps -a
A Full Beginner Walkthrough
I recently recorded a full beginner walkthrough where I explain:
- what Docker actually is
- images vs containers
- running your first container
- launching an Nginx web server
- basic container management
Everything happens live in the terminal so you can follow along step by step.
If you're interested, you can watch it here:
Curious About Your Experience
Docker tends to "click" at different moments for different people.
For some it's when they run their first container.
For others it's when they build their first image.
I'm curious:
When did Docker finally make sense for you?
Top comments (0)