Nice, hadn’t noticed the port range capability. The proxy_pass and just directly referencing the ip would make it nice and concise. Unfortunately I am wanting to balance across multiple backends, but this is all good to know come different requirements.
Cheers On Mon, Mar 2, 2020 at 2:02 PM Reinis Rozitis <[email protected]> wrote: > > I get that the NGINX listen statement works on an individual port basis, > so the equivalent of what's below in NGINX would at the very least require > 300 listen statements. > > You can listen on a port range (see below). > > > > > FYI I've tried referencing my own declared variables from within the > upstream as well as referencing $server_port but of course these don't > appear to be in scope. > > Depends if you want nginx to perform any active healthchecks and what kind > of backends those are. > > If it is http and you just need to redirect traffic instead of defining > upstreams a configuration with (way) less lines could be: > > server { > listen 10.1.0.1:2000-2299; > location / { proxy_pass http://127.0.0.1:$server_port; } > } > > > A fallback to another proxy could be configured via error_page (502). > Something like: > > error_page 502 @fallback; > location @fallback { proxy_pass http://10.1.0.2:$server_port; } > > But I don't think there is a way (at least in the base vanilla) nginx to > configure upstreams in a dynamic way with port ranges as in upstream {} > doesn't support variables for the server definitions. > > rr > > > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
