Grabbing Your iRules by the TesTcl
Ok, I’ll admit, it’s hard to pass an opportunity to joke about a name such as TesTcl. Much like it’s namesake, it’s a serious issue. My current employer makes use of F5 load balancers. They’re not my first employer to do so but probably the first I’ve seen really make extensive use of iRules.
iRules are Tcl scripts that run during the various stages of a request. In our case, it’s mostly HTTP(S) web requests but I have seen them duplicate binary flows or provide detailed TLS statistics to Elastic Stack for later analysis. While TCL isn’t Turing Complete, it does provide a lot of power to manipulate content, headers and even just redirect traffic to different resource pools.
That’s a lot of clevel logic to rely on with debugging mainly consisting of PRINT (well, log local0.) commands and praying you got your string map command right for re-writing a request to a back-end REST service. It’s also very easy to make a mistake adding an extra branch to existing logic. This was the root cause of a service outage where a collision in naming happened. It wasn’t obvious but the new service had /bob/ at the start of the path and the existing service occasionally had /bob/ further into the path (not part of the matching rule).
Tcl is a programming language and we’re writing code. Therefore, it stands to reason that testing said code before going into production should be possible. And it is. TesTcl is a mocking and testing library for F5 Big-IP iRules. Out of the box, it supports a lot of the common iRule manipulations you might do – branching to different pools, re-writing headers, etc.
This tool has been very useful in testing some more complex iRules we have since deployed. Taking a Test Driven Development (TDD) approach of writing the tests first and code (iRules) second is much quicker than the guess, print and repeat cycle we’d previously used. Having a list of passing tests doesn’t hinder getting change approval either.
There are however a few caveats. Firstly, the JTcl project it relies on is a little faffy to get going. It’s a Java implementation of a Tcl intepreter. The usual fun with JREs, classpaths and batch files (no, really) awaits.
Secondly, there’s a few bits that aren’t mocked out from the F5 API. That’s not Earth shattering and easily fixed. You can use the on SOMETHING “” stanza to mock those out as a no-op or pre-set value. This combined with a few behavioural differences between JTcl and Tcl running on the F5 means tests somestime pass but fail to operate on the F5. Though you will find the vast majority of your scripts will work correctly once passing tests.
We’re in a much better place unit testing iRules with TesTcl. Just a shame I don’t have the time to help the project out. It would be really nice to get JUnit or XUnit output that could be integrated into a CI/CD pipeline. Said integration was something that took a bit of time to setup with PyTest for a different work project but makes a world of difference tracking regressions.
