We’re back today with more ‘insider info’ on upcoming changes to Crunchy Postgres via Automation (CPA). If you missed any of the prior posts, you can catch up here. We recently committed support for HAProxy 3.0.x into development and changed our default HAProxy configuration around to accommodate the version bump.

One of the first things we changed is how we build our configuration. Recent versions of HAProxy have the ability to use a configuration directory instead of (or in addition to) a configuration file, and now that we build and ship our own binaries across all our supported OSes, I’ve been eager to switch to a configuration directory. With the upcoming release of CPA 2.3.0, we will be dropping multiple configuration file ‘stubs’ into /etc/haproxy/cfg.d. We’ll be creating a file for our global directives, a file for our defaults, a file for our stats configuration (unless disabled by the user), and one file for each CPA cluster that this HAProxy is a part of. This makes it significantly easier for us to configure and reconfigure HAProxy as we stand up/tear down CPA clusters and I’m personally very happy to be able to simplify the code instead of piecing a full configuration together ‘by hand’.

Next up, we decided to finally fix our logging configuration. For the longest time, we’ve simply used the default log and called it ‘good enough’. As part of moving to HAProxy 3.0.x, we took the time to reevaluate our logging and we’re now using tcplog for our front and back ends while using httplog for the statistics listener (if enabled). We’ve additionally configured the log to be stderr format iso local7 to give us a more structured log format that is emitted for journalctl to capture. Finally, we set dontlognull and logasap to ensure that log entries appear as quickly as possible and are actually useful.

While we were tweaking things, we made some small security tweaks: we enabled rejection of privileged ports, and we configured the default SSL ciphers to use PROFILE=SYSTEM which means any hardening you’ve done to the system SSL (disallowing ciphers, etc) will be automatically inherited by HAProxy.

Given the multi-core nature of today’s servers, we have decided to configure HAProxys nbthread and cpu-map automatically based on the number of cores in the machine. We’re a little conservative with our settings since we can’t easily know if the HAProxy node is dedicated, but users should still see noticeable improvements in HAProxy performance.

And finally, we enabled ‘stick tables’ based on destination for our backends. This should help route connections faster under load.

In all, a bunch of minor QoL improvements that should add up to a decent impact on our HAProxy experience. There’s certainly a lot more that could be done, especially around TLS/SSL, but I’m hopeful this will give us a good enough base until we can replace HAProxy in the mid-term.

:wq