You may be thinking, what's the hype around this 8.6 release?
Well, we have a whole host of new enhancements to our WebUI, which is going to make ease of management of the load balancer, far simpler. The changes are mainly based around ACL rules, Health Checking, and our WAF.
What’s been added with the new HAProxy ACL rules?
If you are an existing user of the Loadbalancer.org appliance, you may think:
“ACL rules have been in the product for years, what's changed?”
While that is true, we admit it wasn’t the best it could have been, with certain configurations requiring some regex, or even a manual configuration. All this worked fine but it wasn’t the smoothest way to make your configuration changes.
So we are pleased to announce a long-awaited overhaul of the ACL rules, based on the following goals:
KISS ('keep it simple stupid') principles i.e.
- Similar interface to the previous version of ACL rules
- Make the commands easy to use and understand
- Allow the easy re-ordering of rules
- Try to make the validation as helpful as possible
- Never cause downtime, auto-test the commands with clear errors
...while at the same time enabling the replacement of complex manual configurations i.e.
- Powerful FreeType rules to allow any combination of HAProxy commands
- Allow combination rules by using the concept of 'flags'
- Allow header rules to be linked to ACL rules via multiple flags
- Allow the FreeText definitions of backends, servers, and pools.
Why did we make these changes?
Fundamentally because we are trying to make the product more flexible, yet easy to use - and most importantly get you closer to zero downtime. As we all know, ACL rules give you flexibility and control over your load balancer traffic and how it is processed in the backend server. It is made up of a set of rules that either allow, deny and even redirect traffic. They can help improve efficiency and security within your network.
Let’s look at a simple example
The new rules allow you to set a flag based upon a rule - so in this example, I’m checking the source subnet to see if it matches 192.168.64.0/22, and (if it does), it sets a flag: ‘internal’.
We can then configure any rules based on this flag. So in this example, I’ve just redirected traffic to an external or internal web server. Headers can also take advantage of flags, being able to set headers and change header values if the flag criteria are met.
ACL rules demo
I’ve already done a quick tour of our WebUI to show you these awesome features in this video, but I’ll dive deeper here into the ACL rules for the purposes of this blog:
How do ACL traffic rules work?
ACL traffic rules allow you to better manage your internal and external traffic. ACLs work on setting conditions, and once that condition is met, an action is triggered. These conditions could be URL paths, headers, IP’s, ports, and many more. I could write a huge blog showing examples of the HAProxy ACL rules, but our friends at HAProxy have already done so here.
Traffic is filtered depending on the order of the rules. It starts from the top of the list until a rule is triggered. Once a rule is triggered that packet is sent. The rules will not continue to run after a rule has been hit unless the rule sets a flag. Therefore it’s important to set up any rule that allows traffic to “Use Server” at the bottom of the list for the added level of security.
What can you do with ACL traffic rules?
ACL rules are so customizable, you can do almost anything with your traffic. We often end up using ACLs to convert existing F5 iRules for migrations. If you have a specific use case in mind, contact us and we will be happy to help.
Not everyone will need the new ACL rules...
...and, no doubt, not everyone will like them either, but we think we’ve chosen a reasonable balance of simplicity and power. Please let us know if you agree or disagree, and make suggestions for future improvements!
Moving on to Health Checks...
Health checks are also a powerful tool to monitor the health state of each backend and ensure traffic is routed to the healthy servers. So, it made total sense that we updated our interface to make these tasks so much easier and take away the pain in accessing the CLI and editing the health checks there.
What’s up with health checks?
So, focusing on the ease of use aspect, we have also improved how you can write and add custom health checks to each of your virtual services. Giving the power to edit health checks directly in the WebUI, as opposed to having access to the command line interface to edit, or scp your health checks across.
We’ve simplified the initial list to just 4 useful checks. This does not mean we have removed the existing scripts that are in our product, they have just become templates under Cluster Configuration > Health check scripts. You can choose any one of these templates to clone and make your own scripts. However. if you know what you’re doing, just use the blank template and let your imagination run wild.
What else is in this 8.6 version?
Our third major update was related to the WAF. We've also introduced lots of small improvements, but also a couple of structural changes that will allow seamless integration with central management for our partners. The rest of the details are in our roadmap.
Making our WAF less painful with CRS 3
Our resident expert, Andrew Howe, has put an enormous amount of effort into making the new WAF improvements transparent and painless. So, everything that used to work will still work, and anything implemented with the new rule set will have a lot fewer false positives.
CRS 3 lowers the barrier to entry for configuring a basic level of WAF protection. This makes securing a web service with a WAF easier than ever before. Read this blog from our own expert Andrew Howe to understand the key concepts of CRS 3 and how they make your life easier
Finally, please let us know if there's anything you’d like us to change in the product. Because we are always listening and learning from you.