Posted inFedora

Deploying HAProxy Layer 7 on Fedora Server: From Lab to Real-World Production

Fedora tutorial - IT technology blog
Fedora tutorial - IT technology blog

Why I Choose HAProxy on Fedora

After using Fedora as my primary environment for over two years, I’ve found it to be an OS that balances stability and cutting-edge features perfectly. Unlike CentOS or Ubuntu LTS, which often get stuck with older versions, Fedora Server always offers HAProxy 2.8+ or 3.0 in its official repositories. You just need to run dnf install to get the latest features without messing around with third-party repos.

The standout feature of HAProxy at Layer 7 (Application Layer) is its ability to deeply inspect HTTP Headers, Cookies, and URLs. This allows for extremely flexible traffic routing instead of just blind load distribution at the TCP layer. In this post, I’ll dive straight into practical configurations and how to handle those “signature” SELinux errors common in the RedHat family.

Quick Start: Running HAProxy in 5 Minutes

If you need to quickly set up a load balancing cluster for testing, follow these three rapid steps.

1. Installing HAProxy

sudo dnf install haproxy -y

2. Minimal Configuration

Open the file /etc/haproxy/haproxy.cfg. Delete the old content and paste this snippet (replace with your corresponding backend IPs):

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

3. Activating the Service

sudo systemctl enable --now haproxy

In theory, you’re done. However, if you access it and see a 503 error or a timeout, don’t panic. 90% of the time, Firewall and SELinux are blocking the way. We’ll handle that right below.

Smart Routing with ACLs

Suppose your system has both an API and a Frontend running separately. You want requests to /api to go to the logic processing cluster, while everything else returns a static page. ACLs (Access Control Lists) were born for this.

frontend http_in
    bind *:80
    
    # Identify API requests
    acl is_api path_beg /api
    
    # Smart routing
    use_backend api_cluster if is_api
    default_backend static_web

backend api_cluster
    balance leastconn
    server api01 10.0.0.5:8080 check maxconn 500
    server api02 10.0.0.6:8080 check maxconn 500

backend static_web
    balance roundrobin
    server web01 10.0.0.10:80 check
    server web02 10.0.0.11:80 check

I prefer using leastconn for the API cluster. This algorithm pushes requests to the server with the fewest active connections. It’s significantly more effective than roundrobin when data processing tasks have uneven response times.

Handling SELinux and Firewalld: Don’t Disable, Configure Correctly!

Many people choose to run setenforce 0 for a quick fix. This is a fatal mistake for security. Fedora defaults to blocking HAProxy from creating outbound connections, so you must grant it permission.

1. Unblocking SELinux

Run the following command to allow HAProxy to connect to backend servers over the network:

sudo setsebool -P httpd_can_network_connect 1

The -P flag ensures this rule persists even after a server reboot.

2. Opening Firewalld

Don’t forget to open the service ports. Otherwise, clients won’t be able to reach the Load Balancer:

sudo firewall-cmd --permanent --add-service={http,https}
sudo firewall-cmd --reload

Health Checks: Ensuring High Availability

A good Load Balancer must know how to remove faulty servers immediately. Instead of just a basic TCP port check, I usually use an HTTP check to ensure the application is actually responding.

backend app_backend
    option httpchk GET /health
    http-check expect status 200
    server app01 192.168.1.20:8080 check inter 2s rise 3 fall 2
    server app02 192.168.1.21:8080 check inter 2s rise 3 fall 2

With the above configuration, HAProxy will check the /health endpoint every 2 seconds. If the server returns a 500 error or timeouts twice in a row (fall 2), it will be removed from the service list. Only when it returns 200 for 3 consecutive times (rise 3) will it be allowed back into rotation.

Administration Page (HAProxy Stats)

For visual monitoring, you should enable the built-in dashboard. It clearly displays which servers are “alive,” traffic volume, and real-time errors:

listen stats
    bind *:9000
    stats enable
    stats uri /monitor
    stats auth admin:SuperSecurePassword2024
    stats refresh 5s

Access http://Your-IP:9000/monitor to see the results. Remember to open port 9000 on Firewalld.

Pro-tips from the Field

After several rounds of “fighting fires” in production environments, I’ve gathered some important notes:

  • Check Syntax: Always run haproxy -c -f /etc/haproxy/haproxy.cfg before restarting. A single extra comma can cause system downtime.
  • Separate Logs: By default, HAProxy logs are mixed into journalctl, making them hard to read. You should configure Rsyslog to push logs to a separate file at /var/log/haproxy.log.
  • Kernel Optimization: For systems handling over 10,000 concurrent connections, increase the file descriptor limit by adding fs.file-max = 65535 to /etc/sysctl.conf.
  • SSL Termination: If using HAProxy for HTTPS decryption, prioritize newer Fedora versions to leverage OpenSSL 3.0, which significantly speeds up handshakes.

Deploying HAProxy on Fedora isn’t hard; the challenge lies in understanding how it interacts with the OS’s security systems. If you encounter strange errors, use the command ausearch -m avc -ts recent to see what SELinux is blocking. Good luck building a stable system!

Share:
Tags: