3 ms·

I prefer commenting out the entry referencing the server/node directly in the haproxy.cfg or even better, the code used to generate it und version control (Conf

• Napsty 4y ago
  Yes but a reload can still cut a KEEP ALIVE established connection (observed in older HAProxy 1.6). Probably solved in more recent versions though.
  • bsagdiyev 4y ago
    This may be resolved in newer versions but definitely bit me before in older ones. I just have a script that drains off the backends we need before putting them in maintenance mode. Makes working on individual hosts much easier.
  • endre 4y ago
    also, old haproxy process (with opened connections) still does checks which might be undesirable at scale. 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.
• linsomniac 4y ago
  Seems a little heavy weight for my "remove from LB, update code, add back to LB" Ansible script. :-)
  • hayst4ck 4y ago
    An alternative I like a bit more than, `remove, update, add back` is to set a signal handler to close the listening socket, wait for current requests to finish, and then exit. 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.
    • linsomniac 4y ago
      That sounds clever and interesting, but in my case I'm probably dealing with ~20 services, some we build some third party, so the "remove from load balancer then update" trick works well.