VMware vCloud Automation Center (vCAC) can be easily integrated with 3rd party solutions to cater for various use cases. I was recently involved in a project where there was a need to integrate with F5.
There are maybe 3 integration points where F5 touches vCAC:
1. As part of IaaS – so as part of the user requesting a machine from the vCAC Self Service Portal or disposing it, then that machine is dynamically added to an F5 Pool or removed from it.
2. As part of a day two activity- the machine is already deployed and running but maybe now we need to add or remove it from an F5 Pool.
3. “F5 as a Service” or “LB as a Service”- so now we don’t talk about machines anymore. We now want to offer in the Self-Service Portal different items like for example “Create Pool”, “Create Virtual Server” etc…
Use-Case 1 will be achieved and covered by the IaaS capabilities of vCAC.
Use-Cases 2 and 3 will be achieved using the new Advanced Service Designer (ASD) which is a new capability in vCAC 6.*
This 3-part blog series will cover all 3 integration points staring with the first one: IaaS.
BIG-IP LTM 11.* and above.
vCAC 6.0 or 6.0.1
vCO 5.1 and above (I am using the embedded vCO 5.5.1 which is part of vCAC 6.0.1)
F5 vCO plugin version 2. I got it from here: https://devcentral.f5.com/d/f5-management-plug-in-for-vmware-vcenter-orchestrator-v200?download=true but best thing is to send an email email@example.com and they will supply you with the latest version, free of charge as far as I know.
1. Install the F5 vCO plugin as explain here: https://devcentral.f5.com/articles/automating-application-delivery-with-big-ip-and-vmware-vcenter-orchestrator#.Uy2G-q1_sRE
2. Next you need to run the Attach LTM workflow in vCO. Most likely the Attach LTM workflow will appear to work OK, but when you try to run other workflows afterwards it says your device is disconnected. This is caused by an SSL certificate issue. Ensure your self-signed cert on the BIG-IP matches the name with which you are connecting to it, and also import that certificate into vCO using the vCO configuration user interface (https://your_vco_ip:8283) and restart vCO server.
When you run the “Attach LTM” workflow make sure the “use Rest API” is set to “no” as it is still in Early-Access mode so better use Soap (see below):
3. Build a vCO workflow to add VM to an F5 Pool. My workflow looks like this:
First scriptable task step will be to get the IP from the VM vCAC is dynamically provisioning. Next scriptable task step will be to find if the Pool name we have set as custom property at the blueprint level in vCAC exist or if we need to create it. If it exists then we just add the VM IP to the existing F5 Pool. If not then we create the Pool, then generate a random IP (192.168.110.*) to assign to the F5 Virtual Server (this customer didn’t have an IPAM solution but if they did then this is where I would call out to an IPAM system like Infoblox for example to get an IP), create the F5 Virtual Server, add an icmp monitor to the pool and then eventually add the VM IP as a pool member.
Input parameters will look like this:
Note: the two input parameters memberPort and PoolName will come from vCAC IaaS blueprint so needs to be defined at the blueprint level. the 3rd parameter vCAC:Entity will come dynamically from vCAC IaaS.
4. Build a vCO workflow to delete the Virtual Server, remove all VM’s from an F5 Pool and then delete the pool. My workflow looks like this:
First scriptable task step will be to get all Pools from LTM then find the specific Pool we are after. Next scriptable task step will delete the Virtual Server, then remove all IP members from the Pool and finally delete the Pool itself.
You can alternatively write a workflow that doesn’t delete the Virtual Server or the Pool but just remove the specific member from the Pool. In fact I will show that use case in part 2 of this blog series.
5. Now we need to associate these 2 workflows with a vCAC external Stub. More information about vCAC external stubs and how they can be associated with vCO workflows and triggered at runtime can be found here in Chris Alleaume’s excellent blog: http://www.virtualnebula.com/blog/2014/1/24/running-vco-workflows-from-vcac-during-the-provisioning-of-a-virtual-machine
Make sure you associate your “add member to pool…” workflow with MachineProvisioned stub and your “remove member from pool…” workflow with MachineDisposing stub as described in Chris’s blog.
Make sure that these 3 properties are populated with values in your blueprint:
ExternalWFStubs.MachineProvisioned.memberPort >> for example ’80’
ExternalWFStubs.MachineProvisioned.PoolName >> for example ‘Web’
That’s it you are ready to rock!
You can request machines from the vCAC Self Service Portal and it will be automatically added to the F5 Pool of your choice and removed from it when the machine is disposed.
Here is how it will look like in LTM if the process has been successful (Pool is created and monitored and includes 1 member):
For your convenience the two vCO workflows mentioned above can be downloaded from here: