Currently we use F5 Big-IP LTMs (IP load balancers) in our environment for load balancing. We have an existing process for making changes to LTM configs and pushing them out. I'm trying to figure out the best way to accommodate a new need of our environment.
This is our current method for making changes to our LTM configs (to create new VIPs or add or remove nodes for example) :
- Connect to a server where we maintain copies of our LTM configs
- check out a copy of the config from RCS version control
- vi the config file and make the change on this server
- diff the new config against the previous in version control
- paste this diff into a change control ticket in our ticketing system
- have a fellow network engineer buddy check the diff and sign off on it
- scp the new config file out to our secondary LTM server
- run a "bigpipe verify load /tmp/bigip.conf" to verify the new conf
- copy the staged bigip.conf over the live one in /config/bigip.conf
- run a "bigpipe load"
- tech logs into the web interface to confirm it looks good
- synchronize from our seconary LTM to our primary LTM by running "bigpipe config sync" on our secondary
We want to grant other teams the "Operator" permission to enable and disable nodes in a VIP pool. Doing so writes the changed node state into the config file.
How can we allow other teams to use iControl or the web interface to administratively enable and disable nodes, while maintaining our ability to version control and review config changes before deploying them while not overwriting the node states that have been set on the live production LTMs?
I would use bigpipe export and import.
then when you are ready to deploy do an export of the current state and then a final sdiff against your modified source controlled scf and keep the pool setting differences for the current state export. Then import the output of the sdiff.
Another option is to use something like chef to make changes. You can source control your recipes.