Open ppenguin opened 2 months ago
Hi, Thank you for opening this feature request ! :tada:
indeed the STREAM_HOST
would be more intuitive.
Could you develop a bit more on your use case for multiple STREAM_PORTS
? Thank you
For the suspected bug, I'll have a look into it and let you know !
Could you develop a bit more on your use case for multiple
STREAM_PORTS
?
In many cases where the infrastructure is not necessarily built on microservices, it could be pretty normal to expect that, say an user app or program, would want to connect to a non-http services.ourcorp.com:<port>
, where <port>
could be multiple ports, of which any should support specific configuration of any of the possibilities nginx
offers (so at least tcp, udp or both). Since the preread
selects based on vhost
, it is an unnecessary limitation to not offer multiple ports configuration.
The alternative is highly unattractive, since it would require adding a new vhost
to DNS, LetsEncrypt, the user app, etc, for each different non-http port that is exposed by the "functional unit" (e.g. a single container or task) behind BW.
What's needed and why?
Preamble
The intent of this issue is to collect recent experiences with trying to use
v1.6.x-dev
and ideas for solutions to issues.Background
a deployment under
nomad
where (for resource reasons) the BW instance was moved to a separatenomad
node (on anarm64
VPS) and all upstream services run on anothernomad
node (amd64
). There are services that need to be contacted both viahttp
(normal WAF function for BW) and withTCP/UDP
(vianginx
stream functionality of BW).Some observations
For now just a brain dump to not forget the topics:
USE_UDP
should not be exclusive, we need alsoUSE_TCP
STREAM_PORTS
(so both multi-site and multiple)REVERSE_PROXY_HOST
if there is no http endpoint but only a stream. In fact, we should haveLISTEN_STREAM_HOST
, because typically we prefix the upstream for a proxy withhttp://
and for a stream it would be a bare IP or hostname. (The suitability of the termLISTEN
in that context is debatable, because at least for the host we mean the upstream (forward)).... to be updated ...
Related suspected bugs
BUG:
my.server.com_LISTEN_STREAM_PORT
is overwritten in configI observed that the content of
/etc/nginx/my.server.com/server-stream.conf
hadin it just after start (which was the value I configuered with
LISTEN_STREAM_PORT
, but a few seconds later it was reset to another port number?!!!Ah, confirmed: this appears to be a bug in restoring config data from the cache or database, i.e. if there was an old value the new value doesn't overwrite it as expected.
BUG: http and stream forwarding doesn't work simultaneously
Related to observation (3) above:
http
doesn't work withouthttp://
prefix inREVERSE_PROXY_HOST
, butstream
doesn't work with it. So we need either a dedicatedSTREAM_HOST
or processing of the value, or process the proxy address. The former is much better, because it is necessary if we want to use the same vhost name for different upstreams for http and other backends.Implementations ideas (optional)
No response
Code of Conduct