Container volumes and networks: where data really lives

Containers are ephemeral; the data must not be. Every container data-loss story ends at a mount that nobody drew on a diagram: state in the writable layer, a bind mount to a laptop path, or two services sharing a network nobody named.

State outlives the container

Named volumes hold state. Databases, uploads and queues live in named volumes with a backup story. The writable container layer holds nothing you would miss.

Mount read-only by default. Config, fixtures and shared content mount read-only; only the paths that must change stay writable. An attacker or a bug then finds most doors locked.

Name the networks. Each purpose gets its network, and each service joins only what it needs. Debugging who talks to what becomes a lookup instead of an investigation.

Worked example: a fictional lost upload

The context below is fictional. Fictional app ParcelTrack (fictional) stores uploads in the container layer on one host. A routine image update wipes a week of customer files; there is no backup because nobody classified uploads as state.

The rebuild moves uploads to a named volume with nightly archives, mounts config read-only, and splits frontend from data traffic on two named networks. Next update: new image, same data, zero loss.

Checklist: data that survives updates

1. Every stateful path named as a volume with a backup.
2. Non-write mounts read-only.
3. Networks named per purpose, services minimally joined.
4. An update test proves data survives a new image.

Related reading

• Hands on: Volume and Network Misconfigurations.
• DevOps Foundations Module 6 covers the container sequence.