The Ephemeral Nature

Think of a container like a whiteboard in a meeting room.

The template (image): There’s a printed template attached to the whiteboard with the meeting agenda — always there, read-only, the same for every meeting.

Using the whiteboard (running container): During your meeting, you write notes, draw diagrams, add ideas. All of this goes on the whiteboard’s writable surface.

Meeting ends but room is booked for later (stopped container): You leave, but the room is reserved. Your notes are still on the whiteboard. When you come back, you can continue.

Room released, cleaned by janitor (removed container): The room is no longer reserved. The janitor erases the whiteboard. Next team gets a clean whiteboard with just the original template.

Ephemeral (Lost When Container is Removed):

• Files created inside the container
• Installed packages
• Configuration changes
• Application state in memory

Persistent (Survives Container Removal):

• The image itself
• Data in volumes (we’ll cover in Module 10)
• Data in bind mounts
• Container logs (depending on logging driver)

Survives Restart, Lost on Removal:

• Container’s writable layer contents
• Container metadata (name, settings)

Containers Should Be Replaceable

Good practice: You should be able to delete any container and recreate it from the image without data loss.

This means:

• Important data goes in volumes
• Configuration comes from environment variables or config files
• Application state is stored externally (databases, caches)

The “Cattle, Not Pets” Philosophy

Traditional servers are “pets” — you name them, you care for them, you fix them when sick.

Containers are “cattle” — they’re numbered, they’re interchangeable, if one is sick you replace it.

Pattern 1: Configuration via Environment Variables

Instead of editing config files inside the container:

docker run -e DATABASE_URL=postgres://... -e DEBUG=false myapp

Pattern 2: External Data Storage

Instead of storing data inside the container:

docker run -v mydata:/app/data myapp

Pattern 3: Build Everything into the Image

If you need packages, put them in the Dockerfile. Don’t install them at runtime.

# Good: Dependencies in image
RUN apt-get install -y curl

# Avoid: Installing at runtime (lost when container is replaced)

---