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?
Sol:--
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.
No comments:
Post a Comment