Quel est l'intérêt du processus de docker-proxy? Pourquoi un proxy TCP d'espace utilisateur est-il nécessaire?

J'ai remarqué qu'il existe un processus proxy-docker en cours d'exécution pour chaque port publié. Quel est le but de ce processus? Pourquoi un proxy TCP d’espace utilisateur est-il nécessaire pour cela?

$ ps -Af | grep proxy
root      4776  1987  0 01:25 ?        00:00:00 docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 22222 -container-ip 172.17.0.2 -container-port 22
root      4829  1987  0 01:25 ?        00:00:00 docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 5555 -container-ip 172.17.0.3 -container-port 5555

et quelques règles iptables associées créées par docker:

$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 1 packets, 263 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 1 packets, 263 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 1748 packets, 139K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   32  7200 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 1719 packets, 132K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   32  7200 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0           

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            127.0.0.1            tcp dpt:22222 to:172.17.0.2:22
    0     0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            127.0.0.1            tcp dpt:5555 to:172.17.0.3:5555

iptables docker

— Tarnay Kálmán
source

Pas d'accord pour fermer cette question. Il s’agit d’un problème d’architecture valide qui découle de serverfault.com/questions/615372 ; si nous votons à la baisse sur ce qui semble être une partie non documentée (du moins sur le site Web) du service, alors la question se pose: devons-nous simplement installer aveuglément de nouveaux services brillants que nous ne comprenons pas le service interne? fonctionnement de?

— Avery Payne

Aussi sur so stackoverflow.com/a/37809857/1318694

— Matt

Apparemment, il y a des cas extrêmes sans meilleure solution de contournement (pour l'instant):

localhost <-> routage localhost
instance de docker s'appelant via son port publié
et peut-être plus

https://github.com/docker/docker/issues/8356

UPDATE: Depuis la version 1.7.0 (2015-06-16), le proxy userland peut être désactivé en faveur d'un NAT en épingle à cheveux à l'aide de l'indicateur --userland-proxy = false du démon.

— Tarnay Kálmán
source