Hi,
I have the following setup:
and the problem is that when a petition comes in through haproxy01, then it is forwarded to Pub-agent1 and the user logs into the app, the next time we might be redirected from haproxy01 to Pub-agent2, so the user has to log in again. How would I solve this problem?
I guess one option would be stick on source, the other could be sending all traffic to one marathon-lb instance and when this one goes down, send everything to the other.
How are you handling those situations?
Hi,
Simply enable cookie based persistence.
Baptiste
Hi,
Thanks, Do I need to add something to Marathon-lb in order to work together with the previous HAProxy instance? I’ve seen that send-proxy-v2 and accept-proxy may be needed but I cannot get it to work. So traffic gets to Marathon-lb:443 but doesn’t forward to frontend_containerX
I have no idea what how marathon does manage HAProxy’s configuration.
Ok, but let’s say I have 2 HAProxy chained before the app itself, should I specify something on both HAProxy?
Let’s say I have:
User–>HAProxy1–>HAProxy2–>App
Thanks.
Nothing particular. You might want to know the client IP address at the app level, in such case, you have to enable Xforwardfor in HAProxy1.
So do you have any idea what could be happening with this setup?
frontend dcosweb_ssl
bind 10.11.6.60:443 ssl crt /etc/haproxy/embl.pem
mode http
default_backend dcosweb_ssl_back
description dcos-web-vip.embl.de SSL version
log global
maxconn 8000
monitor-uri /monitordcosweb
option httplog
option dontlognull
timeout client 30s
backend dcosweb_ssl_back
mode http
balance source
option httpchk /_haproxy_health_check
retries 2
timeout connect 5s
timeout server 31s
server dock-pub-agent01 10.11.6.33:443 check port 9090 send-proxy-v2 inter 5s fall 4 rise 3 ssl verify none
server dock-pub-agent02 10.11.6.34:443 check port 9090 send-proxy-v2 inter 5s fall 4 rise 3 ssl verify none
I found the problem, I wasn’t passing the SNI from the first to the second load balancer:
sni ssl_fc_sni
