HAProxy: How to temporary disable a back end server using the command line
claudiokuenzler.com
claudiokuenzler.com
The ease with which you can make real-time reactions to threats and conditions is really second to none, and with the ability to truly "hitless" reload (reload without affecting in-flight requests and connections) it makes those have immediate impact and no customer impact.
Sometimes the capabilities make the config a bit inscrutable, but other than that, I can't recommend it enough.
We ended up using HAPRoxy as front for pretty much everything (even if techncially slapping just Nginx would be simpler at first), just because it often happens that this and that needs to be added (stuff like adding proper headers when devs don't want to figure out how to make their '00s CMS emi the '20s security headers).
It can also talk directly via unix socket to the backends so you don't even need to have a bunch of ports open if you want to front something.
The general answer here, is no, I don't think you can do much in HAProxy that you can't do with OpenResty, but with HAProxy you generally don't have to pay the overhead of Lua (and HAProxy tends to be very well optimized, so the difference can be significant at high throughput of requests / bytes).
I think you'll find they're using ARR and not HAProxy for the "batteries included" load balancer. You can tell this from the cookie names "ARRAffinity" and "ARRAffinitySameSite".
Can also be done remotely https://github.com/Wirehive/haproxy-remote
hatop -s /var/run/haproxy/example.sock
F9 - Enable a backend server (Status: UP)
F10 - Disable a backend server (Status: MAINTENANCE)
https://www.haproxy.com/documentation/dataplaneapi/community...
as such we try to avoid reloading haproxy as much as possible. you can even renew a cert on-the-fly uploading the new cert via the admin socket.
Assuming you initialize every service you depend on at program start and not in the critical path and that health checks only function after this setup work has been done it simplifies operations a bit and decreases the liklhihood of configuration errors (a drained server in a load balancer) from persisting.
stats admin
```
403 Forbidden
nginx
```
This depends a great deal on the architecture of your application server and traffic load. There are a lot of reasons that it is nicer to use a queue in front of your load balancer, rather than use queues in your application server, or worse, use the operating system queue.
You must have SSL termination, logging, load balancing, and queuing. You probably want to modify headers and interpret cookies as well.
HAProxy is a queue that feeds into a load balancer. Nginx is a buffer that feeds into a load balancer (IIRC).
One useful property that HAProxy can ensure is no more than 1 request going to a server at a time. I believe (but potentially incorrectly) that nginx will fail requests, rather than "queue" them, if it tries to ensure this property. HAProxy also historically had health checks for backend servers, while for nginx it was a paid premium feature.
I could be wrong about nginx not being able to queue. It has been a while.
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 is the right tool for queuing and load balancing to servers that will actually fulfill the request.
> 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.
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).
See info below, correct link: https://www.claudiokuenzler.com/blog/1240/haproxy-how-to-dis...
Our software does change links sometimes (it follows redirects and also uses the canonical URL when it finds one), but from the logs it doesn't look like any of that happened here.