HAProxy Redis
-
Dear All,
HAProxy has a Redis health check method in its backend, which is quite useful for Redis NoSQL high availability settings.
Redis has released a new version 3.2 recently. Unfortunately, the HAProxy health check does not work with that version anymore. I am not certain if this is an issue with the upstream software or with this package. However, the problem applies to both the current HAProxy version haproxy-1.6.4 in the regular package and version haproxy-devel-1.7.d2 in the devel package.
The issue can be replicated with realative ease by using the docker containers of both versions of redis available on the docker hub.
Does someone know how to deal with this intelligently?
Regards,
Michael Schefczyk
-
Hi Michael,
I have no clue how redis is supposed to work.. But gave it a try and haproxy 1.6.4 tels me: "Layer7 check passed: Redis server is ok"
Used this to start my docker: docker run –name some-redis32 -d redis:3.2
When i telnet to the haproxy frontend i can send ping and info commands, output below:
ping +PONG info $2104 # Server redis_version:3.2.0 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:5382f69a4e75566b redis_mode:standalone os:Linux 3.13.0-32-generic x86_64 arch_bits:64 multiplexing_api:epoll gcc_version:4.9.2 process_id:1Can you tell me what is wrong with my testcase.?
Regards,
PiBa-NL -
Dear PiBa,
Thank you very much for checking it out! It turns out that the cause is not with pfSense or HAProxy, but rather with Redis. I was used to running the official redis docker container in a kubernetes cluster. I only need Redis in a very limited way: I am operating two owncloud servers which share file locking information via Redis. To get redis as highly available as possible while keeping things simple (or at least trying to), I was running one container in a cluster using NFS storage. Should the container or its host fail, the scheduler would restart the container on another host based on persistent NFS storage. HAProxy is to ensure that the container is reachable wherever it runs. That did work with no issues until Redis 3.0.7.
The Redis 3.2 container running in the same environment returns the following to the monitoring command:
(error) DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '–protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside. Error: Server closed the connection
That does make it obvious that things will not work. There are entries at github (e.g., https://github.com/docker-library/redis/issues/58) which were closed but not really solved in a way that would help me, yet. I will check out how to best deal with this in the kubernetes service definition or by building the image with an own dockerfile to modify the configuration file upfront.
Regards,
Michael
-
Hi Michael,
Ok, thanks for your followup :) i suppose it would be possible to use those config options to make it listen for outside requests, while still using other options for the storage.?. I'm not very handy with docker so far, i don't think i can give good advises there anytime soon..
Regards,
PiBa-NL