Installing HAProxy 2 LTS on CentOS 7.9

The purpose of this article is to demonstrate how a modern version of HAProxy 2 long term support (LTS) can be installed on a CentOS 7.9 server. Although HAProxy RPMs are available under EPEL with CentOS, they lag behind the current LTS versions available (the major version is 2.6 as of this writing - information on HAProxy releases and LTS schedule can be found in the table published at the HAProxy website).

Finding information online for this procedure can be difficult and, unfortunately, much of it can be incomplete re: steps related to logging and proper integration with systemd. We will cover those items as well. Installation of CentOS 7.9 Server and creating a full working HAProxy configuration will be kept out of scope, however. The focus will be on building and installing necessary binaries, setting up logging with rsyslog, and confirming basic operation.

This work is derived from the following resources, although we cannot guarantee the referenced links will always be available. All the more reason to capture the process here.

Install HAProxy 2 on CentOS 7

How to install the latest version of haproxy on centos 7

Regarding CentOS 7.9 and OpenSSL

The reader should be aware that the latest version of OpenSSL available in the CentOS 7.9 repo is “OpenSSL 1.0.2k-fips”:

Per the vulnerabilities page on the OpenSSL web site (found here):

“Note: All OpenSSL versions before 1.1.1 are out of support and no longer receiving updates. Extended support is available for 1.0.2 from OpenSSL Software Services for premium support customers.”

If you do plan to use CentOS 7.9 in production with HAProxy encapsulating traffic with SSL/TLS, you will need to bear this in mind. Upgrading OpenSSL on CentOS 7.9 to a more current release is out of scope for this article and is left as an exercise to the reader.

Installation Procedure

Prepare the Build Environment and Download HAProxy

Log into your CentOS 7.9 Server as ‘root’ user and perform the following…

Install the packages needed to compile HAProxy from source (note the package ‘systemd-devel’, this is needed for systemd integration for HAProxy when it’s built):

Next, download the HAProxy version that you want to build (versions available can be found here, in our example we will build version 2.6.6):

Unpack the file and change directory into where it was unpacked:

Once in the main source directory, build HAProxy using the build flags outlined below (note the build directive for USE_SYSTEMD=1, this is needed for systemd integration). Note also that we add the flag USE_PROMEX=1 to enable the built-in Prometheus exporter for HAProxy:

Create the directory /etc/haproxy in preparation for performing install of the binaries and as a home for the haproxy.cfg we will need to create, then perform the installation:

After that step, you should see haproxy installed in /usr/local/sbin on the server, you can then run a quick version check to make sure it can execute:

Now that we have the necessary binaries installed, we can move on to configuration. There are two things that need to be set up next:

• The HAProxy systemd service file

• The haproxy.cfg file

This is done as follows, first for the systemd service file:

Next, we use a similar technique to create a very basic haproxy.cfg file for testing. Note that we are overriding the default logging approach here which uses a Unix socket target. Our goal is to drop in the necessary hooks to allow us to send logs to a remote logging server. For testing purposes to that end, we will send all HAProxy log traffic over default UDP port 514 to an rsyslog server running on the same host, using logging facility '1' (this is done with the line “log 127.0.0.1 local1").

NOTE: this is not a fully functional haproxy.cfg example, this is only a stub to test logging!

Now, with these two items in place, we need to perform some changes to the /etc/rsyslog.conf file to allow it to act in the role of “remote log server”. We also want to avoid having these log messages sent to other log file targets on the system (such as the /var/log/messages file). We make the following changes to rsyslog.conf to accommodate this.

Uncomment the lines in /etc/rsyslog.conf for handling remote UDP log traffic:

Next, make adjustments to the “RULES” section in rsyslog.conf for the log facility directives related to /var/log/messages:

Finally, you will need to add a facility definition for local1 so that all messages using that facility (which should be dedicated for HAProxy) are logged in /var/log/haproxy.log:

Once those changes are made for rsyslog, you will need to restart it for them to take hold. You can check its status after issuing the restart also in case there were any errors in the above changes:

We should now be ready to start HAProxy as follows, along with checking its status in case there are any errors on startup. It helps to have an empty log file ready in /var/log/haproxy.log so we include that step here as well:

If all is working properly, you should see the following output in /var/log/messages:

Now, let’s generate a smoke test of client traffic against the system to make sure session traffic is being properly logged in /var/log/haproxy.log. This can be done with the simple curl command below, run it for a couple of seconds then hit ‘^C’ to exit out:

After breaking out of the above curl command, you should see session log entries present in /var/log/haproxy.log per the example below (Note again, this isn’t representative of logging production HTTP/HTTPS traffic, it’s simply a test to see if communication to the remote log server works - your eventual log entries will be different in practice when you set things up to perform real load balancing work):

If you see this, then you have a working HAProxy 2.6 LTS in place that’s set up for remote logging. Congratulations!

From here, we recommend that you review our other articles related to HAProxy. One article in particular can be found here, as the next step usually involves setting up TLS testing with a Swarm Gateway farm in place:

Configuring haproxy SSL offloading with a Self Signed Certificate on Content Gateway

Additional Notes

Sometimes, it’s necessary to make adjustments for default resource limits for HAProxy. This usually involves increasing the open file limit for the HAProxy process. Since we’re fully integrated with systemd in the above example, we can take advantage of that to create a resource limits file for the HAProxy process.

First, you will need to create a service directory for the HAProxy systemd service:

Now, we want to create a file named ‘limits.conf’ in that directory, then edit it to increase the file limit (you can use text editor of choice, here we use ‘vi’):

Place the following setting scope and associated setting in that file:

Once that is done, you will need to direct systemd to reload daemon information, then restart haproxy:

If that change has taken hold, you should see an increase from default of the number of open files allowed for HAProxy (a before and after example is shown below):