Does load balancer F5 support CasC (Configuration as Code)?

Question

Using CasC with F5 would allow for versioned and optionally dynamic network endpoint configuration, saving time and reducing risks.

Does this tool support this? Are Single Configuration Files (SCF, F5 term) the vehicle to do that?

Answer 1

Yes, F5's do support Configuration as Code. Historically, F5 has made an appliance to manage Configuration as Code called "Enterprise Manager" which pragmatically managed client endpoint F5s (LTMs, etc) using the iControl XML API.

They rather quickly discovered this management appliance was terrible and added a more robust REST API to the client appliances for managing devices (LTMs, etc.; also branded as iControl) which is much easier to use and more flexible and then began building a replacement for the Enterprise Manager branded BIG-IQ.

The point being, you can manage that same API using this REST interface. See their tutorial on DevCentral. Usually, you can find the exact REST syntax and calls on the DevCentral site on a per-version basis like this one for TMOS 12.1.0.

Generally speaking, it is NOT recommended that you use an SCF (Single Configuration File) pretty much ever for a couple of reasons. First, it lacks any supporting files, such as certificates and keys for your SSL profiles or scripted (so-called "external" health monitors), etc. Secondly, it plays poorly if you use partitioning, as partitions are spread over several files in a foldered structure. These don't consolidate well into an SCF file. You would actually be better off to write TMOS scripts. One of the reasons F5 switched from the bigpipe command to the TMOS shell is that it could be scripted where bigpipe could not be easily scripted. But again, the REST API is preferred. SCFs are really a legacy of version 9 of TMOS and haven't aged well and work poorly in version 12. A significant reason for this is due to the changes in the HA peering between V10 and V11 when they changed to a clustered architecture. It really wreaked havoc on the usability of the SCFs.

Puppet actually has a module for managing F5s if you use this configuration management tool and salt has a runner for it - both using the REST API if you use either of these configuration management tools.

Answer 2

James, you are correct in that BIG-IQ replaced Enterprise Manager. However, like Enterprise Manager, BIG-IQ is for 'device/feature' management. For integrating via REST APIs directly, or to 3rd party automation tools/tool-chains, you should look at F5 iWorkflow (programmable/extensible API gateway).

The team behind iWorkflow are focussed on 'services templates' and 'service catalogs'. These being great ways to rapidly create 'declarative interfaces' that you can hit with single REST calls, versus calling hundreds of 'imperative interfaces' (individual REST end-points) to perform the same task.

Moving to a declarative model will save you from MANY headaches in the future, and will better support automation, and integration with CI/CD pipe-lines. The LAST thing you want is to move all the nuances of your infrastructure into the automation pipe-line itself!! Abstraction through declarative interface will protect you from that pit of despair.

With REST+declarative interfaces, you have a much simpler Infrastructure as Code model in that you are only maintaining JSON blobs for the service templates, and not monolithic configuration files. Double-WIN!

Take a look at calling iApps (F5 services templates) from the REST API. Here's a free on-line training course:

http://f5-automation-labs.readthedocs.io/en/latest/

Chase = Correct! REST all the way!