The Feynman Guide to Docker

Have you ever tried to run a piece of software on a friend's computer, only for it to fail immediately? You scratch your head, look at your screen, and say those infamous words:

"But it works on my machine!"

The other person sighs. "Well, we aren't shipping your machine to production, are we?"

For decades, this was the ultimate headache of software engineering. An application would work perfectly on a developer's laptop, but break on the test server, and blow up in production.

To solve this, the tech world created Docker. Let's use the Richard Feynman Technique—translating complex technical concepts into simple, everyday analogies—to understand exactly how Docker works, why it is so powerful, and how to use it.

1. The Packaging Problem: The Shipping Container Analogy

To understand Docker, we first need to look at the history of global shipping.

Before the 1950s, cargo was a mess. If you wanted to ship whiskey, piano keys, bags of coffee, and bags of flour from New York to London, workers (stevedores) had to manually load every single crate, barrel, and sack onto the ship.

This was slow, expensive, and risky. The whiskey barrels could leak onto the sacks of flour, or the piano keys could be crushed by heavy crates.

Then came the standardized shipping container.

Instead of worrying about how to pack piano keys vs. whiskey barrels, we put everything into identical metal boxes of the exact same size. The crane at the dock doesn't care what's inside the container; it only cares that the container has standard corner locks and fits on the ship, train, or truck.

Docker does the exact same thing for software.

Instead of shipping your raw code and hoping the server has the right version of Node.js, Python, or database libraries, you pack your code, runtime, system libraries, and settings into a standardized Docker Container.

The server running Docker doesn't care if your container holds a complex Java app or a simple HTML site. It just runs the container.

2. Virtual Machines vs. Containers: The Hotel vs. The Apartment Complex

Before Docker, we isolated applications using Virtual Machines (VMs). Let's compare them using a housing analogy:

Virtual Machines: The Hotel

A VM is like a hotel. Every guest (application) gets their own fully isolated room. But that room also comes with its own private bathroom, kitchen, plumbing, and structural walls. In tech terms, a VM bundles your app with a complete Guest Operating System (OS).

• The Problem: Guest OSs are huge. They take gigabytes of space, consume lots of memory just to idle, and take minutes to start up.

Docker Containers: The Co-Living Apartment Complex

A Docker Container is like a room in a co-living apartment complex. Every resident (application) has their own private, locked bedroom (isolated user space), but they share the central heating, water pipes, foundation, and main door. In tech terms, containers share the Host OS Kernel (the core engine of the operating system).

• The Benefit: Because containers don't need their own heavy Guest OS, they start up in milliseconds, take up megabytes instead of gigabytes, and allow you to run dozens of apps on a single machine.

3. Images vs. Containers: The Blueprint vs. The House

Two terms you will hear constantly are Image and Container. The easiest way to separate them is to think of them as a Blueprint and a House.

• Docker Image (The Blueprint): This is a read-only template containing the instructions to build your environment. It describes exactly what operating system to start with, what packages to install, and where your code lives. You cannot change an image once it is built.
• Docker Container (The House): This is the active, running instance of the image. Just like you can build five identical houses from a single blueprint, you can run five identical containers from a single Docker image.

4. Layer Caching: The Stack of Transparent Sheets

How are Docker images actually constructed? They are built using Layers.

Think of a Docker image as a stack of transparent acetate sheets laid on top of one another.

1. Layer 1 (Bottom): You lay down a sheet that says "Start with Ubuntu Linux."
2. Layer 2: You lay down a sheet on top that says "Install Node.js."
3. Layer 3: You lay down a sheet that says "Copy our application code."
4. Layer 4 (Top): You lay down a sheet that says "Run the start script."

When you look down from the top, you see the combined picture: a running Node.js app on Ubuntu.

The Power of Layer Caching

Because these layers are read-only and stacked, Docker is smart. If you change a line of code in your app and rebuild the image, Docker looks at the layers:

• "Did Ubuntu change?" No. Reuse Layer 1 cache.
• "Did Node.js version change?" No. Reuse Layer 2 cache.
• "Did the app code change?" Yes! Rebuild Layer 3 and 4.

This makes builds incredibly fast, but only if you write your Dockerfile correctly.

The Golden Rule of Dockerfile Optimization

Always copy files that change rarely (like dependency files) before copying files that change frequently (like source code).

# GOOD Dockerfile practice
FROM node:18-alpine

WORKDIR /app

# Copy dependency configs first
COPY package.json package-lock.json ./
RUN npm install  # This heavy step is now cached!

# Copy the rest of the application
COPY . .

CMD ["npm", "start"]

If you copied your entire codebase before running npm install, any minor comment change in your code would invalidate the cache, forcing Docker to download all your Node modules from scratch every time!

5. Data Persistence: Volumes (The External Hard Drive)

By default, Docker containers are ephemeral—meaning they are temporary.

Think of a container like a hotel room. While you are there, you can move the chairs, put clothes in the closet, and write notes on the desk pad. But when you check out (stop the container), the maids clean the room, discarding anything you left behind. The next guest gets a completely fresh room.

If your application is a database, you cannot afford to lose your data every time a container restarts.

To solve this, Docker uses Volumes.

A Volume is like an external USB hard drive. You plug it into the container and tell the database app to write its files directly to that external drive.

Even if the container is deleted, crashed, or upgraded, the external drive (volume) remains plugged into the host machine, keeping your data perfectly safe.

6. Container Networking: The Apartment Intercom

By default, containers live in absolute isolation. They are locked rooms. If you run a web app inside container A on port 80, your computer (the host) cannot reach it, and container B (a database) cannot talk to it either.

To connect them, Docker uses Bridged Networks and Port Mapping.

Port Mapping (-p 8080:80)

Think of port mapping like a doorman or mail redirect service. When you run:

docker run -p 8080:80 my-web-app

You are telling your computer: "Whenever anyone calls door number 8080 on my main building (the host computer), route that call straight to apartment room 80 inside the container."

Bridge Networks

When you run multiple containers (e.g., a frontend app, a backend API, and a database) and want them to talk to each other, you place them on the same Docker Network. Docker automatically assigns them internal DNS names, letting Container A call http://database:5432 without needing to know the host's actual IP address.

Summary: The Docker Cheat Sheet

To wrap it up, here is how the physical world maps to the virtual world of Docker:

• Container (Standardized Shipping Box): Ensures code runs identically on any machine.
• Virtual Machine (Private Hotel Room): High isolation but heavy resource footprint.
• Docker Image (Blueprints / Recipe): Read-only static template for containers.
• Layer Caching (Stack of Acetate Sheets): Reuses unchanged layers to speed up builds.
• Volume (External USB Hard Drive): Keeps database files safe when containers die.
• Port Mapping (Main building buzzer routing): Connects host traffic to container interior.

Mastering Docker is the first step to building modern, cloud-native systems. Next time you encounter a deployment error, don't ship your machine—ship the container.

References & Further Reading

This guide is inspired by the foundational lessons and workflows of leading DevOps educators:

• Docker Crash Course by TechWorld with Nana (Videos: Docker Crash Course for Beginners & Docker Tutorial for Beginners).
• Complete Docker Course - From BEGINNER to PRO! by DevOps Directive (Video: DevOps Directive Course).