4 ms·

This is great. We use haproxy at my work and I like it, it does it's job, but quirks like dns resolution only at startup, having to reload on config changes and

This is great. We use haproxy at my work and I like it, it does it's job, but quirks like dns resolution only at startup, having to reload on config changes and no seamless reloading stop me from loving it.

blibble 9y ago
title of article says it now supports seamless reloading? what's the alternative to reloading on config change? automatic detection and reload on file change? personally I prefer the explicit action
- StavrosK 9y ago
  I, too, am wondering about that. The only alternative I can see to reloading is doing it automatically every file change, which means everything would break if I saved before everything was ready. I am perplexed.
  - phil21 9y ago
    It certainly does not automatically reload on configuration file change. This simply means you can have hitless reloads - change your configuration, reload HAProxy, and you will drop zero incoming connections during the reload time. Other methods previously existed to do this without having to first drain traffic, but they were both unwieldy and still tended to have a performance impact.
- Chronos 9y ago
  It still requires explicit action. However, the old way had a little dance between the old process and the new process: the new process tells the old process to start shutting down, the old process stops listening for new connections, then the new process starts listening for new connections. That left a gap where connections got rejected. The new technique is for the old process to use a Unix socket to seamlessly transfer ownership of the listening sockets to the new process. At no point are the listening sockets closed, so no connections are rejected. It's still a (potentially) new haproxy binary starting up and parsing the (potentially) changed haproxy config because the user requested a graceful restart.
  - vbernat 9y ago
    The new process listen to connections before the old process stop listening. The problem is that the old process can still have new connections queued up. They are lost when its sockets are closed.
tyingq 9y ago
Haproxy can be configured to cache dns resolves for shorter periods of time. Though there are some other limitations. Here's a thread showing a config that does that, and some of the limitations. http://discourse.haproxy.org/t/trouble-with-dns-resolvers-sticking-to-single-ip-address/146 http://discourse.haproxy.org/t/trouble-with-dns-resolvers-st...
r4um 9y ago
This is not needed since version 1.6 See https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#5.2-resolvers https://cbonte.github.io/haproxy-dconv/1.6/configuration.htm... It can do DNS resolution at runtime, additionally you can override bunch of options as to how DNS resolution behaves in terms of TTL, Failures etc

blibble 9y ago

title of article says it now supports seamless reloading? what's the alternative to reloading on config change? automatic detection and reload on file change? personally I prefer the explicit action

StavrosK 9y ago
I, too, am wondering about that. The only alternative I can see to reloading is doing it automatically every file change, which means everything would break if I saved before everything was ready. I am perplexed.
- phil21 9y ago
  It certainly does not automatically reload on configuration file change. This simply means you can have hitless reloads - change your configuration, reload HAProxy, and you will drop zero incoming connections during the reload time. Other methods previously existed to do this without having to first drain traffic, but they were both unwieldy and still tended to have a performance impact.
Chronos 9y ago
It still requires explicit action. However, the old way had a little dance between the old process and the new process: the new process tells the old process to start shutting down, the old process stops listening for new connections, then the new process starts listening for new connections. That left a gap where connections got rejected. The new technique is for the old process to use a Unix socket to seamlessly transfer ownership of the listening sockets to the new process. At no point are the listening sockets closed, so no connections are rejected. It's still a (potentially) new haproxy binary starting up and parsing the (potentially) changed haproxy config because the user requested a graceful restart.
- vbernat 9y ago
  The new process listen to connections before the old process stop listening. The problem is that the old process can still have new connections queued up. They are lost when its sockets are closed.

tyingq 9y ago

Haproxy can be configured to cache dns resolves for shorter periods of time. Though there are some other limitations. Here's a thread showing a config that does that, and some of the limitations. http://discourse.haproxy.org/t/trouble-with-dns-resolvers-sticking-to-single-ip-address/146 http://discourse.haproxy.org/t/trouble-with-dns-resolvers-st...

r4um 9y ago

This is not needed since version 1.6 See https://cbonte.github.io/haproxy-dconv/1.6/configuration.html#5.2-resolvers https://cbonte.github.io/haproxy-dconv/1.6/configuration.htm... It can do DNS resolution at runtime, additionally you can override bunch of options as to how DNS resolution behaves in terms of TTL, Failures etc