Service A: The Database

Before we can build a multi-container app, we need a data layer that runs as its own service.

In earlier work, we mostly interacted with MongoDB through Atlas. That was convenient, fast, and absolutely the right choice for many app projects. But in this lesson, we’re staying local on purpose so we can see how Docker Compose handles service coordination and, soon, persistent volumes.

We are not here to become MongoDB power users today. We are here to understand what it means for a database to live in its own container.

Why the Database Gets Its Own Container

Once we move beyond a single-container app, we stop treating everything as one giant bundled machine.

Our database has a different job than our Node app:

the API service runs our application logic
the database service stores and retrieves data
each service can be started, stopped, replaced, and debugged independently

That separation is the whole game.

A local MongoDB container also gives us a nice bridge. We already have a Node portfolio project backed by MongoDB, so we’re not far away from containerizing it.

Not a MongoDB Lesson

We already know what MongoDB is and what collections/documents look like. Here, MongoDB is mainly our stateful service—the part of the stack that gives us something meaningful to connect to and, later, something meaningful to persist.

Launching MongoDB, in a Container, Manually

To start, we’ll launch MongoDB the manual way so we can feel the setup friction before Compose comes in to save the day.

Run this in a terminal:

docker run -d --name db_service mongo:8.0

Breaking Down the Command

docker run creates and starts a container from an image
-d runs it in detached mode so it stays in the background
--name db_service gives the container a predictable name
mongo:8.0 pulls and runs the MongoDB 8.0 image

Where did that image come from

If an image is not already on our machine, Docker will automatically search for and fetch it from Docker Hub!

How to Choose an Image Tag

When we look up an image on Docker Hub, we’ll usually see many, many tags.

To select the right image for our purposes, a few simple rules go a long way:

avoid latest unless we truly want whatever changed most recently. The bleeding edge is not always our friend.
pin a major version for reasonable stability without over-controlling every patch - in this case mongo:8.0
ALWAYS prefer official or clearly maintained images, unless we have a very good reason not to.

For this lesson, mongo:8.0 is a good fit because it is modern and stable and official.

More Image Selection Info

When comparing images on Docker Hub, look for a few things:

who maintains the image
whether the tags are current and clearly versioned
whether the image has good documentation
whether the priority is simplicity, small size, or maximum control

Verifying That Our MongoDB Service Is Running

Now let’s confirm that the container actually exists and is alive:

docker ps

We should see a running container named db_service.

We can also inspect its logs:

docker logs db_service

At this stage, we are not trying to do anything fancy. We just want proof that our database service is up and waiting.

Extra Bits & Bytes

Official MongoDB Image on Docker Hub

⏭ Step into the Database

The service is alive. Let’s step into it and see what we can do.