Next we define our https frontend which is where all traffic to Alfresco is handled:
# Main front end for all services
bind *:443 ssl crt /path/to/yourcert/yourcert.pem
capture request header X-Forwarded-For len 64
capture request header User-agent len 256
capture request header Cookie len 64
capture request header Accept-Language len 64
We now get into the more 'fun' part of configuring HAProxy - setting up the acls.
These acls are the mechanism used to match requests to the service to the appropriate backend to fulfil those requests, or to deny unwanted traffic from the service. I suggest that if you are unfamiliar with HAProxy that you have a good read of the docs for acls and what they can achieve (section 7 in the docs).
We separate out all the different endpoints for Alfresco into their own sub-domain name, e.g. my.alfresco.com for share access, webdav.alfresco.com for webdav, sp.alfresco.com for sparepoint access.
I'll use these three endpoints in the examples below, using the following mapping:
Share - my.yourcompany.com
Webdav - webdav.yourcompany.com
Sharepoint - sp.yourcompany.com
We first set up some acls that check the host name being accessed and match on those. Anything coming in that doesn't match these won't get an acl associated (and therefore won't get forwarded to any service).
acl robots - checks for a web bot harvesting the robots.txt file
acl alfresco_path - checks whether the request is trying to access the alfresco webapp. We deny direct access to the Alfresco Explorer webapp so you can remove this check if you want that webapp available for use.
acl share_path - We use this to deny direct access to the Solr API.
acl share_redirect - this checks whether there is any context at the end of the request (e.g. /share)
We next set up some deny settings, you can ignore these if you don't want to limit access to any service. The example below denies access to the Alfresco Explorer app from public use via the 'my.yourcompany.com' route. These use matched acls from earlier, and can include multiple acls that must all be true.
# Denied paths
http-request deny if alfresco_path is_my
Now we redirect to /share/ if this wasn't in the url path used to access the service.
redirect location /share/ if share_redirect is_my
Next we set up the list of backends to use, matched against the already defined acls.
# List of backends
use_backend share if is_my
use_backend webdav if is_webdav
use_backend sharepoint if is_sp
Then we set up the default backend to use as a catch-all:
Now we define the backends, the first being for share:
On this backend, enable the stats page:
# Enable the stats page on share backend
stats auth <user>:<password>
stats uri /monitor
stats refresh 2s
The stats page gives you a visual view on the health of your backends and is a very powerful monitoring tool.
option httpchk GET /share
cookie JSESSIONID prefix
server tomcat1 server1:8080 cookie share1 check inter 5000
server tomcat2 server2:8080 cookie share2 check inter 5000
These define the following:
backend share - this defines a backend called share, which is used by the use_backend config from above.
option httpchk GET /share - this enables http health checks, using a http GET, on the /share path. Server health checks are one of the most powerful feature of HAProxy and works hand in hand with tomcat session replication to move an active session to another server if the server your active session on fails healthchecks.
balance leastconn - this sets up the balancing algorithm. leastconn selects the server with the lowest number of connections to receive the connection.
cookie JSESSIONID prefix - this enables cookie-based persistence in a backend. Share requires a sticky session and this also is used in session replication.
server tomcat1 server1:8080 cookie share1 check inter 5000 - this breaks down into:
server - this declares a server and its parameters
tomcat1 - this is the server name and appears in the logs
server1:8080 - this is the server address (and port)
check inter 5000 - this sets the health check, with an inter(val) of 5000 ms
Define the webdav backend.
Here we hide the need to enter /alfresco/webdav on the url path which gives a neater and shorter url needed to access webdav, and again we enable server health checking:
option httpchk GET /alfresco
reqrep ^([^\ ]*)\ /(.*) \1\ /alfresco/webdav/\2
server tomcat1 server1:8080 check inter 5000
server tomcat2 server2:8080 check inter 5000
Define the SPP backend.
Here we define the backend for the sharepoint protocol, again with health checks:
balance url_param VTISESSIONID check_post
cookie VTISESSIONID prefix
server tomcat1 server1:7070 cookie share1 check inter 5000
server tomcat2 server2:7070 cookie share2 check inter 5000
Once this is all in place you should be able to start HAProxy. If you get any errors you will be informed on which lines of the config these are in. Or, if you have HAProxy as a service, you should be able to run 'service haproxy check' to check the config without starting HAProxy.
There are many more cool things you can do with HAProxy, so give it a go and don't forget to have a good read of the docs!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.