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