4 ms·
Has HAProxy cleaned up their dynamic reload issues? I am a pretty big fan having used HAProxy in production, but compared to the relative simplicity of "nginx -
by rhymenoceros 8y ago
Has HAProxy cleaned up their dynamic reload issues? I am a pretty big fan having used HAProxy in production, but compared to the relative simplicity of "nginx -s reload" the restart complexity of HAProxy always gives me pause.
- rogerdonut 8y agoHello, HAProxy 1.8 brought hitless reloads and has solved all of these issues. You can find information on this here [1][2] [1] https://www.haproxy.com/blog/truly-seamless-reloads-with-haproxy-no-more-hacks/ https://www.haproxy.com/blog/truly-seamless-reloads-with-hap... [2] https://www.haproxy.com/blog/hitless-reloads-with-haproxy-howto/ https://www.haproxy.com/blog/hitless-reloads-with-haproxy-ho...
- rhymenoceros 8y agoThis is an improvement but it still seems like HAProxy is offloading a small (but annoying) amount of responsibility to users when handling restart requests. You still have to track the existing process' PID and give it to the new process, give the new process the same "-x [socket_file]" argument, and make sure the new process comes up before making any subsequent changes to the HAProxy config file. Does HAProxy have any plans to wrap this process juggling to make things as stupidly easy as nginx's reload behavior?
- rogerdonut 8y agoThe current method integrates with both init scripts and systemd. You shouldn't need to manually pass any of that information. Also, the -x option is not required if you are running HAProxy in master/worker mode in which case sending a SIGUSR2 to the master process would be sufficient. With that said, we do have further improvements planned for an upcoming release. Stay tuned :)