Course Outline (Part 26)

In the modern era of software engineering, we rarely install databases directly onto the host operating system of a server (sometimes called “bare metal”).

Instead, the industry standard is to package the database, its dependencies, and its configuration into a lightweight, isolated box called a Container.

In this module, we will learn how to run MongoDB using the two most dominant container technologies in the world: Docker and Kubernetes.

1. Running MongoDB in Docker

Docker allows you to spin up a fully functioning MongoDB database on any computer (Mac, Windows, or Linux) in seconds, without having to install the actual database software on your machine.

Assuming you have Docker installed on your computer, open your terminal and run this single command:

docker run -d -p 27017:27017 --name my-mongo mongo:latest

Let’s break down exactly what this command did:

  • docker run: Tells Docker to create and start a new container.
  • -d: Runs the container in the background (Detached mode).
  • -p 27017:27017: Maps port 27017 on your physical computer to port 27017 inside the container. This allows you to connect Compass to localhost:27017 and have the traffic seamlessly routed into the container!
  • --name my-mongo: Gives the container a friendly name so we can reference it later.
  • mongo:latest: Tells Docker to pull the official, latest MongoDB image from the public Docker Hub registry.

To stop the database, you simply run docker stop my-mongo. To start it again, run docker start my-mongo. It is that easy!

2. The Problem with Containers (Data Loss)

Containers are designed to be “ephemeral” (temporary). If you delete a container (docker rm my-mongo), the container is destroyed, and every single byte of data inside it is instantly deleted forever.

Obviously, a database that loses all its data when it restarts is useless.

To solve this, we must use Docker Volumes. A Volume is a way to tell Docker, “Hey, store the database files on my physical computer’s hard drive, not inside the temporary container.”

Let’s run the command again, but this time with a Volume:

docker run -d -p 27017:27017 --name my-mongo -v mongo-data:/data/db mongo:latest
  • -v mongo-data:/data/db: This tells Docker to create a physical folder on your computer called mongo-data, and mount it inside the container at /data/db (which is the default folder where MongoDB writes its BSON files).

Now, even if you completely destroy the Docker container, your data is perfectly safe on your physical hard drive. When you spin up a new container, you just point it to the same volume, and your data is instantly back online!

3. Docker Compose (Local Development)

Running long terminal commands is tedious. Docker Compose allows you to define your database configuration in a simple YAML file. This is the absolute best way to manage MongoDB for local development.

Create a file named docker-compose.yml:

version: '3.8'

services:
  database:
    image: mongo:latest
    container_name: mongodb-dev
    ports:
      - "27017:27017"
    volumes:
      - mongo-data:/data/db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=admin
      - MONGO_INITDB_ROOT_PASSWORD=supersecretpassword

volumes:
  mongo-data:

Note the environment variables! This allows us to automatically create a secure root user the moment the database spins up.

To start the database, simply open your terminal in the same folder as the file and run:

docker-compose up -d

4. Introduction to Kubernetes (K8s)

Docker is fantastic for running a single database on a single server (or your laptop). But what if you are Netflix, and you need to run a 50-node Sharded MongoDB Cluster across 50 different servers in a cloud data center?

You cannot manually SSH into 50 servers and type docker run. You need a conductor to manage the orchestra of containers. You need Kubernetes.

Kubernetes (K8s) is a Container Orchestration platform. You write a YAML configuration file describing the “Desired State” (e.g., “I want a 3-node MongoDB Replica Set”), and Kubernetes automatically distributes the containers across your physical servers, monitors their health, and restarts them if they crash.

5. StatefulSets in Kubernetes

Running stateless applications (like a Node.js web server) in Kubernetes is easy. If a Node.js container crashes, Kubernetes just deletes it and spins up a new identical one.

Databases are much harder. Databases have State (data on a hard drive). If a MongoDB Primary node crashes, Kubernetes cannot just randomly spin up a brand new MongoDB container on a different server, because that new container won’t have access to the physical hard drive where the data was saved!

To solve this, Kubernetes uses a special object called a StatefulSet.

A StatefulSet guarantees two things for databases:

  1. Stable Network ID: The containers get permanent, predictable names (e.g., mongo-0, mongo-1, mongo-2). This is required so the Replica Set nodes can consistently communicate with each other.
  2. Persistent Volume Claims (PVC): Kubernetes automatically creates and attaches a dedicated, permanent cloud hard drive (Volume) to each specific container. If mongo-0 crashes on Server A, Kubernetes will restart mongo-0 on Server B, and physically detach the cloud hard drive from Server A and reattach it to Server B!

(Note: Deploying a highly available MongoDB Replica Set manually in raw Kubernetes YAML is extremely difficult. The industry standard is to use the MongoDB Enterprise Kubernetes Operator, a software extension provided by MongoDB Inc. that automatically configures the StatefulSets and Replica Set elections for you).

Summary

Modern DevOps relies heavily on containerization.

  • Docker allows you to spin up isolated MongoDB environments in seconds.
  • Volumes are mandatory to prevent catastrophic data loss when containers restart.
  • Docker Compose is the ultimate tool for local development.
  • Kubernetes orchestrates massive multi-server deployments.
  • StatefulSets are required in Kubernetes to manage the strict networking and storage requirements of a database Replica Set.

We have covered everything from basic CRUD to cloud orchestration. In the final conclusion module, Module 26: Next Steps, we will summarize everything we’ve learned and discuss where you should go from here to become a MongoDB Master!

Discussion

Loading comments...