F5 Load Balancer Deployment Scripts
=====================================
Paul Graydon & Matt Taniguchi

These scripts were born out of a need to manage a pair of F5 load balancers
in something hopefully approaching a practical approach amongst a team.

We were migrating away from an Apache/mod_proxy based, fairly organically
grown setup, and the transition gave us a chance to clean things up a little.

The ultimate aim is to make it easy to deploy changes with some automated tests,
enforce certain standards and require all deployed changes to be checked in to
the VCS (in our case we use CVS).

F5's BIG-IP load balancers are incredibly flexible courtesy of their iRules.
iRules are essentially a TK based scripts, and F5 have provided a lot of
commands, settings and configuration options in them.
We could use one script per vhost but in our testing we found that sticking
to a monolithic script resulted in much better performance.

However we have over 80 vhosts, with over 100 different applications behind
them, with their own routing quirks. That results in our main iRules script
weighing in at around 1000 lines.

==Using the scripts==

There are three main things these scripts manage:
- Pools  (the back-end servers)
- Monitors (the health checks)
- iRules (the glue!)

The flat files for all three exist under the pools, monitors, and irules
subdirectories respectively.

=Pools and Monitors=

In these scripts monitors and pools are explicitly tied together by naming
convention. They must share the same name, with just _pool and _health being
different. e.g. in the included examples, foo-monkey_health and foo-monkey_pool.
In our case we use the first half of the name to refer to the subdomain (foo)
and the second half to refer to the webapp (monkey) so that it's easy to find
them for any changes.  For now you can only have one health check associated
with an application.

=iRules=

We split the irules subdirectory into multiple subdirectories.  The name of
the subdirectory is used to define the name of the generated iRule.
In the included example, there are two directories, http and ssl, which generate
http_rule and ssl_rule respectively.  The iRule deployment process defines a
header and a footer which include our common aspects, before starting and
closing a switch statement based on a glob of the HTTP::host parameter.
We split each possible vhost (HTTP::host) into its own file, but you could
choose to have multiple vhosts in a single file.
To aid in troubleshooting, each file is tested individually by way of a
temporary rule, and the script will abort if it hits a syntax error.
That does mean every file in the subdirectory must be capable of standing
on it's own as part of a case statement.


=Configuration=
You will need to adjust the f5.cfg file.  In there you specify things like
authentication credentials for the F5, along with various defaults for pools
and monitors.

It is important that the hostname be set to the IP address of your a hot spare
F5 Load balancer.  Whenever we've run these scripts against the live balancer
we've notice that it's had a detrimental impact on monitoring and performance.
Deploying against the spare, and then syncing to the main avoids the problem.


==Things to note==
Some of these are covered above, but by way of tl;dr:

- Point these scripts at your hot spare, not your live LB.
- Pool and monitor files must share the same name, with only the suffix changed
- Each iRule file must stand alone as part of a case statement, or it will
fail the basic syntax checking the scripts do.
- Only HTTP, HTTPS and TCP_HALF_OPEN checks have been implemented so far.
- If you're not using CVS, drop out the entire try/except block in the
if __name__ == "__main__" sections of the 3 deploy scripts.