Docker Networking — Bridge, Host e Overlay per Container che Parlano Senza Latenza

Hai due container che devono parlarsi, ma non si vedono. Oppure hai un database in un container e un'app in un altro, ma la latenza è alta. O ancora, devi far comunicare container su server diversi. Se ti sei trovato in una di queste situazioni, sai che Docker networking non è solo docker run --network. Sbagliare la rete significa performance sotto i piedi e sicurezza bucata.

Noi, di Meteora Web, ci siamo passati. Un cliente e-commerce con frontend Vue e backend Laravel: i container non riuscivano a sincronizzare le sessioni perché usavamo il bridge sbagliato. Abbiamo risolto in un pomeriggio, ma la lezione è rimasta: ogni driver di rete ha un perché. In questa guida vediamo bridge, host e overlay con esempi concreti. Niente teoria da manuale: solo quello che serve per far funzionare i tuoi container in produzione.

Questa guida è un approfondimento del nostro Pillar su Docker e containerizzazione. Se non hai mai usato Docker, parti da lì.

Come funziona il bridge di default di Docker e quando usarlo?

Il bridge è la rete predefinita di Docker. Quando lanci un container senza specificare --network, finisce su un bridge virtuale chiamato docker0. Ogni container ottiene un IP privato (es. 172.17.0.2) e può comunicare con altri container sullo stesso host solo se sono collegati allo stesso bridge.

Limitazioni del bridge di default

Il bridge predefinito è isolato: i container non possono risolversi per nome. Per parlarsi devono conoscersi l'IP, che cambia a ogni riavvio. In produzione è un disastro. Per questo Docker offre i bridge definiti dall'utente (user-defined bridge).

Bridge user-defined: la soluzione per container sullo stesso host

Crei una rete bridge personalizzata e lanci i container su di essa. Il vantaggio è la risoluzione DNS automatica: i container si vedono per nome.

# Crea una rete bridge personalizzata
docker network create my-bridge

# Avvia due container sulla stessa rete
docker run -d --name app --network my-bridge nginx
docker run -d --name db --network my-bridge postgres

# Dal container 'app' puoi fare ping a 'db' per nome
docker exec app ping db

Quando usarlo? Sempre, per comunicazioni tra container sullo stesso server. È il metodo più sicuro e performante per applicazioni monolitiche o microservizi su singolo host.

Errore comune: esporre porte inutili

Se usi un bridge personalizzato, non devi esporre al host le porte dei container che comunicano tra loro. Esponi solo quelle necessarie verso l'esterno. Noi vediamo spesso sviluppatori che pubblicano 5432 (PostgreSQL) sull'host quando il frontend è su un altro container. Inutile e insicuro.

Quando conviene usare la rete host invece del bridge?

La rete host elimina l'isolamento: il container condivide lo stack di rete dell'host. Niente IP virtuale, niente NAT. Le porte sono esposte direttamente sull'host.

# Lancia un container con rete host
docker run --network host nginx

Il vantaggio è la bassa latenza: niente traduzioni di indirizzi, niente bridge virtuale. È ideale per servizi che richiedono alte prestazioni di rete (es. proxy inversi, load balancer, applicazioni real-time). Lo svantaggio è zero isolamento: se due container usano la stessa porta (es. 80), conflitto. Inoltre il container ha accesso a tutte le interfacce di rete dell'host.

Quando sceglierlo?

• Quando la latenza è critica e non puoi permetterti il layer di virtualizzazione della rete.
• Per container che devono ascoltare su un gran numero di porte dinamiche.
• Se l'host ha una configurazione di rete complessa (es. VPN, più interfacce) e vuoi che il container le erediti.

Attenzione: non usare host in ambienti multi-tenant o se hai bisogno di isolamento tra container. Un container malevolo (o con bug) potrebbe sniffare il traffico di altri servizi.

Come configurare una rete overlay per container su più host?

Quando i tuoi container vivono su server diversi (cluster Docker Swarm o Kubernetes), ti serve una rete overlay. Crea una rete virtuale che attraversa i nodi, permettendo ai container di comunicare come se fossero sullo stesso host.

# Su un nodo manager di Docker Swarm
docker network create --driver overlay --attachable my-overlay

# Avvia un servizio su due nodi con la stessa overlay
docker service create --name frontend --network my-overlay --replicas 2 nginx
docker service create --name backend --network my-overlay --replicas 2 your-app

I container dei due servizi possono parlarsi per nome di servizio (es. http://backend:8080). Docker si occupa del routing tra nodi attraverso un data plane (VXLAN di default).

Requisiti

• Docker in modalità Swarm (o Kubernetes con CNI compatibile).
• Porte 4789 (VXLAN) aperte tra i nodi.
• Key-value store (Consul, etcd) se usi il vecchio overlay standalone.

Quando usarlo?

Se hai un cluster di server e vuoi microservizi distribuiti con comunicazione trasparente. È l'equivalente di una VLAN per container. Noi l'abbiamo usato per un cliente con due datacenter in Sicilia: app e database su nodi diversi, zero configurazioni manuali di routing.

Quali differenze tra bridge, host e overlay in termini di sicurezza e performance?

Ecco un confronto rapido basato sulla nostra esperienza:

• Isolamento: bridge (alto), host (basso), overlay (medio – il traffico viaggia cifrato tra nodi se abilitato IPsec).
• Performance: host (massima), bridge (leggera perdita), overlay (perdita maggiore per incapsulamento).
• Scalabilità: solo bridge (singolo host), overlay (multi-host).
• Facilità: bridge (semplice), host (semplice), overlay (richiede cluster).

La scelta giusta dipende dal contesto. Un consiglio da chi lavora su progetti reali: parti sempre dal bridge user-defined e passa agli altri solo quando hai un motivo misurabile (latenza o multi-host).

Come comunicano i container tra loro con Docker networking?

Oltre ai driver di rete, devi capire come i container si scoprono e si parlano. In un bridge personalizzato, Docker fornisce DNS integrato basato sul nome del container. Se usi Docker Compose, i servizi si vedono per nome del servizio (es. db dal servizio app).

# docker-compose.yml
services:
  app:
    image: nginx
  db:
    image: postgres
    # Di default, 'app' può contattare 'db' sul nome del servizio

Se hai bisogno di comunicazione inter-host, usa overlay con Swarm o Kubernetes. Senza cluster, puoi usare soluzioni come docker run --link (deprecato) o esporre porte sull'host e configurare i container a conoscere IP esterni. Sconsigliamo: diventa un incubo da mantenere.

Esempio concreto: applicazione web + database su due host

# Host 1: database
docker run -d --name postgres --network host -e POSTGRES_PASSWORD=secret postgres
# Host 2: app (si connette all'IP pubblico di Host1:5432)
docker run -d --name app --network host -e DATABASE_URL=postgres://user:pass@IP_HOST1:5432/db app

Non è elegante, ma funziona. In produzione meglio usare un cluster o un reverse proxy come Traefik.

Cosa fare adesso

1. Identifica se i tuoi container sono su uno o più host. Su singolo host, crea sempre un bridge user-defined e metti i container sulla stessa rete.
2. Se hai un cluster Docker Swarm, crea una rete overlay e lancia i servizi su di essa.
3. Evita il bridge di default: non ha DNS, e i container soffrono.
4. Non usare --link (deprecato). Sostituiscilo con reti definite.
5. Verifica la sicurezza: in bridge personalizzato, i container non vedono gli altri se non sulla stessa rete. Tienili separati per ruolo (es. rete frontend, rete backend).
6. Se vuoi approfondire il pillar principale, torna alla guida completa su Docker e containerizzazione.