Managing Data with Docker Volumes

Containers are ephemeral: anything written lives inside the container, and removing it wipes the data. Fine for stateless apps, but a database needs its data to survive.

Each container has a thin writable layer on top of its image. Writes land there, but it's tied to the container's life — delete the container and that layer vanishes.

Docker offers two ways to persist data: volumes (managed by Docker) and bind mounts (a host folder mapped in). Volumes are the recommended default.

Create a named volume in one command with docker volume create. Docker decides where it physically lives so you don't have to.

Attach a volume with -v using volumeName:/path/in/container. Now everything written to that path persists in the volume.

Since the volume is independent of the container, you can delete the container, spin up a new one with the same volume, and your data is still there.

A bind mount maps a host directory into the container — perfect for development, where editing code on your machine shows up instantly inside.

Pick by the job: volumes for portable, Docker-managed production data; bind mounts for development when you want an exact host path and full control.

docker volume ls lists your volumes and docker volume inspect shows details — including where the data actually lives on disk.

Mount one volume into multiple containers and they share files — for example, an app container and a backup container both reading the same data.

Unused volumes waste disk. Remove one with docker volume rm or clear dangling ones with docker volume prune — carefully, since this deletes data for good.

Test your understanding of Docker data.

You learned to persist data: containers are ephemeral, volumes survive removal and mount with -v name:/path, while bind mounts suit development.