Nginx with dynamic upstreams • Hacker News Board

Re: Nginx with dynamic upstreams

#51

Post by Tenzer » Mon, Jul 27, 2015, 4:16 AM UTC

sprobertson wrote: post #26

Tenzer wrote: post #3

Earlier quoted context omitted.

It's good to hear it was of use to somebody :) I know you can use a map in Nginx to do what you ask for, as long as you have a list of domains already: http://nginx.org/en/docs/http/ngx_http_map_module.html#map . I can only imagine it also being possible to make fully dynamic, I just don't have a clear way of doing it in mind right now.

Lua + Redis is a nice way to do this, I have a small project https://github.com/spro/simon that does dynamic routing and load balancing based on Hostname -> IP:Port sets in Redis. Adding a new route is as simple as: sadd backends:hnapi.dev 192.168.0.42:10555

Neat! I want to get started on some Lua scripting as well, probably first to just get a bunch of metrics out of Nginx via StatsD. There's access to a whole bunch of numbers via Lua that you otherwise can't get out from the stub_status page.

Re: Nginx with dynamic upstreams

#52

Post by Tenzer » Mon, Jul 27, 2015, 4:17 AM UTC

mattdeboard wrote: post #29

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.

No, you can't. You can instead create your own EC2 server, give it a static IP (well, "Elastic IP") and then hope your own server doesn't go down. This is the reason why I prefer to use an ELB since I never seen stability issues with it.

Re: Nginx with dynamic upstreams

#53

Post by brryant » Mon, Jul 27, 2015, 4:51 AM UTC

Another way around the rewrite is to simply proxy_pass with the $uri: https://gist.github.com/sansmischevia/cf425d5ffe09f824cb27

Re: Nginx with dynamic upstreams

#54

Post by Tenzer » Mon, Jul 27, 2015, 5:07 AM UTC

brryant wrote: post #53

Another way around the rewrite is to simply proxy_pass with the $uri: https://gist.github.com/sansmischevia/cf425d5ffe09f824cb27

Sure, that's also what I cover in the post. The latter part about rewriting is only relevant when you want to have the service behind an ELB to be located at something else than "/".

Re: Nginx with dynamic upstreams

#55

Post by ishigoemon » Mon, Jul 27, 2015, 4:19 PM UTC

lisper wrote: post #38

ishigoemon wrote: post #28

Earlier 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!"

A TCP socket teardown followed by a reconnect is hardly the equivalent of ramming a floating chunk of ice. There are a bunch of reasons you will see that teardown in practice, like NAT timeouts in a home router, or carrier-grade 6to4 NAT, or mobile devices rehoming to a new tower, or anywhere else that state is tied to the path.

Sure this is a deliberately produced failure, but only in the sense that this is a "normal" failure. This is a condition that is to be expected on the internet, and this is simply an additional place it occurs.