Re: Maintenance mode

On Thu, Sep 11, 2008 at 6:35 AM, Willy Tarreau <w#1wt.eu> wrote:
> In the mean time, I could propose you an alternative : make use of environment
> variables in the configuration, and just reload your config.

Another reason why this system is not ideal, though: It's not a clean separation between system-admin scripts and application-oriented scripts.

We use SysV-style /etc/init.d scripts in combination with Monit to control daemons like HAProxy. So the gory details of how HAProxy is controlled is actually hidden away in a bunch of OS-provided system scripts and configuration files, as is well and proper. Having these files be aware of application-specific environment variables breaks what I consider to be a separation of concerns.

Setting variables by communicating with a running HAProxy process is squeaky clean. What I just realized, however, is that using shared memory only is not enough; because if you restart HAProxy you want the currently set variables to survive.

So here's another solution which is potentially cleaner to implement: Add a mechanism to include configuration files in the main configuration file. With this, my configuration file could look like this:

  frontend http
    include /srv/myapp/config/haproxy/maintenance.conf     use_backend maintenance if maintenance_mode

and in maintenance.conf, which you then rewrite as needed, a catch-all like so:

  acl maintenance_mode path_beg /

Of course, changing variables still requires reloading HAProxy, so there's that, but it means you can maintain the variables separate from the main system config, and that they remain persistent across restarts.

An "include" command has other useful applications, such as splitting HAProxy configs into multiple pieces, Apache-style. It would be particularly nice if such a command could take a globbing pattern ("include /etc/conf/haproxy/conf.d/*.conf").

Did you get my complaints about multiple errant HAProxy processes, by the way? Just the other day I had four processes running. I have no idea why they never shut down, but I will try to do some process forensics the next time I catch one.

Alexander. Received on 2008/09/15 20:15