Forum Discussion

BaltoStar_12467's avatar
Oct 27, 2015

BIP-IP : source-control solutions

F5 BIG-IP Virtual Edition v11.4.1 (Build 635.0) LTM on ESXi

 

I'm interested in source-control solutions for iRules and other BIG-IP elements.

 

One mechanism is to version the element file-names ("irule-01","irule-02") and store older versions within the device itself - which offers a definite advantage during typically anxious prod-deployments of clear & fast rollbacks via the admin UI.

 

However, this system has a serious drawback once implemented in external source-control as it becomes "versioning on top of versioning" as each file-name-version is further versioned ( via commit shas ) throughout the dev-test cycle. As not all elements will necessarily be revised ( and re-versioned ) for a given dev-qa-deploy cycle, you end up with a mix of file-name-versions - rather than a simple release tag.

 

However, including only a single version within the device, and maintaining all source-control externally also has a drawback in that previous release versions must always be located via the source-control tool ( GitHub UI or git command line ) and this adds complexity and potential confusion & error during a troubleshooting session following a prod rollout that exhibits site errors.

 

Another technique it to version bigip.conf in source-control and effect all changes via direct edits. The device is only updated via import/load/save of bigip.conf

 

A more advanced variation would be to maintain individual elements under source-control and build a generator to create bigip.conf ( and other config-files ) from the total collection of elements.

 

The disadvantages of this system are clear : many changes are far easier to implement via the admin UI, config-file structure & syntax errors only become apparent on device update, and restriction of changes to wholesale replacement of the config-file is ultimately just a policy without any mechanism of absolute enforcement ( unless restrict device access to an automated update script or app - unrealistic given the typically hands-on nature of prod troubleshooting and remediation ).

 

1 Reply

  • This is an old thread, but in case someone else stumbles across it looking for source control solutions... The only "good" method of source control that I've found is to migrate VIP resources to AS3 or FAST code. If you pair your Visual Studio Code app to an Azure Repository, you gain source control, allowing you to add comments whenever you make a change to the code, and quickly view and compare current code to old code, and revert to old code. The downside is that all changes have to be done through code since that would be the new source of truth, and the GUI would just be for viewing/troubleshooting config.

     

    I'm assuming this would work the same with a Git Repository as well if you don't have an Azure Repo.