This issue was created two years ago and still isn’t supported:
https://github.com/rancher/rancher/issues/1673
Why? This seems like an incredibly basic feature that Docker has supported for years.
The honest answer is because we unfortunately have limited resources and competing priorities. When sorting our github issues by most comments or most thumbs up, it doesn’t even make the top 25 in either of those lists.
I’m not trying to minimize it though. It is a useful feature. It bugs me that we don’t support it yet too. I’ll bring it up to see if we can do anything about it.
Is it particularly difficult to implement? It just seems like one of those things that would have been added at the same time as the normal port mapping. The syntax is pretty basic and just does the same thing in a loop. A bunch of the more niche features of docker-compose are supported so it’s really bizarre to me that it’s not present.
Thanks for the reply, btw. I appreciate that you guys don’t have all the time in the world, but I’d like to know if there’s something I’m not thinking about in the implementation that prevented it from being added.
It’s not incredibly difficult to implement but isn’t the easiest/quickest change in the world either. For better or worse (and getting better in the future), touching a field in the API means touching a bunch of projects: cattle, agent, go-rancher, rancher-compose, validation-tests, & UI off the top of my head. Depending on how we implement, this one might also touch rancher-metadata and our network-manager as well. (Ah, the joys of microservices). Additionally, this particular feature requires a little extra work in cattle than a normal pass-through field because we do container scheduling based off of ports. So this needs some consideration in cattle.
The initial problem for a long time was that actually telling Docker to do it was wildly slow and inefficient and spawned a separate proxy process for each port. Today it would be done through the CNI driver manipulating iptables rules and not involve the docker daemon at all.
Gotcha. Well, if you guys implement it any time soon, please please please do not do what Docker does. It goes through the range one-by-one and creates separate iptables entries for each one. This cause painful slowdowns on startup and it isn’t necessary. You can do this instead and get the same effect with a single iptables entry:
iptables -t nat -A DOCKER -p tcp \
-m multiport --dports ${PORT_RANGE} \
-j DNAT --to-destination ${IP}
If you have to open more than a handful of ports in a range, it’s much faster. You guys are managing iptables separately from Docker anyway, so I really hope you’ll consider using it.