Separate data from containers

Every container has a thin writable layer on top of the read-only image. When your app writes a file, it lands there. And when you remove the container, that layer is gone, with every file in it.

For a web server that’s fine. For a database, it’s a disaster waiting to happen. Replace the container to update the image and the data is gone.

Containers are replaceable

The way out is a mindset shift. Treat every container as something you can delete and recreate at any moment. Then put anything that must survive outside of it:

• durable data, like a database directory or uploaded files, goes in a volume
• configuration goes in environment variables or mounted config files

Updating the app then means: stop the old container, start a new one from the new image, attach the same volume.

Create a volume

A named volume is a piece of storage Docker manages for you, with its own lifecycle. It exists before any container uses it, and it stays after they’re removed.

docker volume create notes-data
docker volume inspect notes-data

The inspect output shows a Mountpoint, a path on the host like /var/lib/docker/volumes/notes-data/_data. On Docker Desktop that path is inside a hidden Linux VM, so you can’t even open it from your Mac.

Don’t edit that directory directly, on any system. Docker owns it, and the file ownership inside it belongs to the containers that use it. If you need to look at the data, do it from a container that mounts the volume, or with a backup tool.

We’ll attach this volume to PostgreSQL in the Compose lessons.

Persistence is not backup

A volume survives container replacement. That’s all it promises.

It doesn’t protect you from docker volume rm notes-data typed in the wrong terminal, from an application bug that deletes rows, or from a corrupted database file. All of those survive a container replacement just fine, because the volume carried them over.

So before calling data “durable”, answer three questions: how is this volume backed up, where does the backup live, and when did I last test a restore. If the answer to the last one is “never”, you don’t have a backup. You have a hope.

Three kinds of storage

Use the writable layer for throwaway runtime changes, like a temp file the app creates on start. Use a volume for state that must outlive the container. And for scratch data that should disappear when the container stops, use a tmpfs mount, which lives in memory only (--tmpfs /tmp).

Try this: create the volume, inspect it, and find its Docker-managed name and mountpoint. Then leave the directory alone. We’ll use the volume soon.