The Ephemeral Problem

Imagine you’re staying in a hotel for a week.

Option 1: Store everything in the hotel room

You leave your laptop, clothes, and documents in the room. It’s convenient—everything’s right there.

But when you check out, housekeeping clears the room. All your stuff is thrown away. (This is what happens with container filesystems.)

Option 2: Store important things in a personal safe deposit box

The hotel provides safe deposit boxes in the lobby. You put your passport, money, and important documents there.

Now when you check out and come back to a different room next week, your important stuff is still in the safe deposit box. The room changed, but your valuables persisted.

Docker volumes are the safe deposit box. Data stored in volumes persists even when containers are removed.

Option 3: Keep working files in your car trunk

You have a briefcase of work documents that you keep in your car. You bring the car to the hotel, and access your files from the parking lot.

When you change hotels, the files stay in your car—they’re not in the hotel at all.

Bind mounts are your car. You’re storing data on the host filesystem, and the container just accesses it.

Container filesystem layers:

Remember union filesystems from Module 7? When a container runs, it has:

1. Read-only image layers (shared across containers)
2. Read-write container layer (unique to this container)

When you write data inside a container, it goes to the read-write container layer.

What happens when the container stops:

• The container layer stays on disk
• Data is still there
• You can restart the container and the data is intact

What happens when the container is removed:

docker rm mycontainer

• The container layer is deleted
• All data written to the container filesystem is lost forever

The ephemeral nature:

# Start MySQL, create database, add data
docker run -d --name mysql mysql:8
docker exec mysql mysql -u root -proot -e "CREATE DATABASE myapp"
docker exec mysql mysql -u root -proot -e "USE myapp; CREATE TABLE users (id INT)"

# Stop and remove
docker stop mysql
docker rm mysql

# Start new MySQL container with same name
docker run -d --name mysql mysql:8

# Try to access the database
docker exec mysql mysql -u root -proot -e "SHOW DATABASES" | grep myapp
# Not found! Data is gone.

Docker provides three ways to persist data:

1. Docker Volumes (Recommended)

Managed by Docker. Stored in Docker’s directory (/var/lib/docker/volumes/).

docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql:8

Data persists in the volume even if the container is removed.

2. Bind Mounts

Map a host directory to a container directory.

docker run -v /host/path:/container/path myimage

Data is stored on the host filesystem. Useful for development.

3. tmpfs Mounts

Stored in host memory (RAM). Extremely fast, but data is lost when container stops.

docker run --tmpfs /app/cache myimage

Useful for temporary data that doesn’t need to persist.

Use cases that require persistence:

• Databases: PostgreSQL, MySQL, MongoDB
• File uploads: User profile pictures, documents
• Configuration: Application settings, certificates
• Logs: Application logs, audit trails
• Cache: Redis, Memcached (though can be rebuilt)
• State: Session data, job queues

Use cases that don’t require persistence:

• Stateless web servers: Serving static code
• Microservices: If they store state externally
• Workers: Processing jobs from a queue
• Temporary processing: ETL jobs that output to external storage

Real-world horror story:

A company ran their production database in a Docker container without volumes. The host server had a power outage. When it rebooted, Docker didn’t restart the container automatically.

An engineer manually started the database container:

docker run -d --name db postgres:15

But they forgot the exact flags from the original deployment. They created a new container instead of restarting the stopped container.

All customer data from the past 6 months: gone.

No volume, no backup, no recovery. The company went out of business.

The lesson: Always use volumes for stateful applications. Always.

---