💾 Volumes

Volumes: A container's filesystem is a whiteboard in a rented meeting room: the moment your booking ends (docker rm), the cleaning crew wipes it clean.

A container's filesystem is a whiteboard in a rented meeting room: the moment your booking ends (docker rm), the cleaning crew wipes it clean. A volume is the binder you carry out of the room — it survives every meeting. But wait — if containers are supposed to be disposable, why do we need persistence at all? Because SOME state is the product, not the pollution: test reports, failure screenshots, database data you seeded for a demo. Java has the same split — objects on the heap vanish when the JVM exits, which is exactly why you serialize what matters to disk. For QA the distinction is a daily trap: run your Selenium suite in a container without mounting a volume for the report folder, and a red pipeline leaves you with no HTML report and no failure screenshots — the evidence died with the container.

Volume Commands (Persistent Storage)

Named volumes — create, list, inspect, remove

Where Does a docker volume Physically Live?

docker volume create allocates space…

`docker volume create test-data` allocates space in an area Docker manages ITSELF (on the host machine, but OUTSIDE any container) — it is not yet ATTACHED to any container.

docker volume ls and inspect show…

`docker volume ls` and `docker volume inspect` show that this space EXISTS and reveal its REAL disk path (physical location on the host) — this data STAYS THERE even if the container is REMOVED.

docker volume rm ONLY works if NO…

`docker volume rm` ONLY works if NO container is using that volume — otherwise Docker says "volume is in use" to PREVENT you from ACCIDENTALLY deleting the data.

Arrange the lifecycle of a persistent test-database volume in the correct order.

Create the named volume (docker volume create)

Run the container mounting that volume (-v)

Data survives in the volume even if the container is stopped and removed