Forum Discussion

sriramgd_111845's avatar
sriramgd_111845
Icon for Nimbostratus rankNimbostratus
May 03, 2011

F5 and source control - deploy from SCM or get from device?

I got some good advice on how to get our changing F5 configuration into source control:

 

http://devcentral-sea.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/1178703/showtab/groupforums/Default.aspx

 

 

Based on this I implemented a job which goes out and gets the F5 configuration every n minutes, compares it with what is in our source control and if it has changed, checks it in, with the diff as the check in comment. This way we have a history of changes done to the F5 via the web or command line.

 

 

In a review the question was raised that we should be deploying configuration changes from the SCM instead of pulling the changes.

 

 

However I don't see an easy way out for this. Here are two options which came mind:

 

1. Lock the web and command line interface out to all users and have them change the configuration file in SCM and then have a command to overwrite the configuration file on the F5 through the SCM build process. The problem with this is most users may not be familiar with the configuration file, may make mistakes with it etc.

 

2. Build a UI which does this and integrates with our SCM. This would take time to build.

 

 

We do have an F5 in our test environment which we could use as a 'staging' server - the problem is that it is used for various QA purposes and we cant overwrite the configuration file for staging and testing before deploying to production.

 

 

Based on this I still think that just getting the configuration and checking it in if it has changed is the best way to maintain history (and allow for rollbacks) for the F5 configuration.

 

 

Any advice on this?

 

 

Any examples of how anyone maintain the F5 configuration(s) in source control?

 

 

Thanks.

 

 

config
design

2 Replies

Sort By
  • Steven_Wagner_1's avatar
    Steven_Wagner_1
    Icon for Nimbostratus rankNimbostratus
    Jun 02, 2011
    Hi there,

     

     

    I was just wondering about how other people were managing their configs, in production or otherwise. Depending on the SCM (or combination of SCMs?) you use, I bet you could come up with something manageable without introducing something really wild like a Jenkins (nee Hudson) server acting as gatekeeper for configuration deployments. The big problem I see with a push config method is that backing out of changes quickly could be a bit cumbersome, especially if you've got an audience that's never used that particular flavor of SCM before. I think your safest bet is to test these processes on a development or QA F5 first and get people used to the idea of using that process. Prove it in QA and people will have confidence in it when you roll it out to production.

     

     

    Coming more from a server background, I was intrigued to find that F5s seem to run "more or less" Linux. Has anyone on this forum heard of anyone having any success applying a server-oriented config management system or deployment solution to an F5 device or series of devices? For example, I was integrating PyControl v2 into a Fabric command that would remove a target app server from its application pool and bleed connections off before deploying a new version of the app to it and re-adding it again. Then I got restricted bpsh access to that set of load balancers and found that I could just issue bigip commands directly.

     

     

    So that's neat, but Fabric's primarily an orchestration tool. It'd be really neat to roll this up into a Chef or Cfengine or Puppet type of solution, where you're already building a model of what your application looks like on N servers and what their relationship is between each other. All three of those tools have robust templating engines built into them, so it seems that it should be possible to at least generate and track config files.

     

     

    The trick is that you'd have to really trust the coding you did on that Chef/Cfengine/Puppet integration, because the integration would require you to manage IP/Server/Pool/Member/Node objects EXCLUSIVELY through your config management interface or risk having unmanaged changes reverted on the next run! Hope THAT config is tracked in SCM and tested in QA first...

     

     

  • Michael_Yates's avatar
    Michael_Yates
    Icon for Nimbostratus rankNimbostratus
    Jun 02, 2011
    @sriramgd,

     

     

    I understand your goal, but wouldn’t recommend a push from SVN to your BIG-IP. Doing so would require both a UNIX diff (http://www.computerhope.com/unix/udiff.htm) and merge (http://www.computerhope.com/unix/merge.htm) to get the changes into the BIG-IP Configuration file (or a total replacement from Source Control), but would also require a b load to be implemented, which is disruptive to all traffic on the BIG-IP while it re-reads the configuration file.

     

     

    I would recommend using a merge file (http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086464/BIG-IP-and-Merge-File-Configuration-Changes.aspx) which can exist externally from the bigip.conf, can be verified for syntax and reference context prior to implementation, and implemented without any service interruption to other traffic.

     

     

    Configuration and Source Control.

     

    I currently have my BIG-IP’s configured to do an hourly push of their configuration files into source control, but I believe that I will be utilizing iControl to change my methodology to a pull soon. So that is good advice from the other post.

     

     

    You could also utilize trac (http://trac.edgewall.org/) to view the differences between files stored in your source control (so if something was working, but now it isn’t you can view the specific changes that have taken place).