Il networking in Docker gestisce la comunicazione tra i container, tra i container e l’host, e consente sia l’accesso a Internet sia la raggiungibilità dei servizi dall’esterno.
Il comando docker network consente di gestire le reti in Docker. Permette di creare, visualizzare, collegare e rimuovere network utilizzate dai container per comunicare tra loro, con l’host e con l’esterno.
frank@debian:~$ docker network
Usage: docker network COMMAND
Manage networks
Commands:
connect Connect a container to a network
create Create a network
disconnect Disconnect a container from a network
inspect Display detailed information on one or more networks
ls List networks
prune Remove all unused networks
rm Remove one or more networks
Run 'docker network COMMAND --help' for more information on a command.
Attraverso i vari sottocomandi è possibile creare reti personalizzate, connettere o disconnettere container, ispezionare la configurazione e rimuovere reti non più utilizzate.
- connect: collega un container a una rete esistente
- create: crea una nuova rete
- disconnect: scollega un container da una rete
- inspect: mostra i dettagli di una rete
- ls: elenca le reti Docker disponibili
- prune: rimuove le reti non utilizzate
- rm: elimina una o più reti specifiche
Collegare un container a più reti
Un container Docker può essere collegato o scollegato da una rete anche dopo la sua creazione senza doverlo eliminare e ricreare.
Creiamo prima una rete personalizzata di tipo bridge:frank@debian:~$ docker network create --driver bridge net_test01
Avviamo ora un container nginx e senza specificare una rete, Docker lo collegherà automaticamente alla rete predefinita bridge.
frank@debian:~$ docker run -d --name mycontainer nginx
Verifichiamo che il container sia in esecuzione:
frank@debian:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fb23de7cbcdc nginx "/docker-entrypoint.…" 46 seconds ago Up 45 seconds 80/tcp mycontainer
Il container è attivo e non avendo specificato altre opzioni è collegato alla rete bridge di default.
Collegare il container a una seconda rete collegando il container alla rete personalizzata net_test01:frank@debian:~$ docker network connect net_test01 mycontainer
Con docker inspect è possibile verificare che il container sia ora collegato anche alla nuova rete: le reti saranno su subnet differenti. Verifichiamo nel dettaglio le reti collegate:
frank@debian:~$ docker container inspect fb23de7cbcdc
oppure
frank@debian:~$ sudo apt install jq
frank@debian:~$ docker container inspect fb23de7cbcdc --format '{{json .NetworkSettings.Networks}}' | jq
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "b8bf7ec3178b80274bb968bf479e9eff5514cc3dbf2a1736a0eb4175068646e0",
"EndpointID": "e8aef1d89c6ceb6a894acef50c84e44e51fa9329f6bbc1ec93132623f685301c",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"MacAddress": "96:a2:95:1b:c4:9c",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
},
"net_test01": {
"IPAMConfig": {},
"Links": null,
"Aliases": [],
"DriverOpts": {},
"GwPriority": 0,
"NetworkID": "31211ad317c3b047962203b85637f88c2e05fa3e32fb042759c86661bfdc90a1",
"EndpointID": "c3e0f7fea7d667185cf49220cddaaf2cd774b19ea7d7ea599f612f3ee5e838cf",
"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.2",
"MacAddress": "c6:c4:12:b5:ad:c6",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": [
"mycontainer",
"fb23de7cbcdc"
]
}
}
},
Ora il container risulta collegato a due reti:
- bridge
- net_test01
Ogni rete assegna al container un indirizzo IP diverso appartenente alla propria subnet.
Possiamo ora scollegarlo dalla rete predefinita bridge:frank@debian:~$ docker network disconnect bridge mycontainer
Verificando nuovamente:
frank@debian:~$ docker container inspect fb23de7cbcdc --format '{{json .NetworkSettings.Networks}}' | jq
"Networks": {
"net_test01": {
"IPAMConfig": {},
"Links": null,
"Aliases": [],
"DriverOpts": {},
"GwPriority": 0,
"NetworkID": "31211ad317c3b047962203b85637f88c2e05fa3e32fb042759c86661bfdc90a1",
"EndpointID": "c3e0f7fea7d667185cf49220cddaaf2cd774b19ea7d7ea599f612f3ee5e838cf",
"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.2",
"MacAddress": "c6:c4:12:b5:ad:c6",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": [
"mycontainer",
"fb23de7cbcdc"
]
}
}
},
Il container risulterà collegato solamente alla rete net_test01.
Un container può essere collegato a più reti contemporaneamente. Questo permette di separare i flussi di comunicazione: ad esempio, il container può usare una rete interna per comunicare con servizi backend (database, API interne) e una seconda rete per essere raggiungibile da altri servizi o dall’esterno. In questo modo si ottiene maggiore isolamento e una migliore organizzazione della comunicazione tra i container.
Risoluzione DNS automatica
I container possono comunicare usando il nome del container invece dell’indirizzo IP utile in scenari come Docker Compose.frank@debian:~$ docker network create --driver bridge net_test01
frank@debian:~$ docker run --name alpine-box1 -it --net=net_test01 alpine sh
/ #
CTRL P + Q per disconnettersi
frank@debian:~$ docker run --name alpine-box2 -it --net=net_test01 alpine sh
/ #
CTRL P + Q per disconnettersi
Essendo nella stessa network i container possono comunicare usando il nome:
frank@debian:~$ docker exec -it alpine-box2 sh
/ # ping alpine-box1
PING alpine-box1 (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.514 ms
64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.196 ms
64 bytes from 172.18.0.3: seq=2 ttl=64 time=0.159 ms
^C
--- alpine-box1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.159/0.289/0.514 ms
Rimozione delle reti
Docker impedisce la rimozione di una rete se ci sono container ancora collegati. È necessario prima scollegare o rimuovere i container:frank@debian:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
b8bf7ec3178b bridge bridge local
a8820964de30 host host local
31211ad317c3 net_test01 bridge local
597294692ce2 none null local
frank@debian:~$ docker network rm net_test01
Error response from daemon: error while removing network: network net_test01 has active endpoints (name:"alpine-box1" id:"7a93f3d2af07", name:"mycontainer" id:"c3e0f7fea7d6", name:"alpine-box2" id:"d51eb549edbe")
exit status 1
È comunque preferibile scollegare i container manualmente:
frank@debian:~$ docker network disconnect net_test01 alpine-box1
frank@debian:~$ docker network disconnect net_test01 alpine-box2
I container restano attivi ma non sono più collegati alla rete che può ora essere eliminata:
frank@debian:~$ docker network rm net_test01
frank@debian:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
b8bf7ec3178b bridge bridge local
a8820964de30 host host local
597294692ce2 none null local
Per rimuovere tutte le reti orfane:
frank@debian:~$ docker network prune
È possibile forzare la rimozione:
frank@debian:~$ docker network prune -f
Dettaglio delle reti Docker
È possibile visualizzare le reti create di default da Docker ciascuna associata a un driver specifico con:frank@debian:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
7b595434fa8d bridge bridge local
a8820964de30 host host local
597294692ce2 none null local
Il comando docker network ls mostra alcune informazioni utili per identificare e comprendere le reti Docker disponibili. Ogni colonna fornisce un dettaglio specifico:
- NETWORK ID: identificativo univoco della rete
- NAME: nome che identifica la rete
- DRIVER: definisce come i container comunicano tra loro, con l’host e con l’esterno
- SCOPE: indica la visibilità della rete; local significa che la rete è disponibile solo sull’host locale
- bridge: rete privata sull’host (driver predefinito). I container comunicano tra loro e accedono all’esterno tramite NAT.
- host: il container utilizza direttamente lo stack di rete dell’host. Non è presente alcun isolamento di rete.
- none: nessuna rete configurata. Il container è completamente isolato (solo interfaccia loopback).
- overlay: rete multi-host. Consente la comunicazione tra container su host diversi, tipicamente in ambienti cluster o Docker Swarm.
- macvlan / ipvlan: rete fisica. Il container appare come un dispositivo nella LAN, con un proprio indirizzo IP (e MAC nel caso di macvlan).
Isolamento e pubblicazione delle porte
I container Docker sono isolati in una rete virtuale interna. Se non si pubblica esplicitamente una porta il servizio in esecuzione nel container non è raggiungibile dall’host né dall’esterno.frank@debian:~$ docker run -d nginx:latest
frank@debian:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f455fc9221e1 nginx:latest "/docker-entrypoint.…" 4 seconds ago Up 3 seconds 80/tcp heuristic_goodall
frank@debian:~$ curl http://localhost
curl: (7) Failed to connect to localhost port 80 after 2 ms: Could not connect to server
La connessione viene rifiutata perché, per impostazione predefinita, i container sono isolati: dobbiamo essere noi ad aprire in modo esplicito la porta che vogliamo esporre.
nginx ascolta sulla porta 80 solo all’interno del container e docker ps mostra semplicemente 80/tcp. Il servizio non è raggiungibile dal browser dell’host perché nessuna porta dell’host è stata pubblicata.
Pubblicando una porta con -p Docker crea un collegamento tra una porta dell’host e una porta del container:frank@debian:~$ docker run -d -p 8080:80 nginx
Con questa opzione Docker crea un collegamento tra:
- la porta 8080 dell’host dove arrivano le richieste dall’esterno
- la porta 80 del container dove nginx ascolta
$ curl http://localhost:8080
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...
La richiesta arriva alla porta 8080 del sistema host e Docker la inoltra automaticamente alla porta 80 del container dove nginx risponde:
frank@debian:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
65bc470ce6ea nginx "/docker-entrypoint.…" 2 minutes ago Up 2 minutes 0.0.0.0:8080->80/tcp, [::]:8080->80/tcp heuristic_merkle
Docker pubblica la porta 8080 dell’host e la inoltra alla porta 80 del container visibile in docker ps come 0.0.0.0:8080->80/tcp.
In pratica, qualsiasi richiesta inviata all’host sulla porta 8080 viene inoltrata al container sulla porta 80 rendendo il servizio raggiungibile.
Se non viene specificata alcuna rete con --network Docker collega automaticamente il container alla rete bridge predefinita, questo vale sia per docker run nginx sia per docker run -p 8080:80 nginx. In altre parole, anche quando pubblichi una porta, il container rimane sulla rete bridge di default e Docker crea le regole necessarie per inoltrare il traffico dalla porta dell’host alla porta del container.
Puoi verificarlo con:frank@debian:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1a75a8127752 nginx "/docker-entrypoint.…" 12 minutes ago Up 12 minutes 0.0.0.0:8080->80/tcp, [::]:8080->80/tcp intelligent_volhard
3387150b83ba nginx:latest "/docker-entrypoint.…" 14 minutes ago Up 14 minutes 80/tcp competent_babbage
0f6033df8fd3
frank@debian:~$ docker container inspect 1a75a8127752 --format '{{json .NetworkSettings.Networks}}' | jq
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "b8bf7ec3178b80274bb968bf479e9eff5514cc3dbf2a1736a0eb4175068646e0",
"EndpointID": "f686021f0cb2b0fdd8e09fc86de3c5cbbad0e2ff3ea35900509c349fea4e1137",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.3",
"MacAddress": "82:7a:a0:15:17:5e",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
}
}
},
frank@debian:~$ docker container inspect 3387150b83ba --format '{{json .NetworkSettings.Networks}}' | jq
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "b8bf7ec3178b80274bb968bf479e9eff5514cc3dbf2a1736a0eb4175068646e0",
"EndpointID": "ad579b3532c86dda3b2d040372d1887a6f0aa1921df276095a30e437f7d2b2df",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"MacAddress": "a2:53:73:9b:5b:4c",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
}
}
},
Reti personalizzate
Dopo aver visto i principali network driver è importante capire che il comportamento della rete non dipende solo dal driver scelto ma anche dalle opzioni con cui viene creata o utilizzata una rete.
Oltre alle reti create di default è possibile creare reti personalizzate tipicamente bridge utili per isolare meglio i container e sfruttare funzionalità come la risoluzione DNS automatica.
In particolare, il driver bridge può essere utilizzato in modalità predefinita (con NAT e accesso a Internet) oppure in modalità --internal, limitando la comunicazione al solo perimetro della rete Docker. All’estremo opposto, il driver none consente l’isolamento totale del container.
Questo ci permette di individuare tre modalità pratiche di isolamento:- Rete bridge predefinita: comunicazione tra container e accesso a Internet tramite NAT.
- Rete bridge con --internal: comunicazione consentita solo tra container della stessa rete senza accesso verso l’esterno.
- Driver none: isolamento totale, nessuna rete disponibile (solo loopback).
Rete bridge (predefinita) con NAT
Se avvii un container senza specificare una rete, Docker lo collega automaticamente alla rete bridge predefinita. In questo scenario i container possono comunicare tra loro (se si trovano sulla stessa rete) e possono uscire verso Internet tramite NAT gestito dall’host.
Questo comando avvia un container basato sull’immagine nginx in modalità detached -d e gli assegna il nome web:frank@debian:~$ docker run -d --name web nginx
Non essendo stata specificata alcuna rete, il container viene collegato alla rete bridge predefinita e riceve un indirizzo IP su una subnet privata tipicamente 172.17.0.0/16. Il servizio web è attivo all’interno del container, ma non è ancora raggiungibile dalla rete esterna (LAN/Internet) perché non è stata pubblicata alcuna porta.
Il container può comunque raggiungere Internet in uscita tramite NAT quindi può contattare servizi esterni senza configurazioni particolari. La comunicazione con altri container è possibile solo se anche loro sono collegati alla stessa rete Docker. In questo caso Docker gestisce automaticamente il networking interno.
La rete bridge crea un ambiente isolato rispetto al resto della LAN per quanto riguarda le connessioni in ingresso ma il container resta raggiungibile dall’host tramite l’IP assegnato sulla rete bridge. Per esporre il servizio verso l’esterno è necessario pubblicare esplicitamente le porte usando l’opzione -p.
Rete bridge interna con --internal (niente Internet)
--internal non è un driver ma un’opzione di docker network create. Crea una rete tipicamente bridge che permette ai container di parlarsi tra loro ma impedisce l’accesso verso l’esterno quindi niente Internet e niente NAT.
frank@debian:~$ docker network create --internal rete_isolata
Avvio due container nella rete isolata:
frank@debian:~$ docker run --name container-001 -it --network rete_isolata alpine sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if35: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 2e:c7:4c:42:07:0e brd ff:ff:ff:ff:ff:ff
inet 172.18.0.8/16 brd 172.18.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
--> CTRL P + Q per disconnettersi dal container-001
frank@debian:~$ docker run --name container-002 -it --network rete_isolata alpine sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if36: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:8b:10:4a:a3:8c brd ff:ff:ff:ff:ff:ff
inet 172.18.0.9/16 brd 172.18.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
/ # ping container-001
PING container-001 (172.18.0.8): 56 data bytes
64 bytes from 172.18.0.8: seq=0 ttl=64 time=0.267 ms
64 bytes from 172.18.0.8: seq=1 ttl=64 time=0.187 ms
64 bytes from 172.18.0.8: seq=2 ttl=64 time=0.221 ms
64 bytes from 172.18.0.8: seq=3 ttl=64 time=0.185 ms
^C
--- container-001 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.185/0.215/0.267 ms
In questa configurazione il container non ha accesso a Internet perché la rete è stata creata come interna internal e quindi Docker blocca il traffico verso l’esterno.
I container possono comunque comunicare tra loro ma solo se collegati alla stessa rete interna. Questo permette di creare ambienti isolati dove i servizi dialogano esclusivamente a livello locale.
Dal punto di vista del networking, il container è collegato a una rete di tipo bridge configurata con l’opzione Internal=true, quindi senza routing verso l’esterno.
Per verificare la configurazione è possibile utilizzare il comando docker network inspect rete_isolata dove tra i dettagli della rete comparirà il parametro "Internal": true.
frank@debian:~$ docker network inspect rete_isolata
[
{
"Name": "rete_isolata",
"Id": "e378fce2631382034b4b11549aa58488ed29afd666577774f9c3ca6d11ee01bd",
"Created": "2026-02-13T12:42:12.757479953+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv4": true,
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": true,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Options": {},
"Labels": {},
"Containers": {
"141c3df49da65701138735a99515cbe57dbe6ba7ce1f078a64cdf5948be834cb": {
"Name": "container-1",
"EndpointID": "fffdbecb0e70743c6cfb54056a0c5139f1d17b911951fc90caa53206d5163fd2",
"MacAddress": "16:a6:84:52:e1:1e",
"IPv4Address": "172.18.0.2/16",
"IPv6Address": ""
},
"c027cd49d5692e6f5897125c627019128781e5327bbd4a21edeb0979cecee15d": {
"Name": "container-2",
"EndpointID": "14a8d581bc1b40ba4eba94d043daa89fc8fb01e2309119c2911871c787f6d820",
"MacAddress": "2e:61:3c:49:f7:f1",
"IPv4Address": "172.18.0.3/16",
"IPv6Address": ""
}
},
"Status": {
"IPAM": {
"Subnets": {
"172.18.0.0/16": {
"IPsInUse": 5,
"DynamicIPsAvailable": 65531
}
}
}
}
}
]
Container completamente isolato con --network none
Se vuoi isolare totalmente un container dalla rete puoi avviarlo con --network none. In questo caso il container non viene collegato a nessuna rete Docker e non ha interfacce di rete disponibili, tranne la loopback.frank@debian:~$ docker run --network none -it busybox sh
/ # ip a
1: lo: mtu 65536 qdisc noqueue qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
Questa modalità è utile per test locali (processi, filesystem, CPU/memoria) o quando vuoi ridurre al minimo la superficie di attacco, evitando qualunque dipendenza o esposizione di rete.
In questa modalità il container non ha alcun accesso alla rete: non può raggiungere Internet e non può comunicare con altri container.
Docker infatti non assegna nessuna rete al container, che risulta completamente isolato dal punto di vista del networking.
All’interno è presente soltanto l’interfaccia lo (loopback), utilizzata esclusivamente per la comunicazione interna al container stesso.
Si tratta quindi del massimo livello di isolamento di rete, utile per test, sicurezza o processi che non devono effettuare alcuna comunicazione esterna.
Rete macvlan: container raggiungibile direttamente in LAN con IP statico
Il container può comparire come un dispositivo reale nella LAN con un proprio indirizzo IP e a differenza della rete bridge non è necessario pubblicare porte con -p: il servizio è raggiungibile direttamente tramite l’IP assegnato.
Prima controlla quale interfaccia stai usando e che indirizzamento ha l'host:frank@debian:~$ ip a
Interfaccia fisica di esempio: enp1s0
IP host: 192.168.122.120/24
Gateway: 192.168.122.1
Creiamo ora una rete macvlan usando la stessa subnet dell’host in questo esempio 192.168.122.0/24 e il relativo gateway:
frank@debian:~$ docker network create -d macvlan \
--subnet=192.168.122.0/24 \
--gateway=192.168.122.1 \
-o parent=enp1s0 network01_macvlan
Verifichiamo che la nuova rete sia presente:
frank@debian:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
7b595434fa8d bridge bridge local
a8820964de30 host host local
212ef23da8d5 network01 macvlan local
597294692ce2 none null local
Ispezioniamo network01_macvlan per confermare subnet e gateway:
frank@debian:~$ docker network inspect network01_macvlan
...
"Subnet": "192.168.122.0/24",
"Gateway": "192.168.122.1",
"Driver": "macvlan",
"Options": {
"parent": "enp1s0"
}
...
Da questo momento, tutti i container collegati a network01 si comportano come se fossero dispositivi reali collegati alla tua rete locale. In pratica, ogni container può ricevere un indirizzo IP della stessa LAN (ad esempio 192.168.122.X) proprio come un PC, una VM o una stampante di rete. Questo significa che, quando un altro host della rete deve raggiungere il servizio esposto dal container, non passa più dall’host Docker: contatta direttamente l’IP del container. Di conseguenza il container risulta visibile in rete con un proprio MAC address e un proprio indirizzo IP. Non è nascosto dietro l’host come accade con il driver bridge. Non viene usato il NAT: il traffico non viene tradotto dall’host ma arriva direttamente al container come se il container fosse collegato fisicamente allo switch.
Se nginx ascolta sulla porta 80 nel container, dalla LAN basterà aprire il browser di un PC e collegarsi al link http://IP_DEL_CONTAINER.
Avviamo un container nginx assegnando un IP statico:frank@debian:~$ docker run -dit --name myweb_macvlan --net network01_macvlan --ip 192.168.122.181 nginx
Verifichiamo che il container sia in esecuzione:
frank@debian:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cf4193f96dd4 nginx "/docker-entrypoint.…" 17 seconds ago Up 17 seconds myweb_macvlan
Da un PC nella stessa rete possiamo verificare la raggiungibilità con un ping:
frank@laptop01:~$ ping 192.168.122.181
PING 192.168.122.181 (192.168.122.181) 56(84) bytes of data.
64 bytes from 192.168.122.181: icmp_seq=1 ttl=64 time=0.554 ms
64 bytes from 192.168.122.181: icmp_seq=2 ttl=64 time=0.612 ms
^C
Aprendo il browser da qualsiasi PC collegato alla stessa rete e collegandosi al seguente link verrà mostrata la pagina di benvenuto di nginx: http://192.168.122.181
Con docker inspect possiamo verificare IP e gateway assegnati:frank@debian:~$ docker container inspect myweb_macvlan --format '{{json .NetworkSettings.Networks}}' | jq
"Networks": {
"network01_macvlan": {
"IPAMConfig": {
"IPv4Address": "192.168.122.181"
},
"Links": null,
"Aliases": null,
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "bb174ad4c38ccd1a82ff5bfbefd849b869014392875da5487faf3cf56d174e10",
"EndpointID": "a3fac17f0f00583af11f221a4c97fdf3810da1a59d4918aa13014b833ebd9f85",
"Gateway": "192.168.122.1",
"IPAddress": "192.168.122.181",
"MacAddress": "ae:2b:f8:40:13:f0",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": [
"myweb_macvlan",
"cf4193f96dd4"
]
}
}
},
Docker recupera e mostra i log del container chiamato myweb_macvlan consentendo di verificare rapidamente se il servizio è stato avviato correttamente, se ci sono errori o semplicemente per monitorare il comportamento del container. Questo comando è molto utile durante i test e il troubleshooting perché permette di analizzare cosa sta accadendo all’interno del container senza dovervi accedere direttamente con una shell.
frank@debian:~$ docker logs myweb_macvlan
Possiamo inoltre avviare un container assegnando un IP statico ed entrare nella shell per verificare direttamente le interfacce di rete:
frank@debian:~$ docker run -dit --name alpine_macvlan --net network01_macvlan --ip 192.168.122.182 alpine
frank@debian:~$ docker exec -it alpine_macvlan sh
# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
6: eth0@if2: mtu 1500 qdisc noqueue state UP
link/ether be:30:ab:e2:08:59 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.182/24 brd 192.168.122.255 scope global eth0
valid_lft forever preferred_lft forever


