skip to Main Content

I am running very lightweight Docker images in a Docker swarm environment. For this I forward a random port to the destination port inside the container. Here is an example output:

y0xxxjj8kvi3   foo-test-1 1/1   strm/helloworld-http:latest  *:30001->80/tcp
37f4czmipex0   foo-test-2 1/1   strm/helloworld-http:latest  *:30002->80/tcp
qmzjlxt95n8r   foo-test-3 1/1   strm/helloworld-http:latest  *:30003->80/tcp
...

As you can see, the more services I deploy, the more ports are being used. Does this mean the number of services is limited by the number of ports available to the network stack? Is there another network mode that is more suitable?

Currently the routing is done by the Docker swarm routing, but I have a load balancer ready that could forward the calls to the containers directly using their virtual IP address, but I am not sure if that solves the problem. Which network mode would be best fitting for this?

Thanks!

Edit: I am aware that Kubernetes might be the better fit here given the limitations, but I am still curious to solve this with Docker swarm.

2

Answers


  1. There are theoretically 65,535 ports per IP address, but this isn’t related to Docker Swarm.

    Since you’re using Swarm as an orchestration engine, you can spin up additional nodes and have them join the swarm using docker swarm join. Then you’ll have additional ports available.

    However, the way you’ve phrased this question does raise questions about your intended use case. I typically only expose a small number of ports of to external clients (say, 80 and 443 for web apps, 5432 for postgres, etc). I may use swarm networking to do some simple load balancing, for example. For a web application, I can run nginx or another reverse proxy and forward the requests to an "internal" network, for example; In that case never expose the ports to the public network at all.

    Login or Signup to reply.
  2. Realistically the exposed ports are not an issue as in any production setup you would run services behind reverse proxies. Traefik, nginx, caddy, haproxy etc. All of these can listen on :80 or :443 and then route traffic to the appropriate service over docker networks.

    This means, you need to examine the limitations of docker networks. In a default install, docker swarm allocates overlay networks as /24, giving essentially 254 IPs to allocate to services. In endpoint_mode vip, services allocate an IP for a vip AND a IP for each task, in endpoint_mode dnsrr, only an IP per task container. Unless you are careful, this can limit you to 127 service attachments per network.

    You can make overlay networks larger but the overlay network driver references moby/moby#44973 which limits you to increasing the overlay networks to 1024 (/22) in size. (The Swarm Networking page mentions an older issue moby/moby#30820 which has been fixed)

    So, your limitation is 500-1000 services per reverse proxy network. However this does not apply any kind of hard limit as you can attach a reverse proxy to multiple networks. As each network is modelled as an interface being attached I can’t even hazard a guess as to what that limit is.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search