I'll be honest: I had read about Docker containers probably five times before anything clicked. The diagrams made sense in isolation, but I couldn't picture how a real application actually used any of it. What does a network between containers look like in practice? What does a volume actually do?

For one of our DevSecOps assignments, we were pointed to Samuel Nartey's DockerQuiz project — a Kahoot-style Docker quiz that is itself a fully containerized 3-container application. The premise was simple and smart: learn Docker by running Docker, not by reading about it.

This is my honest write-up of building it, breaking it, and what I actually learned along the way.

What the Project Is

DockerQuiz is a Flask web app that quizzes you on Docker concepts. But the real lesson isn't the quiz — it's the infrastructure underneath it.

When you run docker compose up, three containers spin up and connect over a private network:

• quiz-app — the Flask application serving the quiz at localhost:5000
• mongo — a MongoDB instance storing your profiles, scores, and session state
• mongo-express — a web UI for browsing MongoDB live at localhost:8081

┌─────────────────────────────────────────────────────────────────┐
│                     quiz-network  (bridge)                      │
│                                                                 │
│   ┌──────────────┐      ┌───────────────┐    ┌──────────────┐  │
│   │   quiz-app   │─────▶│     mongo     │◀───│mongo-express │  │
│   │ Flask :5000  │      │ MongoDB :27017│    │ Web UI :8081 │  │
│   └──────────────┘      └───────────────┘    └──────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Three separate containers. One shared network. One command to start everything.

Getting It Running

Prerequisites: Just Docker Desktop

No Python, no MongoDB, no Node.js installation needed. Everything runs inside containers. That alone felt like a small revelation — my machine didn't need to know anything about Flask or MongoDB. Docker handled all of it.

After cloning the repo and navigating into the project folder, I ran:

docker compose up --build

The first run took a few minutes — Docker was pulling the official mongo:7.0 and mongo-express:1.0.2 images from Docker Hub. After that, every subsequent run took a matter of seconds.

Once the terminal showed quiz-app | * Running on http://0.0.0.0:5000, I opened two tabs:

• http://localhost:5000 — the quiz
• http://localhost:8081 — Mongo Express

Three containers starting up via docker compose up --build

Playing the Quiz and Watching the Data

I created a profile — name, avatar, role — and started answering questions. What made this different from just reading a tutorial was that I could open Mongo Express on the side and watch my own data appear in real time.

Every answer I submitted updated a document in the quiz_states collection. When I finished, a full result document landed in results. It wasn't abstract anymore — I could see the Flask container writing to the MongoDB container, and browse it through a third container, all on the same local machine.

The quiz interface at localhost:5000

Mongo Express showing the live database at localhost:8081

_My profile document appearing in the profiles collection
_

My completed quiz result in the results collection

The moment that landed hardest was seeing this line in app.py:

MONGO_URI = "mongodb://mongo:27017/"

mongo isn't localhost. It's the service name from docker-compose.yml — and Docker automatically resolves it to the right container's IP address. That's Docker's built-in DNS. Containers discover each other by name, not by hardcoded addresses. It's the pattern used in virtually every real production deployment, and seeing it in a small project made it finally make sense.

The Experiment That Showed Me What depends_on Actually Does

The README has a section called Experiment and Break Things. I tried two of them.

Experiment 1 — Changing the Port Mapping

The first one was clean and immediate. I changed this line in docker-compose.yml:

# Before
ports:
  - "5000:5000"

# After
ports:
  - "8000:5000"

The format is HOST_PORT:CONTAINER_PORT. The container still listens on port 5000 internally — nothing inside Docker changes. But now my machine maps its port 8000 to that container port. So localhost:5000 stopped working and localhost:8000 served the app instead.

The quiz app now accessible at port 8000

Confirming the app loads correctly at localhost:8000

It's a small change, but it made port mapping tangible. The container's internal world is completely separate from what I expose on my machine.

Experiment 2 — Commenting Out depends_on

This one surprised me — and the surprise turned out to be the most educational part.

I commented out the depends_on block in docker-compose.yml so that quiz-app would no longer wait for mongo to be ready before starting:

  quiz-app:
    build: .
    # depends_on:
    #   - mongo

I expected chaos. The quiz app starting before the database — surely that would crash everything?

Commented out depends_on

_Terminal output after commenting out depends_on _

It... worked. The app came up fine.

Here's what I learned: depends_on only controls start order, not readiness. It tells Docker to start the mongo container before quiz-app, but it does not wait for MongoDB to actually be accepting connections. In practice, MongoDB often starts fast enough that it doesn't matter.

But the deeper reason everything stayed stable is in the app itself. app.py has a retry loop — it attempts to connect to MongoDB up to 5 times with 2-second gaps between attempts. So even without depends_on, the app just quietly retried until the database was ready. The resilience was already built in.

The lesson wasn't "comments depends_on is safe to remove." It was: retry logic in your application is what actually handles race conditions, not start order alone. depends_on is a hint, not a guarantee. Real-world applications can't assume the services they depend on will be available the moment they start — and this project demonstrates exactly how to handle that.

Stopping and Cleaning Up

# Stop containers, keep your data
docker compose down

# Stop containers AND wipe the database
docker compose down -v

The -v flag removes the named volume (mongo-data), which is where MongoDB persists your data between restarts. Without it, your quiz results survive a docker compose down and come back when you start again. With it, you're starting completely fresh.

Running docker compose down to stop all containers

What I Actually Walked Away Understanding

Before this project, I could define Docker concepts. After it, I understood them:

Container networking — Containers on the same network talk to each other by service name. mongo resolves to the MongoDB container because Docker's internal DNS makes it so. No IP addresses, no host machine involvement.

Port mapping — The container's internal port and the host port are completely independent. "8000:5000" means "my machine's 8000 talks to the container's 5000." Changing the host side changes nothing inside the container.

Named volumes — mongo-data:/data/db means data written inside the container at /data/db is actually stored in a Docker-managed volume on the host. That's why your quiz results survive a restart.

depends_on vs. actual readiness — Start order is not the same as service readiness. Your application needs to handle the case where its dependencies aren't immediately available. Retry logic matters.

Why multiple containers — The separation between quiz-app, mongo, and mongo-express isn't over-engineering. It means you can update the Flask app without touching the database. You can scale the app without scaling the database. You can swap MongoDB for something else without rewriting application code. This is the architecture pattern that shows up in real production systems.

Try It Yourself

The full project is here: github.com/samuel-nartey/devops-labs

Navigate to Docker & Containers/Running Your First Container/running docker compose, run docker compose up --build, and play through it yourself. Then open docker-compose.yml and start experimenting. The experiments in the README are genuinely worth doing — even when (especially when) they don't produce the failure you expected.

Docker clicked for me when I stopped reading about it and started running something real. This project is exactly that.