I have an application that runs in a container that requires a range of ports to be mapped to it.
docker run -p 2000-3000:2000-3000 myapp
Nigel Brown has written a detailed article on The docker-proxy which explains the how and why.
The
docker-proxy
, then, is a 'catch all' method for allowing container port forwarding to the Docker host. However, it's generally considered that thedocker-proxy
is an inelegant solution to the problems highlighted above, and when a large range of container ports are exposed, it consumes considerable memory. An attempt was previously made to remove the dependency for thedocker-proxy
, but this fell foul of the limitations of the aged kernel in RHEL 6.x and CentOS 6.x, which the Docker project feels duty bound to support. Hence, thedocker-proxy
remains a major constituent part of the Docker experience in all Docker versions up to the current version 1.5. As I write, version 1.6 is due for imminent release, and there have been moves to remove the automatic requirement for thedocker-proxy
, which I'll cover in another article.
Docker now includes a daemon run time option to disable the userland proxy with --userland-proxy=false. This was introduced in v1.7.
There seems to be a few edge case bugs that exist when disabling the userland proxy. There are also IPV6 issues
There is an open GitHub issue for disabling the userland proxy by default (RHEL6 is no longer supported by Docker).
There doesn't appear to be a reason for this other than it was implemented this way. A single process should be capable of handling all of the port mappings for a container
The proxy implementation and package looks clean and uses in built Go functionality so this might just be Go's initial garbage collection limits that allow it to grow to ~ 5MB.
EDIT: Memory usage has been improved in Docker 1.12. There is still a process per port but each process now only uses ~ 750k of private memory space.