Day 24 of 90 Days of DevOps Challenge: Understanding Stateful vs Stateless Containers, Docker Volumes and Intro to Docker Swarm

Today’s session was focused on three critical topics in the Docker ecosystem Understanding the difference between stateful and stateless containers, Leveraging Docker volumes to persist container data, Getting introduced to Docker Swarm, Docker’s native orchestration platform.

Let’s walk through the concepts and hands-on steps covered today.

Stateless vs Stateful Containers

By design, Docker containers are stateless. This means:

• Stateless Container: Data inside the container is ephemeral and gets deleted when the container is removed.

• Stateful Container: Data persists even after the container is stopped or recreated.

Real-world Example:
In a spring-boot-mysql application, if the MySQL database runs as a Docker container, any data written to the database is lost upon container recreation. This behavior is unacceptable in production environments where data integrity and persistence are crucial.

Solution: Use Docker volumes to convert stateless containers into stateful containers.

Docker Volumes

Docker Volumes are the standard mechanism for persisting and managing data in Dockerized environments.

Key Benefits of Volumes:

• Enable persistent storage across container restarts or removals

• Allow decoupling of container lifecycle from data lifecycle

• Facilitate data sharing between containers

Types of Docker Volumes:

1. Anonymous Volumes – automatically created and unnamed

2. Named Volumes – explicitly created and reusable

3. Bind Mounts – map host machine paths directly

Common Volume Commands:

# List all volumes
docker volume ls

# Create a named volume
docker volume create <volume_name>

# Inspect volume details
docker volume inspect <volume_name>

# Remove a specific volume
docker volume rm <volume_name>

# Remove all unused volumes
docker system prune --volume

Making Containers Stateful with Docker Compose

Step 1: Create a directory on the host to persist database data

mkdir /home/ec2-user/app
Step 2: Modify docker-compose.yml to mount the volume

version: "3"
services:
  application:
    image: spring-boot-mysql-app
    ports:
      - "8080:8080"
    networks:
      - springboot-db-net
    depends_on:
      - mysqldb
    volumes:
      - /data/springboot-app
  mysqldb:
    image: mysql:5.7
    networks:
      - springboot-db-net
    environment:
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_DATABASE=sbms
    volumes:
      - ./app:/var/lib/mysql

networks:
  springboot-db-net:

With this configuration, database data will be saved in the host machine and remain intact even after container deletion or recreation. This ensures data persistence, a key requirement in real-world applications.

Introduction to Docker Swarm

Docker Swarm is Docker’s built-in orchestration platform, enabling you to manage containerized services across a cluster of machines.

Key Concepts:

• Orchestration: Automated deployment, scaling, and management of containers

• Swarm: A cluster of Docker nodes (1 master + multiple workers)

• Service: A task definition that tells Swarm how to run a container

Setting Up a Swarm Cluster

Step 1: Provision 3 Ubuntu EC2 Instances

Install Docker on all instances:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Ensure port 2377 is open in your security group for Swarm communication.

Step 2: Initialize the Swarm on the Master Node

sudo docker swarm init --advertise-addr <master-private-IP>

Step 3: Join Worker Nodes

Retrieve the join command:

sudo docker swarm join-token worker

Then execute the provided token command on each worker node:

sudo docker swarm join --token <token> <master-IP>:2377

Deploying a Docker Swarm Service

A service in Swarm is a scalable container definition. Here’s how to deploy one:

sudo docker service create --name java-web-app -p 8080:8080 zerotoroot/javawebapp

By default, one replica is created.

Common Docker Swarm Commands:

# List all services
sudo docker service ls

# Scale the service
docker service scale java-web-app=3

# Inspect service configuration
sudo docker service inspect --pretty java-web-app

# View service tasks
sudo docker service ps java-web-app

# Leave the swarm (on any node)
sudo docker swarm leave

# Remove the service
sudo docker service rm java-web-app

Access your app at:

http://<master-node-public-ip>:8080/java-web-app/

Final Thoughts

Today’s session was an eye-opener in terms of understanding data persistence in containers and the need for orchestration in scalable environments. We explored how Docker Volumes bridge the gap between ephemeral and persistent storage, and how Docker Swarm brings in automation and scalability for production-ready deployments.

Moving forward, these foundational concepts will be essential as we delve deeper into container orchestration, high availability, and deployment strategies.

As always, consistency is key. See you tomorrow on Day 25 of the challenge!