DOCKER

Here's a follow-up post continuing the series — same voice, picking up where the Linux post left off:

Docker Made Sense the Day I Stopped Treating It Like Magic

After my last post on falling in love with Linux, a few people asked the obvious next question: "okay, but when do I actually get to Docker?"

Here's the honest answer — I jumped into Docker way too early the first time, before Linux made sense, and it felt like memorizing spells. docker run. docker build. docker-compose up. Things worked when I copy-pasted commands, and broke in ways I couldn't explain when I didn't. It wasn't until I understood Linux processes, filesystems, and networking that Docker stopped being magic and started being obvious.

Docker Isn't a New Thing. It's a Trick on Top of Old Things.

This was the single biggest unlock for me: Docker isn't some separate virtual computer running inside your computer. A container is just a regular Linux process, with some clever isolation layered on top — its own view of the filesystem, its own network namespace, its own process tree. That's it.

Once I understood that, questions that used to confuse me stopped being mysterious:

• "Why does my container see a different filesystem?" — because of Linux namespaces, not because Docker built a tiny VM.


• "Why did my container die immediately after starting?" — because the one process it was running exited, and containers live and die with their main process, just like any other Linux process.


• "Why is my container using so much memory?" — because cgroups are throttling or reporting resource usage, the same mechanism Linux itself uses.

Docker didn't invent isolation. It packaged existing Linux features into something usable.

The Commands That Actually Matter Here Too

Same philosophy as the Linux post — don't memorize everything, get fluent in a small core set first.

Building and running:

docker build -t myapp .

docker run -p 3000:3000 myapp

Seeing what's actually going on:

docker ps          # what's running right now

docker ps -a       # what's running or has exited

docker logs -f myapp   # this is your tail -f from the Linux post

Getting inside a running container to debug it:

docker exec -it myapp /bin/bash

The first time I ran this and realized I was just... inside a normal Linux shell, looking at normal Linux files, using the same ls, cat, and grep I'd already learned — that's when Docker really clicked. It wasn't a new skill. It was the same skill, in a slightly different box.

Cleaning up (because disk space disappears fast):

docker system prune

docker image prune

Why This Sets You Up for Kubernetes

Here's the part that made the next step obvious: Kubernetes doesn't run "apps." It runs containers. Every pod is one or more containers, scheduled onto a node, which is — you guessed it — a Linux machine. The docker logs, docker exec, and resource concepts you just learned map almost directly onto kubectl logs, kubectl exec, and Kubernetes resource limits.

Learn Docker on top of Linux, and Kubernetes stops looking like a new mountain. It starts looking like the same mountain, just with more automation strapped onto it.

What I'd Tell Someone Starting Docker Today

Don't start with Docker Compose and fifteen services wired together. Start with one container. Build it. Break it. Exec into it and poke around like it's just another Linux box — because it is. Once building and debugging a single container feels boring and routine, multi-container setups and orchestration stop being scary and start being the next logical step.

Next up: I'll go through the CI/CD pipeline basics I wish I'd understood before I started copy-pasting YAML from Stack Overflow.