A Beginner's Guide to Docker

If you’ve ever yelled at your computer because “it worked on my machine,” hey, welcome. You’re not alone. Every developer, from the bright-eyed intern to the CTO juggling a dozen microservices, has run headfirst into environment hell. And that’s where Docker walks in like the calm friend who actually knows how to fix things, not just complain about them.

But what is Docker, really? Why is everyone talking about containers like we’ve all suddenly become digital lunch packers? And most importantly—how do you use it without spiralling into config-file-induced madness?

Pull up a chair. We’re breaking Docker down piece by piece, without sounding like a DevOps textbook had a nervous breakdown.

So… What Exactly Is Docker?

Let’s start with a simple one-liner: Docker is a tool that lets you package up your application along with everything it needs to run—dependencies, system tools, settings—into something called a container.

Think of a container like a shipping container. It doesn’t care what’s inside—Python app, Node project, a tiny Go binary that could take over the world—it wraps it all up neatly, so you can ship it anywhere without worrying about what’s on the other side.

No more “works on my machine” drama. No more weird bugs because someone had an older version of libxml installed. With Docker, you get consistency, plain and simple.

Containers vs. Virtual Machines: What's the Difference?

Quick detour here—because folks get this part tangled up all the time.

Containers aren’t VMs. They're lighter, faster, and don’t come with all the baggage. Imagine a virtual machine like renting a whole apartment just to boil some pasta. You’ve got your own walls, plumbing, kitchen—even if you’re just using a single burner.

Now, a container? That’s like sharing a kitchen in a co-working space. Everyone brings their own pan, their own spices, and just cooks their stuff—without needing an entire building.

Docker uses the host machine’s kernel but isolates everything else. That makes containers super fast to start and way less resource-hungry.

Installing Docker (Without the Tears)

Let’s keep this part short because installing Docker shouldn’t be an ordeal—and thankfully, it isn’t.

Mac & Windows

You’ll want Docker Desktop. Head to https://www.docker.com/products/docker-desktop, download the version for your OS, and follow the installer. It’s GUI-based, so even if you’re allergic to the terminal, you’ll survive.

Linux

You’ve got a few options depending on your distro, but for most Ubuntu folks:

sudo apt update sudo apt install docker.io sudo systemctl start docker sudo systemctl enable docker 

And don’t forget to add yourself to the Docker group if you don’t want to use sudo every time:

sudo usermod -aG docker $USER 

Log out and back in—then you’re good to go.

Let’s Build Your First Container (You Got This)

Okay, let’s say you’ve got a small Python script—maybe a Flask app or something that just says "Hello, Docker!"

Here’s the thing: You can run that inside a container without installing Python on your host. That’s the magic.

1. Your App

Create a file called app.py:

print("Hello from inside the container!") 

2. Your Dockerfile

Now, create a Dockerfile (no extension) in the same directory:

FROM python:3.13 COPY app.py . CMD ["python", "app.py"] 

This tells Docker:

• Use the official Python 3.13 image
• Copy your script into the container
• Run it with Python

3. Build the Image

From your terminal:

docker build -t hello-docker . 

This packages everything into an image named hello-docker.

4. Run It!

docker run hello-docker 

And boom. You should see:

Hello from inside the container! 

That’s it. No Python installed locally. No setup scripts. Just your app, running clean.

The Docker Commands You’ll Actually Use

Docker has a bunch of commands—but you only need a few to get rolling.

• docker build -t <name> . — Build an image from your Dockerfile

• docker run <name> — Start a container

• docker ps — Show running containers

• docker stop <container_id> — Stop one

• docker images — List all images

• docker rmi <image_id> — Remove an image

• docker exec -it <container_id> bash — Jump inside a container (like SSH)

You’ll pick up more as you go, but these are your bread and butter.

Real Talk: Why Bother With Docker?

You know what? Let’s pause here. Because this isn’t just about tools—it’s about sanity.

Docker saves you from:

• The “it works for me” nightmare

• Dependency hell (pip vs conda vs NPM vs...whatever Rust is doing)

• Slow onboarding (give a new hire one command and they’re good)

• Weird bugs that show up only in production

It also lets you simulate production environments, test your app in different setups, and—if you’re building for the cloud—Docker is practically a requirement. Kubernetes? CI/CD? Cloud functions? They all play nice with containers.

But Wait—Where Do Images Live?

Just like code lives on GitHub, Docker images often live on Docker Hub (or private registries like GitHub Container Registry, Amazon ECR, etc.)

Once you’ve built an image, you can push it like this:

docker tag hello-docker yourusername/hello-docker docker push yourusername/hello-docker 

Boom—it’s now sharable, portable, and versioned like the rest of your stack.

A Few Gotchas (Because Nothing’s Perfect)

Okay, before we wrap, some friendly heads-ups:

• Volumes — Containers are ephemeral. If you need persistent data (like database files), you’ll want to mount volumes.

• Networking — Containers are isolated. If you’ve got multiple services talking to each other, you’ll need to configure Docker networks.

• Image Size — Some base images are huge. Look for -slim versions or consider Alpine Linux for tiny builds.

• Build Context — Be careful with what you copy into your container. Don’t accidentally ship your .env or node_modules.

None of these are dealbreakers—they're just the kind of stuff that bites when you’re not looking.

Final Thoughts (And a Bit of Tough Love)

Look—Docker isn’t magic. It won’t fix bad code, poor planning, or your coffee addiction.

But it will make your life a lot easier. It’s one of those tools that—once you’ve used it a few times—feels like cheating. You package your app, run it anywhere, and move on with your life. Clean. Consistent. Done.

And sure, you’ll hit snags. Everyone does. But with a bit of tinkering and curiosity, Docker becomes second nature. Like git—but less terrifying (most of the time).

So go ahead—containerize something small. Doesn’t matter what. A Flask app. A static site. Even a Node script that tells jokes. Just build it, run it, and see what happens.

You’ll be surprised how much smoother everything starts to feel.

Next up? Maybe orchestrating containers with Docker Compose. Or playing with Kubernetes. But for now—breathe. You’ve made it this far. And honestly? That’s already something to be proud of.

- Josh