docker-volume-discipline
Docker Volume Discipline — Named Volumes for State, Audit Before Prune
Section titled “Docker Volume Discipline — Named Volumes for State, Audit Before Prune”- Stateful compose services MUST use named volumes. Any docker-compose service with a persistent data directory (postgres, mysql, mongo, redis, rabbitmq, any DB/queue) MUST mount a named volume (declared under top-level
volumes:) or an explicit bind mount for that directory. NEVER rely on the image’s implicitVOLUME— that silently creates an anonymous volume, which is indistinguishable from prune-able waste. - NEVER blanket-prune anonymous volumes. Before removing dangling anonymous volumes (
docker volume prune,docker system prune --volumes), audit each one for database fingerprints —PG_VERSION(postgres),ibdata1(mysql),WiredTiger(mongo),dump.rdb/appendonly.aof(redis) — and EXCLUDE matches. Delete via an explicitdocker volume rm <list>of verified-safe volumes, never a blanket prune. - Compose fixes land in the owning repo. Converting a service to named volumes is a change to the owning project’s compose file — branch + PR in that repo. NEVER edit compose files in place on a host machine.
Why: anonymous volumes hide real data behind hex names — a blanket prune has destroyed live
database data before. Named-volume example, the audit one-liner, and the conversion procedure:
docs/docker-volume-discipline.md (also carries the incident).
Related
Section titled “Related”rules/preview-first-batch.md— smoke-test + confirm gate before bulk deletionrules/kit-wide-fix-discipline.md— fixes land at the source repo, not locallydocs/docker-volume-discipline.md— the originating incident in full