Well =fun should be a variable name. But the name, whatever it is, should
always be routed to the same ip based on some consistency algorhithm.
I've build some DNS server to correct for the randomizing of the server
list from the dns. So the following:
dig @ordered-dns-proxy chat
always gives me the list:
10.0.0.11
10.0.0.12
10.0.0.13
in this order.
My config now looks like:
-------------
defaults
mode http
timeout client 5s
timeout connect 5s
timeout server 5s
resolvers dns
nameserver srv_dns ordered-dns-proxy:53
frontend all
bind :80
mode http
timeout client 120s
option forwardfor
default_backend chat
backend chat
balance url_param chatName
timeout server 120s
server srv_chat chat:80 resolvers dns
---------------
But still not working. It is always routed to a different server.
What I want to accomplish is something like.
dig @ordered-dns-proxy chat
always gives me the list:
10.0.0.11
10.0.0.12
10.0.0.13
I want to have the connection:
?chatName=xxxx
crc32(xxxx) % 3 is for example 2
always route to the second server in the dns list.
With my current config this won't happen. The balancer is always going to
the first.
2017-10-11 1:27 GMT+02:00 Igor Cicimov <ig...@encompasscorporation.com>:
>
>
>
> On Tue, Oct 10, 2017 at 11:25 PM, Ruben <rdoc...@gmail.com> wrote:
>>
>> I have some stateful chat servers (SockJS) running in docker swarm mode.
When doing dig chat I get an unordered randomized list of servers for
example:
>>
>> (every time the order is different)
>> 10.0.0.12
>> 10.0.0.10
>> 10.0.0.11
>>
>> The chat is accessed by a chatName url parameter. Now I want to be able
to run a chat-load-balancer service in docker with multiple replicas using
the haproxy image.
>>
>> The problem is that docker always resolves to a randomized list when
doing dig chat.
>>
>> I want to map the chatName param from the url to a fixed server which
always have the same ip from the list of ips of dig chat. So the mapping of
the url_param should not be based on the position of the server in the
list, but solely on the ip of the server.
>>
>> So for example ?chatName=fun should always route to ip 10.0.0.12, no
matter what.
>>
>> My current haproxy.cfg is:
>>
>> defaults
>> mode http
>> timeout client 5s
>> timeout connect 5s
>> timeout server 5s
>>
>> frontend frontend_chat
>> bind :80
>> mode http
>> timeout client 120s
>> option forwardfor
>> option http-server-close
>> option http-pretend-keepalive
>> default_backend backend_chat
>>
>> backend backend_chat
>> balance url_param chatName
>> timeout server 120s
>> server chat chat:80
>>
>> At the moment it seems that only the Commercial Subscribtion of Nginx
can handle this kind of cases using the sticky route $variable ...;
directive in the upstream module.
>
>
> Maybe try:
>
> http-request set-header Host 10.0.0.12 if { query -m beg -i chatName=fun }
>
