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

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...

 

 

@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).