Consider adding ability to reload HAProxy

[InAnimaTe]

It would be really nice if there was an easy way to reload the haproxy instance in this image via doing something like docker exec -i -t haproxy /reload whilst it's running so it isn't necessary to restart the container itself (which then executes the like of haproxy -f <config> -p <pidfile> -d -D -sf $(cat <pidfile>))

However, I'm pretty sure the only way to do that is by providing a different init 1 process (i.e. supervisor) which may be unfavorable based on what these official repos/images are supposed to provide (which means I won't be too mad if this issue gets closed ;P)

[yosifkit]

Does Haproxy reload config when it receives a signal like SIGHUP?

[InAnimaTe]

Based on it's manpage, the answer is no. The key thing here is making sure we soft restart haproxy meaning that no connections get interrupted. The line I've provided allows for that. You can see why here.

[tkent-xetus]

+1

[mcbain]

+1

[yosifkit]

Seeing how this would require supervisor or something more complex, I am hesitant to add it to the official image. I think the docker way would be to start a new container and start routing connections through that.

[blop]

+1

I understand the official image must be as clean as possible.

However, not being able to reload configuration without breaking existing sessions will prevent many from using this image in production environment.

[bharrisau]

I'm going to play with a bash script similar to below. I'll send a PR if I can get it to work.

#!/bin/bash
function reload
{
  haproxy -f <config> -p <pidfile> -sf $(cat <pidfile>) &
  wait
}

trap reload SIGHUP
trap "kill -TERM $(cat pidfile) || exit 1" SIGTERM SIGINT
haproxy -f <config> -p <pidfile> &
wait

[blop]

Maybe we can be inspired by what @million12 wrote :
https://github.com/million12/docker-haproxy/blob/master/container-files/bootstrap.sh

It includes a inotify monitoring on the config file to reload automatically.
The haproxy is loaded as a daemon using -D and the bash script is the entrypoint.

[vankhoa011]

+1

[yosifkit]

@bharrisau any luck on creating one? I might try to tackle it later today or thursday, unless you beat me to it.

[bharrisau]

I went with the million12 repo instead, I got it working but it doesn't
react to the hosts file updating and haproxy only maps hostnames to IP on
startup/reset.
On 15 Sep 2015 5:40 am, "yosifkit" notifications@github.com wrote:

@bharrisau https://github.com/bharrisau any luck on creating one? I
might try to tackle it later today or thursday, unless you beat me to it.

—
Reply to this email directly or view it on GitHub
#5 (comment)
.

[romeroyonatan]

+1

[thoughtarray]

Reloading is a must, especially when using HAProxy for service discovery purposes. Using a inotify monitoring daemon would mean running multiple processes in the container. Consider using Unix Socket commands and putting that .sock file on a shared volume.

Might put something about this in the documentation so people can easily find it.

[thoughtarray]

Well, I might have to take this back. After some experimenting, it doesn't look like there is a Unix Socket command that will force HAProxy to re-evaluate it's config file. The reload command is great, but it does drop some (very few) packets. There is a lot of work in trying to achieve a "zero-downtime HAProxy reload"; so just codifying some kind of haproxy /reload might work for some, but not others.

[CBR09]

+1

[klausenbusk]

Maybe we could start haproxy with haproxy-systemd-wrapper, then sending USR2 should restart haproxy.

[klausenbusk]

I opened a PR #17

[narmontas]

Hello,

So how to do reload with the haproxy:1.6 version?

[Starefossen]

From #17:

Reload like docker kill --signal=USR2 or HUP

[narmontas]

It does not work. Is the version with reload feature pushed to docker hub?

[narmontas]

USR2 does not work, HUP works.

[tianon]

Should be pushed now! 👍

[cemarta7]

Sorry I have try HUP and it does not work I load also the config file as a volumen like this:

docker run -it -p 443:443 -v /etc/ssl/private:/etc/ssl/private -v haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg --name proxy --net mynetwork

am I doing something wrong?
docker kill --signal=HUP proxy

Like I try USR2, HUP and no luck

[tianon]

@cemarta7 are you sure you've got the latest version of the haproxy image? (did you docker pull recently?) are you overwriting the default command?

[cemarta7]

I tried with haproxy:1.6-alpine and haproxy:1.6.. will try with latest and let you know in a couple of mins

[cemarta7]

Tried with latest,alpine and nothing.
this is the output
<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /usr/local/etc/haproxy/haproxy.cfg -Ds
<5>haproxy-systemd-wrapper: re-executing on SIGHUP.
<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /usr/local/etc/haproxy/haproxy.cfg -Ds -sf

but changes on the haproxy.cfg are not being display.
am I doing something wrong?

this is my Dockerfile
FROM haproxy:latest
ENV DNS_TCP_ADDR 127.0.0.11
ENV DNS_TCP_PORT 53
VOLUME /etc/ssl/private
VOLUME /usr/local/etc/haproxy/haproxy.cfg
COPY ./haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

like should I load the volume with :ro?

[cemarta7]

I think issue should be reopen. no luck with "docker kill --signal=HUP container_name"

[yosifkit]

COPY cannot go after the VOLUME or the file will not persist into the image (though this is irrelevant when you bind mount a local file into the container on that same path).

$ docker run -it -p 443:443 -v /etc/ssl/private:/etc/ssl/private -v haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg --name proxy --net mynetwork haproxy

Assuming this is your run line, if you start the container and edit the file locally with something like vim, then the container will be unable to see the change: (moby/moby#15793 (comment))

[multani]

Same problem here.

I'm running HAProxy 1.6-alpine at the moment (tried 1.6 just before) with the following Docker command line:

docker run -v /srv/haproxy/haproxy.cfg:/haproxy.cfg:ro -p 80:80 haproxy:1.6-alpine haproxy -f /haproxy.cfg

Sending the HUP signal produces the following logs:

<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /haproxy.cfg -Ds 
<5>haproxy-systemd-wrapper: re-executing on SIGHUP.
<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /haproxy.cfg -Ds -sf 8 
<5>haproxy-systemd-wrapper: re-executing on SIGHUP.
<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /haproxy.cfg -Ds -sf 10 
<5>haproxy-systemd-wrapper: re-executing on SIGHUP.
<7>haproxy-systemd-wrapper: executing /usr/local/sbin/haproxy -p /run/haproxy.pid -f /haproxy.cfg -Ds -sf 12 

but it doesn't pick up the new configuration. Restarting the container altogether works though.

[multani]

Meh, OK, that was stupid of me.

I replaced the bind mount with the following:

docker run -v /srv/haproxy/:/data/:ro ... haproxy -f /data/haproxy.cfg

And that's much better. I'm using consul-template to regenerate the configuration file, and by default it erase the file and recreates a new one. Since the first version must be mounted somehow via my first docker run command inside the container, it doesn't pick up the updated version. Mounting the parent directory instead fixes the problem...

[hgl]

How to reload haproxy with the new config feature? It seems an config created by docker config create can't be updated.

[hgl]

not sure if this relates to moby/moby#35048