¿Cuál es el punto del proceso docker-proxy? ¿Por qué se necesita un proxy TCP de espacio de usuario?

Me he dado cuenta de que hay un proceso docker-proxy ejecutándose para cada puerto publicado. ¿Cuál es el propósito de este proceso? ¿Por qué se necesita un proxy TCP de espacio de usuario para esto?

$ ps -Af | grep proxyroot      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 22root      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

y algunas reglas de iptable relacionadas creadas por docker:

$ sudo iptables -t nat -L -n -vChain 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 LOCALChain 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 LOCALChain 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

Aparentemente, hay algunos casos extremos sin una mejor solución (por ahora):

  • >localhost & lt;-enrutamiento de localhost
  • instancia de docker que se llama a sí misma a través de su puerto publicado
  • y posiblemente más

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

ACTUALIZACIÓN: Desde la versión 1.7.0 (16/06/2015), el proxy de área de usuario se puede deshabilitar a favor de hairpin NAT utilizando la bandera --userland-proxy=false del demonio.

No estoy de acuerdo con el cierre de esta pregunta. Es un problema arquitectónico válido que es una rama de ssh - Restricting the network access of Docker container - Server Fault ; si estamos votando en contra de lo que parece ser una parte nodocumentada (al menos en el sitio web) del servicio, entonces eso plantea la pregunta, ¿deberíamos ir por ahí instalando ciegamente servicios nuevos y brillantes de los que no entendemos el funcionamiento interno?

También en so Why does Docker run so many processes to map ports though to my application? - Stack Overflow