Hi, I am looking for a way to (1) report health from a haproxy instance, such that (2) the health response is set by another "decider" process on the same host. What is the best way to go about it? I am using version 1.7.1 but can upgrade if need be.
We can assume that the decider process sets an environment variable, say HEALTHY, to true or false at any time it wants. We would like an haproxy instance to return a healthy signal iff it is genuinely healthy and the HEALTHY environment variable is set to true. I thought of the following options: 1) Use monitor-uri with 'monitor fail if' clause that uses 'env' fetch method (https://cbonte.github.io/haproxy-dconv/1.7/ configuration.html#7.3.2-env): This doesn't work since 'env' reads the env variable only on haproxy start. 2) Expose a different port and URI than monitor-uri for health check (e.g. /health-uri at port 12345) that is answered by a Lua script. The Lua script uses os.getenv() to read the HEALTHY env variable as well as ping monitor-uri and returns a successful result only if both steps are successful. The haproxy docs (http://www.arpalert.org/haproxy-lua.html#h204) says that many Lua functions, especially file access ones, are prohibited as they block. Is os.getenv() also not allowed? 3) Have a separate inetd-based script running at, say, port 12345 that does both the steps that the above Lua script does. This solution is hinted at by the docs (https://cbonte.github.io/haproxy-dconv/1.7/ configuration.html#port). Is option #2 feasible (os.getenv())? Are there other workable options? Which of the feasible options is better? Readers may ask "what are you trying to achieve?", so I will list my use case as well. USE CASE: We use haproxy in docker container in our production environments. Every container in our datacenter is restarted every 2 weeks. We don't want traffic processing to be disrupted during such planned restarts. So, we plan to achieve a graceful restart in the following way: 1) Intercept container kill signal issued by Apache Aurora 2) The interception is done by the 'decider' process which then sets HEALTHY=false 3) This should cause haproxy to fail health signal to upstream systems (e.g. AWS route 53) 4) This should cause upstream systems to NOT send new requests to haproxy while at the same time allow it time to finish processing in-flight requests 5) Once in-flight requests are processed completely (as reflected in connection count or a fixed timeout), the decider process lets the container shutdown to proceed Thanks!
