5 ms·
Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker. > For my mental model, nginx is the right choice for SSL termination, lo
by TimWolla 4y ago
Disclosure: Community contributor to HAProxy, I help maintain HAProxy's issue tracker.
> For my mental model, nginx is the right choice for SSL termination, logging, request mangling, interpretation of cookies and loadbalancing based on request information (for example choosing haproxy instances based on a domain name).
HAProxy can do all that and IMO it also does it better.
Personally I chain HAProxy and nginx in reverse order: HAProxy exposed to the Internet, doing all the heavy lifting. (Multiple) nginx with minimal config as a static file server and FastCGI gateway behind HAProxy.
see also: https://news.ycombinator.com/item?id=27253579 https://news.ycombinator.com/item?id=27253579
- gregmac 4y agoI've done a similar architecture as well a couple of times. Both setups use multiple haproxy instances (auto-scaling group), multiple backend app servers, and each haproxy server has a local nginx instance. Nginx is used for serving some static error pages that live outside of the backend applications haproxy talks to (eg: "Customer domain not recognized"). There's some hacks to kind of make this work in haproxy but it's much simpler with an actual HTTP content server. Nginx also works well as a caching proxy, and what's really cool with haproxy is it's easy to have most requests go directly to the application server (avoiding an unnecessary proxy hop), but just pattern match certain types -- eg regex match `.jpg$` -- to go through the nginx cache. I've also used a similar technique to have per-domain custom images overriding specific URL paths (eg `/logo.png`), which was a really quick way to allow some customization of a multi-tenant application without having to make major code modifications to support it (only used for a tiny handful of customers).