# Container Storage

## The default: a disposable writable layer

Every running container gets its own writable layer sitting on top of its image's read-only
layers. Anything written there — a log file, a temp file, application data — exists ONLY as long
as that specific container does. Destroy the container, and that data is gone permanently. This
is ROOT 02's "persistent vs. temporary" question, given a hard default answer: by default,
everything in a container is temporary.

## Bind mounts: sharing a specific host path

A **bind mount** connects a specific path on the HOST filesystem directly into the container:

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

Changes are visible on BOTH sides immediately — useful for development (edit code on the host,
see changes in the container instantly) but tightly coupled to that exact host's filesystem
layout, which makes it a poor choice for portable, production data.

## Named volumes: Docker-managed persistent storage

A **named volume** is storage Docker manages for you, independent of any specific host path:

```
docker volume create my-data
docker run -v my-data:/container/path myimage
```

A named volume's data survives container destruction AND recreation — attaching the SAME volume
to a brand-new container gives that new container access to exactly the same data the old one
left behind. This is the deliberate, production-appropriate way to persist container data.

## The test that actually proves persistence

Claiming "this data persists" isn't convincing without proof: write data, DESTROY the container
completely, create a brand new one attached to the same volume, and confirm the data is still
there. This module's Lab requires exactly that proof, not just a claim.

## Bridge to Kubernetes

A Kubernetes `PersistentVolume`/`PersistentVolumeClaim` is the same idea generalized across an
entire cluster instead of one machine — the exact concept this module teaches, just orchestrated
at a larger scale, which Kubernetes courses build on directly.

## Instructor Notes

**Lesson goal:** Make "containers are disposable, volumes are not" a hard, memorable
distinction — directly building on ROOT 02's persistent/temporary framing.

**Approximate timing:** 15 minutes read; 10 minutes live.

**Common misconception to watch for:** assuming ANY container data survives by default — the
default is the OPPOSITE; persistence requires deliberate action (a volume or bind mount).

**Discussion question:** "Why might a named volume be preferred over a bind mount for
production data, even though both technically 'persist' data?" (Answer: a named volume isn't
tied to one specific host's exact filesystem path, making it more portable across different
hosts/environments.)