During configcheck the resolver portion of haproxy is not yet active. Thus during the check it uses the system resolver. Once actually running it will use the resolver from haproxy.
On Mar 4, 2016 16:26, "Arnaud B." <arn...@arnaudb.net> wrote:
Hi there,
First of all : I am very fond of HAProxy :-)
I was trying to do some service discovery with bind9 and HAProxy when I found an odd behaviour on the resolvers part.
Here are some config samples :
My frontend and backend and resolvers config:
resolvers discovery
nameserver jabba 172.16.0.2:53
resolve_retries 5
timeout retry 1s
hold valid 3s
frontend staging_frontend
mode http
bind 127.0.0.1:8013
default_backend staging_backend
backend staging_backend
server jabba php-staging.vra:8013 check resolvers discovery
a sample dig :
$ dig @172.16.0.2 php-staging.vra +short
172.16.0.2
So far, everything seems fine to me. But, when i reload haproxy's config :
mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : parsing [/etc/haproxy/haproxy.cfg:98] : 'server jabba' : invalid address: 'php-staging.vra' in ...I first questioned my configuration and checked everything out ... There was no obvious issue.
mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
mars 04 15:55:13 jabba haproxy[25262]: [ALERT] 063/155513 (25262) : Fatal errors found in configuration.
I checked my /etc/resolv.conf file and saw that my server wasn't using the same resolver. Its resolver did not had any knowledge whatsoever of php-staging.vra and it caused my configuration to fail on reload.
My /etc/resolv.conf was :
nameserver 8.8.8.8and became
nameserver 213.186.33.99
nameserver 172.16.0.2
search vra
nameserver 8.8.8.8
nameserver 213.186.33.99
permitting haproxy's reload.
My question is pretty simple : since there is a resolvers section in haproxy's configuration, is it possible to use it despite the server's resolv.conf?
Let me know if something's unclear in my explanation :)
