2015-07-15 26 views
10

I "dockerizing" un'app che trasmette UDP heartbeat su una porta conosciuta. Questo è con docker-engine-1.7.0 su una varietà di host (Fedora, Centos7, SLES 12).docker docker0 e indirizzi di broadcast del contenitore non impostati

Ho notato che il bridge 'docker0' sull'host di docker e 'eth0' all'interno del container hanno ciascuno un indirizzo di broadcast di 0.0.0.0.

Assumendo il privilegio di amministratore sull'host È possibile impostare manualmente l'indirizzo di trasmissione su docker0. Allo stesso modo nel contenitore (se il contenitore è in esecuzione con privilegi o con NET_ADMIN, NET_BROADCAST), ma sono curioso del perché l'indirizzo di broadcast non sia impostato di default. C'è una opzione di configurazione che mi manca per Docker per farlo automaticamente?

Host:

# ifconfig docker0 broadcast 172.17.255.255 up 
# tcpdump -i docker0 -p 5000 

Contenitore:

# ifconfig eth0 broadcast 172.17.255.255 up 
# echo "Hello world" | socat - UDP-DATAGRAM:172.17.255.255:5000,broadcast 

Broadcast dall'host al contenitore funziona anche una volta che le indirizzi broadcast sono impostati.

+0

Vedere anche: https://serverfault.com/a/881662 – tne

risposta

0

se si passa NET_ADMIN nel contenitore Docker, non utilizzare la reteaffatto per l'applicazione.

Se ho capito correttamente cosa si sta tentando di fare, la trasmissione UDP che trasmette heartbeat su una porta conosciuta viene utilizzata dai contenitori Docker che appartengono a host diversi per trovarsi l'un l'altro, e non da contenitori di docker diversi nello stesso host.

Vorrei quindi raccomandare di utilizzare --net=host:

docker run --net=host --cap-add NET_ADMIN ....

come non se si ottiene un guscio nel contenitore finestra mobile, si vedrà che l'ambiente di rete è esattamente lo stesso uno dei più host che è gestire i contenitori. Se la tua applicazione era in esecuzione su quel server in precedenza utilizzando la trasmissione UDP, funzionerà esattamente allo stesso modo nel contenitore della finestra mobile.