31–40 of 55 posts
I spent a long time fighting this battle with nginx. I eventually came to the conclusion that while it was technically possible, it just wasn't worth the trouble (and yes, I tried various alternatives such as Tengine and OpenResty). What I settled on was the following: Ngninx for SSL termination in front of an haproxy load balancer. I wrote a simple Python script (92 lines of code) that spits out a new haproxy config…
Can you not assign static IPs to ELB instances? This might be a stupid question...ELB is one of the older AWS resources that I've never really touched since Nginx is so powerful & easy to set up.
I spent a long time fighting this battle with nginx. I eventually came to the conclusion that while it was technically possible, it just wasn't worth the trouble (and yes, I tried various alternatives such as Tengine and OpenResty). What I settled on was the following: Ngninx for SSL termination in front of an haproxy load balancer. I wrote a simple Python script (92 lines of code) that spits out a new haproxy config…
Any reason you don't use HAProxy for SSL termination too?
I spent a long time fighting this battle with nginx. I eventually came to the conclusion that while it was technically possible, it just wasn't worth the trouble (and yes, I tried various alternatives such as Tengine and OpenResty). What I settled on was the following: Ngninx for SSL termination in front of an haproxy load balancer. I wrote a simple Python script (92 lines of code) that spits out a new haproxy config…
What part of the battle couldn't you solve? Doesn't the author's setting of the resolver directive work for you, or is there something I'm missing? Also, the author doesn't mention it, but you can also set a custom cache timeout with the valid=Xs option. http://nginx.org/en/docs/http/ngx_http_core_module.html#reso...
Earlier quoted context omitted.
Any reason you don't use HAProxy for SSL termination too?
There are a lot of reasons. Simpler configuration, mutual SSL, URL rewriting and the like. That stuff would really suck if we only used haproxy.
There are some limitations of course, and I can see why you might want to use nginx for some routing. One of the more bizarre tricks I've had to use for more complex redirects (like non-www to www while properly injecting HSTS headers) involved sending the request to a backend that sent to a single frontend via a local port [1]. Hopefully that kludge will be fixed in 1.6.
1. http://blog.haproxy.com/2015/06/09/haproxy-and-http-strict-t...
Earlier quoted context omitted.
There are a lot of reasons. Simpler configuration, mutual SSL, URL rewriting and the like. That stuff would really suck if we only used haproxy.
HAProxy 1.5 does a pretty great job with that stuff now. I agree that the configuration syntax can be difficult but it is very powerful. There are some limitations of course, and I can see why you might want to use nginx for some routing. One of the more bizarre tricks I've had to use for more complex redirects (like non-www to www while properly injecting HSTS headers) involved sending the request to a backend that…
Bizarre tricks are not something I am a fan of deploying to production and using as the foundation for our service. That is hardly a compelling argument. ;)
For some reason it's the most popular reverse proxy for this sort of stuff, however it's not particularly well suited for it. We have this issue. We also have the lack of active upstream checks and any sort of upstream status reports. Both are hidden behind the nginx Plus paywall which is absurdly expensive in a micro-architecture world. There are various patches, Patches!?, you can apply but the documentation isn't fantastic and this is an extra bit of hassle we don't really deserve..
I think the open internet deserves a better reverse proxy TBH.
Earlier quoted context omitted.
> you would need to be able to handle reconnects, but that shouldn't be a new challenge for any system relying on connections being open for long That's true, but it kind of misses the point. Normally, if a connection is dropped it means something has gone wrong. In this case, connections are dropped by design , and there is no way (AFAICT) to work around this. Designing so that behavior that is otherwise the result…
I'd argue that this design promotes building reliable applications. A system that cannot reconnect is fragile, and the best way to know if the system can handle that failure is to occasionally induce the event. Assuming that you are running across a lossless, ideal network is, IMHO, the very definition of Bad Design. "If it hurts, do it more often." -- Martin Fowler
I've been working with nginx quite a bit recently for use as a reverse proxy in a containerized environment and have become quite disenfranchised with it. For some reason it's the most popular reverse proxy for this sort of stuff, however it's not particularly well suited for it. We have this issue. We also have the lack of active upstream checks and any sort of upstream status reports. Both are hidden behind the ngi…
https://github.com/bninja/rump
These are what the routing rules look like:
https://github.com/bninja/rump/blob/master/test/fixtures/set...