Forum Discussion
Syafiq_89483
Cirrus
CirrusiRules Change Management
I have several irules running on a single box. Each irules consist of nearly 500 line of code.
The development process of this irules was so rapidly changing, considering that our customer needs change the logic of irules until become stable and acceptable.
The problem is, sometimes we don't know which part have been changed and which part haven't. Can we get the information when a user/admin/engineer do a change to our irules, and which part of the irules they have change? Maybe it's like implementation of subversion in big-ip.
any idea would highly appreciated.
thanks!
I personally do not think this has to be handled on the F5 itself. If you consider each iRule as a configuration file, you can manage each one like you would manage a system configuration file. We started using Git to manage our iRules, right now it's a manual process, but the F5 has APIs which will be used to implement automated processes. We started by adding headers to each file, so that people know not to modify the iRules directly on the box. Here's what we put at the beginning of each iRule:
Managed by Git (git@your.git.machine/gitpath/conf.git) Version: $Id$ $Format:Git ID: (%h) %ci/%cn$And then you can add this to your .attributes file:
Manage the Identity substitution *.txt ident *_stash ident Substitute information on export *.txt export-subst *_stash export-substWe then use git archive to export the files, which will replace the variables with some information. I realize this solution is not perfect, we are in the early rounds.
The biggest challenge becomes the human factor, no iRules should be modified directly on the F5. BTW, the $Id$ variable can be used to verify that nobody touched the file.
Regards, Didier
Didier_Fort_226Altostratus
I personally do not think this has to be handled on the F5 itself. If you consider each iRule as a configuration file, you can manage each one like you would manage a system configuration file. We started using Git to manage our iRules, right now it's a manual process, but the F5 has APIs which will be used to implement automated processes. We started by adding headers to each file, so that people know not to modify the iRules directly on the box. Here's what we put at the beginning of each iRule:
Managed by Git (git@your.git.machine/gitpath/conf.git) Version: $Id$ $Format:Git ID: (%h) %ci/%cn$And then you can add this to your .attributes file:
Manage the Identity substitution *.txt ident *_stash ident Substitute information on export *.txt export-subst *_stash export-substWe then use git archive to export the files, which will replace the variables with some information. I realize this solution is not perfect, we are in the early rounds.
The biggest challenge becomes the human factor, no iRules should be modified directly on the F5. BTW, the $Id$ variable can be used to verify that nobody touched the file.
Regards, Didier
- JRahm
Admin
interesting concept. If you tied this into an iApp to manage all the iRules, then the rules themselves couldn't be changed directly. 
HamishCirrocumulus
I like it... Do you automate it as well so when a new version is checked into the git repository, the LTM's all get updated? H- Didier_Fort_226OK, I need to look at iApps. No, it's not automated yet, we are in the early stages. BTW, I personally think that adding $Id$ and other variables is a temporary step. Once the iRule are automatically pushed either via iApp or other means, these variables won't be necessary.
Syafiq_89483We started using Git to manage our iRules, right now it's a manual process, but the F5 has APIs which will be used to implement automated processes. We started by adding headers to each file, so that people know not to modify the iRules directly on the box.
seems interesting didier!
thanks for the idea anyway.
iApps + tmsh::expand_macro (added in 11.4 - needs some documentation here on devcentral) provide a nice way to make sure iRules are not modified in place. The strictness of iApps protects the iRules from user error (note that strictness can be turned off but not without some intentional button pressing) and the templating can provide an escape-free 'string map'-free iRule editing environment plus variable substitution, complex macro conditionals, and fantastic debugging.
I would be interested in building an iRule/iApp/iControl/iCall development VM someday around the idea of simplifying this.
Personally I have solved this problem many times in the past primarily with svn/vim/.vimrc/ssh/scp and tmsh load sys config merge file plus a script that I put on the dev F5 BIG-IP box called rerun-iapp. It's nice because you can run it with ssh and a key and with the '-d' flag it puts the lines of scriptd.out out to your terminal. Plus you can create several ASO instances of the template and it will rerun the template for all ASOs - allowing you to do potentially lots of testing quite quickly
- I have the rerun-iapp script and will post it to the code share world. Tried to do so here and it was not pretty
