Containers are isolated by default — they cannot reach each other or the host unless explicitly configured. A payment API that needs to talk to a PostgreSQL database, a Redis cache, and an internal billing service needs networking configured correctly. Similarly, a database container that loses all data when it restarts is useless in production. This pillar covers both.
What This Pillar Covers
- Docker network types — bridge, host, none, and overlay for multi-host communication
- Connecting containers on the same network using service names as DNS hostnames
- Docker volumes vs bind mounts — when to use each and how to manage persistent data
- Volume lifecycle management — creating, inspecting, backing up, and removing volumes safely
Who This Is For
DevOps engineers and developers who run multi-container applications locally or in production and need containers to communicate reliably and persist data correctly.
Why This Matters in Production
At Swiggy, the order service, notification service, and database all run as separate containers. Without correct network configuration, they cannot communicate. Without volumes, every database restart loses order history.
Prerequisites
- Docker Fundamentals and Docker Images
- Basic understanding of TCP/IP, DNS, and ports
- Familiarity with file systems and mount points on Linux