There is a sentence that every Junior Developer says at least once. It’s the sentence that makes Senior Engineers sigh and rub their temples.
"But it works on my machine!"
You wrote the code. You tested it on your laptop. It worked perfectly. Then you pushed it to the server, and it crashed. Why?
Maybe you have Python 3.10, and the server has Python 3.8.
Maybe you are on a Mac, and the server is Linux.
Maybe you installed a library three months ago and forgot to put it in your requirements.txt.
This is called Environment Drift, and it is a nightmare.
The solution is Docker.
The Shipping Container Analogy
Before 1950, shipping goods was a disaster. You had barrels of whiskey, sacks of flour, and loose furniture. Loading them onto a ship took forever because every item was a different shape.
Then, the standardized Shipping Container was invented.
It didn't matter what was inside (cars, grain, TVs). The container was always the exact same size. The crane didn't need to know what was inside; it just needed to lift the box.
Docker does this for code.
It creates a digital "Container" that holds everything your app needs:
The Operating System (e.g., a tiny version of Linux).
The Code.
The Libraries.
The Environment Variables.
When you ship your app, you don't ship just the code. You ship the whole box. If it runs on your laptop, it is mathematically guaranteed to run on the server, because the environment inside the box never changes.
The 3 Concepts You Need to Know
Forget the complex commands for a second. Understand these three words:
Dockerfile (The Recipe): A text file that tells Docker how to build your box. ("Start with Linux, install Python, copy my files, run this command").
Image (The Blueprint): When you run the recipe, you get an Image. This is a frozen snapshot of your app. It cannot be changed.
Container (The House): When you actually run the Image, it becomes a Container. This is the live, running application.
A Real World Example
Let's say you have a simple Python script.
Without Docker:
You tell your friend, "Install Python, then run pip install requests, then run python main.py."
(This fails if they have the wrong Python version).
With Docker:
You write a Dockerfile:
Step 1: Use a standard Python environment
FROM python:3.9-slim
Step 2: Create a folder inside the container
WORKDIR /app
Step 3: Copy our dependencies file
COPY requirements.txt .
Step 4: Install the dependencies inside the container
RUN pip install -r requirements.txt
Step 5: Copy our code
COPY . .
Step 6: The command to run the app
CMD ["python", "main.py"]
Now, your friend just types:
docker build -t my-app .
docker run my-app
It works instantly. No installing Python. No version conflicts. It just works.
Summary
Docker isn't just for DevOps engineers. It is for anyone who values their sanity.
It forces you to document your dependencies explicitly. It allows you to onboard new developers in minutes, not days.
If you want to be a professional software engineer, stop relying on your local setup. Containerize everything.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com
Top comments (0)