Lesson 63: Container Networking & Storage
The Production Reality of Bind Mounts, Named Volumes, and Database Lifecycle Management
What We’re Building Today
A production-grade PostgreSQL container with a named volume strategy that survives container replacement cycles without data loss
A bind-mount-driven development workflow that maps live source directories into containers for hot-reload without image rebuilds
A database backup and restore pipeline using pg_dump, S3-compatible object storage, and point-in-time recovery semantics
A docker network topology that enforces service isolation: frontend, backend, and database tiers communicate on separate subnets with explicit allow-lists
Why This Matters
Every production incident involving container infrastructure eventually touches two questions: where is this data actually stored, and can this container talk to that one. These aren’t configuration details—they are architectural decisions with direct blast-radius consequences.
Bind mounts and named volumes look similar in a Compose file. In production they behave like completely different primitives. Bind mounts couple your container to the host filesystem path, which is fine for a developer’s local source directory and catastrophic for a database’s data directory on a cluster node that gets replaced. Named volumes are managed by the Docker daemon, decoupled from host paths, and—critically—persist across container recreation, image upgrades, and docker-compose down cycles.
Netflix’s container infrastructure team has documented cases where misuse of bind mounts for stateful workloads caused node-local data that became inaccessible the moment an instance was terminated. The fix wasn’t operational—it was architectural. Understanding the storage primitive is the prerequisite to avoiding those failure modes at scale.
Architecture Deep Dive
