Re: HAProxy Hot Reconfiguration with s6

From: Laurent Bercot <ska-supervision_at_skarnet.org>
Date: Tue, 17 May 2016 03:00:58 +0200

On 16/05/2016 23:50, Remko Tronçon wrote:
> You spawn a new haproxy instance yourself, and pass it the PID of the
> process you want to replace:
>
> haproxy -f haproxy.cfg -sf $(pidof haproxy)
>
> The new instance uses SO_REUSEPORT to attach to the same port, and
> then sends a FINISH signal to the given PID to gracefully shut down
> the running instance.

  Yeah, that's not going to work as is with s6; you'll need workarounds.

  It's a quite quirky way to proceed; generally, processes that want to
replace themselves do so by execve()ing into themselves when they get a
certain signal - so they keep the same pid, and it works transparently
with supervision.
  Here, you spawn a different instance, and the pid changes, so you cannot
reuse the same service. However, you can use two services (a current one
and a backup one), and alternate between the two. It's more complex, but
it can be made to work. Here's how I would do it:

  * have two services haproxy-1 and haproxy-2.
  * have symbolic links haproxy-current and haproxy-alt (*not* in the
scandir); initially the former points to haproxy-1 and the latter points
to haproxy-2.
  * Both services have the same run script: run by replacing the pid of
the service running as haproxy-current
  * Have a distinct "restart-haproxy" script, that will be the only one
you execute manually when you want a haproxy restart. This script
    - performs s6-svc -O on haproxy-current
    - listens to haproxy-current then performs s6-svc -u on haproxy-alt
(use s6-svlisten1 for this)
    - when haproxy-current is down, switches the symlinks so that the
"up" service is always named haproxy-current.

  This setup will flip-flop between haproxy-1 and haproxy-2. Depending on
how haproxy reacts to being given an invalid pid to replace, you may need
to specialcase the first start (at boot time) in the haproxy-1 run script.

-- 
  Laurent
Received on Tue May 17 2016 - 01:00:58 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC