Haproxy (Originally High Availability Proxy) provides an industrial grade proxy to the Gentoo administrator routing traffic between ones frontend (web-facing) and backend (web-servers/web-services/databases). It reports connectivity statistics, performs health checks upon backend services and supports load balancing.
Interestingly, if one has multiple frontend machines HAProxy will redirect clients from one machine to another as they are taken offline ensuring a consistent service (One stands under correction on this point).
It handles both TCP (Level 4 in the OSI model) and the HTTP (Level 7 in the OSI model) routing (Routing further protocols seems possible too e.g. mail).
SSL termination may be done at Haproxy or passed through to be termination at the backend (SNI).
USE flags for net-proxy/haproxy A TCP/HTTP reverse proxy for high availability environments
||Device Detection using 51 Degrees|
||Add support for encryption -- using mcrypt or gpg where applicable|
||Use dev-libs/device-atlas-api-c library|
||Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally|
||Install examples, usually source code|
||Enable Lua scripting support|
||Enable network namespace support (CONFIG_NET_NS)|
||Add support for Perl Compatible Regular Expressions|
||Use JIT support for PCRE|
||Enable PCRE2 RegEx support|
||Use JIT support for PCRE2|
||Also build the prometheus exporter|
||Use dev-libs/libslz compression library|
||Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)|
||Enable use of systemd-specific libraries and features like socket activation or session tracking|
||Add threads support for various packages. Usually pthreads|
||Install additional tools (halog, iprange)|
||Pulls in related vim syntax scripts|
||Device Detection using WURFL|
||Add support for zlib (de)compression|
emerge --ask net-proxy/haproxy
The following software supports, compliments or integrates with Haproxy :
- An interactive ncurses client and real-time monitoring, statistics displaying tool for the Haproxy TCP/HTTP load balancer
- A load feedback and check agent for Haproxy
- A statistics collector which processes various statistics and pushes them to a graphing system (Graphite)
HAProxy serves the usual web-servers (Apache/Lighthttpd/NginX/Traefik) and databases (PostgreSQL/Redis/MySQL/CouchDB) and supports encryption (OpenSSL/LetsEncrypt). It will handle backend connections via unix and web sockets. These packages are used with haproxy and do not interact with it directly, hence are not listed here.
The global section, within Haproxy's configuration file, specifies the services permissions and behaviour upon ones system. This file is read sequentially and one may define One or more default block(s) may be set to define the common behaviour of the subsequent frontend/backend blocks; with later default blocks overriding the earlier ones.
In the example that follow one provide the minimal configuration necessary to enable some feature provided by Haproxy. By combining these examples one should be able to configure Haproxy for their own setup.
The following files and folders are used to configure Haproxy
* /etc/haproxy/haproxy.cfg - The main configuration file * /etc/haproxy/certs - The SSL certificates folder * /etc/openssl/private - An alternate, possibly better, location for SSL certificates
The haproxy user and group are configured by emerge during installation.
global user haproxy group haproxy pidfile /var/run/haproxy.pid daemon
This terminates the secure connection and passes the decrypted traffic on to the backend. This assumes the backend is run on a secured internal network.
Haproxy uses a single certificate for authentication purposes, that is an ordered and combined key, thing and thing. If ones certificates are supplied by letsencrypts' certbot then they may use the following line to generate a combined certiifcate for haproxy. The combined certificates should be stored under either the Haproxy folder, /etc/haproxy/certs, or the OpenSSL one, /etc/openssl/private (The author is not sure which of these paths is the canonical one).
SNI is performed within the TCP layer (Level 4 in the OSI model) allowing frontend connections over HTTPS to be directed to the appropriate backend. Only very old browsers do not support this e.g. I.E. on WinXP.
emerge --ask --depclean --verbose net-proxy/haproxy