Nginx with dynamic upstreams

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&#x27;t worth the trouble (and yes, I tried various alternatives such as Tengine and OpenResty).<p>What I settled on was the following:<p>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 configuration and gracefully reloads haproxy whenever the DNS changes. That has (after fixing a bug or two in my code) been FAR more reliable than any other solution to this problem we&#x27;ve tried.<p>Bonus: haproxy is a superior load balancer with better runtime metrics and health checking options than nginx.

I&#x27;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.<p>For some reason it&#x27;s the most popular reverse proxy for this sort of stuff, however it&#x27;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&#x27;t fantastic and this is an extra bit of hassle we don&#x27;t really deserve..<p>I think the open internet deserves a better reverse proxy TBH.

Kong [1] (nginx + lua) is planning to have this feature for free. This is the issue open for support for dynamic upstream [2].<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;mashape&#x2F;kong" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mashape&#x2F;kong</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;Mashape&#x2F;kong&#x2F;issues&#x2F;157" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Mashape&#x2F;kong&#x2F;issues&#x2F;157</a>

Here&#x27;s an implementation that uses nginx&#x27;s X-accel-* headers to perform dynamic routing:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;bninja&#x2F;rump" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bninja&#x2F;rump</a><p>These are what the routing rules look like:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;bninja&#x2F;rump&#x2F;blob&#x2F;master&#x2F;test&#x2F;fixtures&#x2F;settings&#x2F;include.conf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bninja&#x2F;rump&#x2F;blob&#x2F;master&#x2F;test&#x2F;fixtures&#x2F;set...</a>

Am I wrong for thinking that failure to honor the TTL in the first place is a bug?

Thank you for this, it&#x27;s a decent start for me personally. I was previously using the DNS director in Varnish 3.x to do this which was removed in 4.x. The longer time goes on the more risk it is to be running older software so this has been a great help.<p>Oddly enough I&#x27;d never really considered nginx for the job despite using it to reverse proxy elsewhere. Sometimes you just need a poke in the right direction :)<p>Now I just need to figure a way to specify *.internaldomain so that nginx resolves www.example.com.internaldomain - where www.example.com is grabbed from the requested Host: header

Another way around the rewrite is to simply proxy_pass with the $uri: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;sansmischevia&#x2F;cf425d5ffe09f824cb27" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;sansmischevia&#x2F;cf425d5ffe09f824cb27</a>

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&#x27;ve never really touched since Nginx is so powerful &amp; easy to set up.