Difference between revisions of "Haproxy"
(→SSL) |
|||
| (15 intermediate revisions by 4 users not shown) | |||
| Line 24: | Line 24: | ||
retries 3 | retries 3 | ||
option redispatch | option redispatch | ||
| − | |||
contimeout 5000 | contimeout 5000 | ||
clitimeout 50000 | clitimeout 50000 | ||
| Line 50: | Line 49: | ||
backend be_donkey | backend be_donkey | ||
| − | |||
dispatch 192.168.10.5:4080 | dispatch 192.168.10.5:4080 | ||
backend be_transmission | backend be_transmission | ||
| − | |||
dispatch 192.168.10.5:9091 | dispatch 192.168.10.5:9091 | ||
backend be_glassfish_dev | backend be_glassfish_dev | ||
| − | |||
dispatch 192.168.10.10:8080 | dispatch 192.168.10.10:8080 | ||
| − | backend be_glassfish | + | backend be_glassfish #if you want http-check you must use a loadbalancing setup like this |
option httpchk / | option httpchk / | ||
| − | + | balance roundrobin | |
| + | server 192.168.10.5:8080 check inter 2000 | ||
backend be_apache | backend be_apache | ||
| Line 72: | Line 69: | ||
</pre> | </pre> | ||
| + | |||
| + | ==logging== | ||
| + | |||
| + | Since haproxy is issuing new http requests the backend systems sees haproxy as the client. To circumvent this put these two options in haproxy (eg. under defaults): | ||
| + | <pre> | ||
| + | reqidel X-Forwarded-For #delete any existing x-forwarded-for headers befor option forwardfor injects its own | ||
| + | option forwardfor #enable sending the X-Forwarded-For http header to the servers | ||
| + | option httpclose | ||
| + | </pre> | ||
| + | |||
| + | You also need to make the backend servers understand the X-Forwarded-For header: | ||
| + | |||
| + | ===apache=== | ||
| + | You can either use a mod to make apache interpret the X-Forwarded-for header as the real remote ip. For apache 2.2 use mod_rpaf, apache 2.3+ can use mod_remoteip. Otherwise you can rewrite the LogFormat's and replace "%h" (host) with "%{X-Forwarded-For}i" | ||
| + | |||
| + | ===glassfish=== | ||
| + | Configuration -> http service -> access logging -> Format : replace %client.name% with %header.x-forwarded-for% | ||
| + | |||
| + | Tomcat users may want to look into [http://blog.techstacks.com/2010/01/tomcat-6-remoteipvalve.html RemoteIpValve] | ||
| + | |||
| + | |||
| + | ==SSL== | ||
| + | Haproxy can not decrypt ssl connections, so if you need https you can set up an [http://www.stunnel.org/ stunnel] service in front of haproxy which decrypts the ssl and forwards the requests to haproxy. | ||
| + | If you use the "proxy" protocol included in stunnel 4.45 and haproxy 1.5, stunnel can forward the clients IP adress to haproxy. | ||
Latest revision as of 08:41, 4 November 2011
Haproxy as content switch
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
#chroot /usr/share/haproxy
user haproxy
group haproxy
# uid 80
# gid 80
daemon
#debug
#quiet
defaults
log global
mode http
option httplog
option forwardfor
option dontlognull
retries 3
option redispatch
contimeout 5000
clitimeout 50000
srvtimeout 50000
frontend test-1 0.0.0.0:88
acl glassfish hdr_beg(host) app.t-hoerup.dk
acl transmission hdr_beg(host) t.t-hoerup.dk
acl donkey hdr_beg(host) donkey.t-hoerup.dk
acl glassfish-dev hdr_beg(host) app2.t-hoerup.dk
use_backend be_donkey if donkey
use_backend be_transmission if transmission
use_backend be_glassfish_dev if glassfish-dev
use_backend be_glassfish if glassfish
default_backend be_apache
# use_backend be_apache unless glassfish
#if this was a listener instead of a frontend-section then we could use the dispatch statement instead
# dispatch 192.168.10.5:9091 if transmission
# dispatch 192.168.10.5:4080 if donkey
# dispatch 192.168.10.10:8080 if glassfish-pumba
# dispatch 192.168.10.5:80
backend be_donkey
dispatch 192.168.10.5:4080
backend be_transmission
dispatch 192.168.10.5:9091
backend be_glassfish_dev
dispatch 192.168.10.10:8080
backend be_glassfish #if you want http-check you must use a loadbalancing setup like this
option httpchk /
balance roundrobin
server 192.168.10.5:8080 check inter 2000
backend be_apache
stats enable
stats uri /haproxy
dispatch 192.168.10.5:80
logging
Since haproxy is issuing new http requests the backend systems sees haproxy as the client. To circumvent this put these two options in haproxy (eg. under defaults):
reqidel X-Forwarded-For #delete any existing x-forwarded-for headers befor option forwardfor injects its own
option forwardfor #enable sending the X-Forwarded-For http header to the servers
option httpclose
You also need to make the backend servers understand the X-Forwarded-For header:
apache
You can either use a mod to make apache interpret the X-Forwarded-for header as the real remote ip. For apache 2.2 use mod_rpaf, apache 2.3+ can use mod_remoteip. Otherwise you can rewrite the LogFormat's and replace "%h" (host) with "%{X-Forwarded-For}i"
glassfish
Configuration -> http service -> access logging -> Format : replace %client.name% with %header.x-forwarded-for%
Tomcat users may want to look into RemoteIpValve
SSL
Haproxy can not decrypt ssl connections, so if you need https you can set up an stunnel service in front of haproxy which decrypts the ssl and forwards the requests to haproxy. If you use the "proxy" protocol included in stunnel 4.45 and haproxy 1.5, stunnel can forward the clients IP adress to haproxy.
