Kong [1] (nginx + lua) is planning to have this feature for free. This is the issue open for support for dynamic upstream [2].
Nginx with dynamic upstreams
41–50 of 55 posts
Re: Nginx with dynamic upstreams
#42I'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…
Have you looked into HAProxy? Health checks, SSL termination and a reasonable configuration DSL: https://www.digitalocean.com/community/tutorials/an-introduc...
I am acutely aware of HAProxy however the rest of the team is, no surprise I'm sure, familiar with nginx. Likely I'll end up doing the usual nginx->haproxy->backend chain again. HAPROXY appears to have an enterprise now(it may have had forever I just have not noticed) but it appears to be much more focused on value-add support and stack validation than hiding simple-to-implement stuff behind a paywall and open-core. This is more of a frustration with nginx which could be so much more for us if:
* They were not purposely holding back features so they can be pay-walled
* Re-compiling were not necessary to add functionality
* More cohesive modification ecosystem
I know I said "reverse proxy" which HAProxy is cleary the more superior, but I didn't mean to limit my statement to reverse proxies. nginx does have a lot of other functionality people rely on..
Re: Nginx with dynamic upstreams
#43Kong [1] (nginx + lua) is planning to have this feature for free. This is the issue open for support for dynamic upstream [2]. [1] https://github.com/mashape/kong [2] https://github.com/Mashape/kong/issues/157
Unfortunately kong still has a hard dependency on Cassandra.
Re: Nginx with dynamic upstreams
#44Kong [1] (nginx + lua) is planning to have this feature for free. This is the issue open for support for dynamic upstream [2]. [1] https://github.com/mashape/kong [2] https://github.com/Mashape/kong/issues/157
Unfortunately kong still has a hard dependency on Cassandra. https://github.com/Mashape/kong/issues/331
Before the end of the year Kong will support Postgres.
Re: Nginx with dynamic upstreams
#45I 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…
did you look at Kong? https://github.com/mashape/kong
Re: Nginx with dynamic upstreams
#46Re: Nginx with dynamic upstreams
#47Earlier quoted context omitted.
Have you looked into HAProxy? Health checks, SSL termination and a reasonable configuration DSL: https://www.digitalocean.com/community/tutorials/an-introduc...
I am acutely aware of HAProxy however the rest of the team is, no surprise I'm sure, familiar with nginx. Likely I'll end up doing the usual nginx->haproxy->backend chain again. HAPROXY appears to have an enterprise now(it may have had forever I just have not noticed) but it appears to be much more focused on value-add support and stack validation than hiding simple-to-implement stuff behind a paywall and open-core.…
Dynamic modules are on the road map, according to this article: http://www.infoworld.com/article/2951849/web-services/nginx-....
Re: Nginx with dynamic upstreams
#48Earlier quoted context omitted.
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
Certainly systems should be designed to be robust against failures. But encouraging this by deliberately producing failures in production seems like a bad idea to me. It's kind of like saying, "Let's see if the new hull design works by deliberately steering the boat into an iceberg!"
Bad analogy. It's like saying "let's see if the new hull design works by deliberately running it into things in a test laboratory setting". Because, y'know, if you deploy an application to production using a particular network configuration (that is, using an ELB) without testing it in a development/staging environment first, you're doing a poor job.
This disconnect behavior is just a property of the system. Either you design your application to handle it, or you use a different system. (Not that you can get away with not handling disconnects even without ELBs.)
Re: Nginx with dynamic upstreams
#49Am I wrong for thinking that failure to honor the TTL in the first place is a bug?
That was my first thought as well. It's a bit preposterous that a) there's an "unbreak this software" option at all, and b) you have to pay for the privilege to enable it.
Re: Nginx with dynamic upstreams
#50Earlier quoted context omitted.
I think the reasoning for it is for performance. If you can make all the DNS queries you need before you start serving any requests, then you don't have to wait for DNS servers while clients hammer your server. Ideally I would have like it to be an option though, instead of it basically having become a feature in Nginx Plus - if it wasn't for the way I described in the post.
It should just schedule a DNS update before the previous one has expired, and if the addresses have changed shift over, so it should not cause any delays.
I would expect that to be the way the Nginx Plus implementation works, but I have never had a chance to try it out.