Blocco A · Fondamenta Docker — Modulo 4 di 16
Reti e persistenza
Obiettivi di oggi
- Reti bridge dedicate e DNS tra container
- Volumi nominati vs bind mount: dove vive lo stato
- API + PostgreSQL: dati che sopravvivono ai container
Principio: container usa-e-getta, stato no
- Un container deve poter essere distrutto e ricreato in qualunque momento senza perdere nulla
- Lo stato vive: nei volumi (file) o in servizi dedicati (database)
- È il prerequisito di tutto il Blocco B: deploy e rollback ricreano container di continuo
Reti: i container si chiamano per nome
docker network create pratiche-net
docker run -d --name db --network pratiche-net postgres:16
docker run -d --name api --network pratiche-net \
-e DATABASE_URL=postgresql://pratiche:segreto@db:5432/pratiche ...
- Sulla stessa rete:
db si risolve via DNS interno — mai IP
localhost dentro un container è il container stesso (errore classico)- Pubblicare una porta (
-p) è una scelta di esposizione, non un obbligo
Volumi
docker volume create pratiche-dbdata
docker run -d --name db \
-v pratiche-dbdata:/var/lib/postgresql/data postgres:16
| Volume nominato | Bind mount |
|---|
| Gestito da | Docker | te (path host) |
| Uso tipico | dati di produzione | codice in sviluppo, config |
Laboratorio (2h)
- Rete + volume; PostgreSQL; API ricostruita con
DATABASE_URL
- Crea pratiche → distruggi il DB → ricrea → le pratiche ci sono ancora
- Bonus: dentro il DB con
psql; primo pg_dump
Riepilogo e prossimo passo
- Nome-sulla-rete e volume nominato: le due gambe di ogni stack
- Ma ora l'avvio richiede 5 comandi in ordine giusto…
- Modulo 5: Docker Compose — tutto lo stack in un file