This is embarassing. I'm getting a 502 Proxy Error.
Well. That means that HAProxy is still up when the backend servers aren't. "embarassing" isn't the terminology I'd use in this case.
How embarrassing for OP!
HAProxy 1.5
21–30 of 51 posts
Re: HAProxy 1.5
#22Impressive list of features. Does anyone know if HAProxy is used by any IAAS/PAAS providers?
We heavily use Haproxy at Clever Cloud
Re: HAProxy 1.5
#23Earlier quoted context omitted.
What about SSL? HAProxy supports SSL offloading.
I didn't investigate deeply; I'd never heard of haproxy prior to Fitbit. Someone from site ops told me they use nginx + haproxy but it would be easier for me to just set up nginx. This article does sound to me like SSL support in haproxy is brand new: http://seanmcgary.com/posts/using-sslhttps-with-haproxy
SSL support has been around for a while, but 1.5 has been considered beta for a few years now, though that hasn't stopped it from being deployed in a lot of production environments.
Before SSL was rolled into haproxy, nginx was often a good candidate to handle the SSL termination. Stunnel is also common, and stud was popular for a while, but seems it was abandoned once haproxy could handle the job.
Re: HAProxy 1.5
#24Impressive list of features. Does anyone know if HAProxy is used by any IAAS/PAAS providers?
I have the sneaking suspicion that Amazon's Elastic Load Balancer is based on HAProxy (and has been tracking the 1.5 series in development for some time). Nothing particularly evidentiary, but it's a glass slipper that fits very snugly.
AWS is certainly on the list of "Who is using HAProxy" here: https://www.haproxy.com/
Re: HAProxy 1.5
#25Thanks for all hard work. I had checked 1.5 dev build 2-3 months ago, enabling SSL was causing very high CPU. Must have been good now.
Re: HAProxy 1.5
#26Impressive list of features. Does anyone know if HAProxy is used by any IAAS/PAAS providers?
Linode's NodeBalancers are clearly HAProxy. I just wish they exposed more config options (such as the PROXY protocol - it's useless for SMTP without that).
Re: HAProxy 1.5
#27This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.
Wouldn't you get the same with a HAProxy reload with a SIGTERM?
Re: HAProxy 1.5
#28This release contains a neat feature: you can now bind HAProxy to a specific FD opened by its parent process. This means that you can babysit your HAProxy processes underneath a parent process that opens ports and get hitless HAProxy restarts, which I've long desired.
Wouldn't you get the same with a HAProxy reload with a SIGTERM?
No, not really, for short period of time you've got state where previously configured instance is not working already and future one is not working yet.
Re: HAProxy 1.5
#29Earlier quoted context omitted.
Wouldn't you get the same with a HAProxy reload with a SIGTERM?
No, not really, for short period of time you've got state where previously configured instance is not working already and future one is not working yet.
This is generally correct. In particular, when the HAProxy process is stopped/restarted there is a brief period during which the port is not bound by either process. (If the new process isn't able to get the socket when it boots it will sleep ~XXms, then try to bind/listen in a loop until it gets it or a retry threshold is hit.) During this time the kernel will reject incoming connections to the HAProxy port, so you are in danger of dropping incoming requests on the ground.
Re: HAProxy 1.5
#30Earlier quoted context omitted.
Wouldn't you get the same with a HAProxy reload with a SIGTERM?
No, not really, for short period of time you've got state where previously configured instance is not working already and future one is not working yet.
Oh, you are right, after searching a little on the subject it looks like some people are doing things like this:
iptables -I INPUT -p tcp -m multiport —dports 80,443 —syn -j DROP && sleep 0.5 && \
/etc/init.d/haproxy reload;
iptables -D INPUT -p -tcp -m multiport —dports 80,443 —syn -j DROP