[feature-request] Allow specifying port ranges in network stanza

[ryanmickler]

I have a 'system' job that starts couchbase server instances, using the official couchbase server container. This container needs a lot of ports open (e.g. 21100-21299) to share data when running in clustered mode. The only way we've been able to get this to work

               network {
                    #...
                    port	"nodeDataA"	{ static =  21100 }
                    port	"nodeDataB"	{ static =  21101 }
                    port	"nodeDataC"	{ static =  21102 }
                    #...
                    }

in the network block, and a similar thing in the port_map block. (you can imagine how huge the jobfile has become)

Is there another way to achieve this?

Can i suggest something like

                network {
                    # ...
                    port_block	"nodeData"	{ 
                        static_range_begin =  21100
                        static_range_end =  21299
                       }
                    # ...
                    }

[schmichael]

Thanks for the good writeup and use case @ryanmickler! Seems like something Nomad should handle better.

[joshuaclausen]

2 use cases that being able to specify the dynamic port range in the network stanza would support:

1. Legacy applications that have external dependencies on a specific port range, e.g. Xbox Live Services requires a defined port range for online services that an application on an Xbox will be permitted to call out to. That list may not be in the default Nomad port range.

2. Applications (legacy ones especially) that need to restrict access to specific client IPs could specify a port range that falls within a predefined firewall rule on the nomad client host.

[shantanugadgil]

I have recently solved this using a jinja template and a for loop within jinja to do something similar.
I also added the for loop for the service blocks.

FWIW, I changed the restart mode of the job to fail as all processes inside the job don't necessarily exist all the time.

[joshuaclausen]

I solved this by setting some meta tags in the jobspec that defined my desired port range, writing a "harness" script that picked a port from that range, making sure no other processes were listening on that port, and then running my executable on that port. I have no network resource stanza in the jobspec now, but that seems to be just fine as far as Nomad is concerned.

I can see how it may be wise to leave this sort of use case up to the user to solve.

[lmayorga1980]

I think this fits into my current scenario

Dockerfile

##
EXPOSE 5000-5200
##

Do I need to expose those 200 ports explicitly into the nomad job specification file? That is 200 extra lines.

[sanjeevkumarraob]

This is a must support for nomad. When this will be implemented?

[kholisrag]

I solved this by setting some meta tags in the jobspec that defined my desired port range, writing a "harness" script that picked a port from that range, making sure no other processes were listening on that port, and then running my executable on that port. I have no network resource stanza in the jobspec now, but that seems to be just fine as far as Nomad is concerned.

I can see how it may be wise to leave this sort of use case up to the user to solve.

Hi can you share from technical perspective, I need a port range scenario too, to solve my problems

[konsti]

Another use case is WebRTC where typically a range of UDP ports need to be opened.

[ghost]

Another use case is WebRTC where typically a range of UDP ports need to be opened.

exactly my issue, so having to drop nomad for now
back to k8s

[shantanugadgil]

Another use case is WebRTC where typically a range of UDP ports need to be opened.

exactly my issue, so having to drop nomad for now back to k8s

🤕

Just thinking and a curiosity question: An external job file generator like Levant, Nomad's Terraform provider ❓ , some jinja based wrapper, etc. did not work?
(anything which has a loop construct)

I think one of the problems with block ranges would be how the port name would be referenced. As of today every port has an identifier.

[ryanmickler]

Thanks @shantanugadgil, Indeed, I ended up using terraform to provision the nomad job file (and deploy the job), so that i could loop over the ports.

[ghost]

Thanks @shantanugadgil, Indeed, I ended up using terraform to provision the nomad job file (and deploy the job), so that i could loop over the ports.

hmmm, yeah that would work. but I need to open up 10000 ports (yes, 10 thousand), for webrtc, 50-60k
might be a stretch 😸