Docker Volumes and Networking

Docker Volumes and Networking

A container writable layer is tied to that container. Volumes provide Docker-managed persistent storage, while bind mounts expose a chosen host path. Docker networks give containers isolated connectivity and built-in discovery.

Core ideas

• Named volumes outlive containers and are portable across container replacements on one daemon.
• Bind mounts are useful for development source or explicit host integration but couple workloads to host layout.
• User-defined bridge networks provide service-name DNS and configurable isolation.
• Publishing HOST_PORT:CONTAINER_PORT exposes a container port through the host; EXPOSE alone does not publish it.

How it works

Create a network and volume, attach services by name, and publish only the entrypoint that external clients need. Containers on the same user-defined network connect using container DNS names and container ports, not the host-published port.

Command or configuration example

docker network create app-net
docker volume create db-data

docker run -d --name db --network app-net \
  -v db-data:/var/lib/postgresql/data postgres:17

docker run -d --name api --network app-net \
  -e DATABASE_URL=postgres://db/app -p 127.0.0.1:8080:8080 my-api:1.4.0

Run examples first in a disposable environment. Replace image names, versions, credentials, ports, paths, and resource values with reviewed settings appropriate to your system.

Production guidance

• Back up and restore application-consistent volume data; copying live database files may be unsafe.
• Use read-only mounts where writes are unnecessary and verify host-path ownership.
• Bind published ports to the required interface and segment networks by trust and application.

The chapter quiz follows this lesson and checks the concepts as well as the operational tradeoffs.