Let’s look at how to automatically add members to your
BIG-IP pool by using the Service Discovery iApp. Whenever you deploy a BIG-IP
Virtual Edition by using one of the templates on the F5 Github site, this iApp is installed
on the BIG-IP.
The idea behind this iApp is you assign a tag to a virtual
machine in the cloud and then BIG-IP automatically discovers it and adds it to
the pool. By tagging instances in AWS and Azure, and configuring the iApp, the
pool is updated based on an interval you specify. This is especially helpful if
you auto-scale your application servers because they are then automatically
added and removed.
Today, we’ll look how to do this in Azure but you can also do
this in AWS.
First, we’re going to add a tag to the application sever in
Azure. You can assign the tag to either the virtual machine or to the NIC. For auto-scaling
you’d tag the scale set. This can we’ll simply add it to the virtual machine.
When you click through the virtual machine, on the left you’ll
get the ‘Tags’ option.
This entry can be any name/value pair you want and for this
we’ll use ‘mytag’ and ‘addme.’
And we’ll click Save.
For this exercise, we have two application servers in the
resource group and already added the tags for that one. So at this point, we’re
ready to get into the BIG-IP and configure the iApp.
Once in, go to Application
Services>Applications>Create.
Next, we give it a name and choose f5_service_discovery from the list.
Scroll down the same page and fill out the open fields. Under
Cloud Provider, we select Azure.
Depending on your provider, there are additional questions. Add the Azure
resource group and the Subscription ID. The next 3 fields (for the Azure
selection) are security related: Tenant ID, Client ID and Service Principal
Secret. Rather than using your own credentials to create and modify resources
in Azure, you can create an Azure Active Directory application and assign
permissions to that. Details are included on the Github ReadMe or the Azure
documentation about service Principal.
Under the Pool area,
is where you enter the name/value pair that we used for the tags in Azure. We leave
the rest default. In this instance, you may notice the update interval at 60
seconds. By default, 60 seconds is the interval that BIG-IP will query Azure to
see if there is a resource with the tags you specified. Under Application Health, select ‘http’ as
the health monitor. Click Finished.
When complete, we can see we got a pool with two active
members in it.
If you take the tags off one of the instances, it’ll leave
the pool. Of note however, there must be two members in the pool before you
remove tags from an instance. If you remove the tags from all the application
servers, the pool will not be updated. BIG-IP must see at least one set of tags
to update the pool because it doesn’t want to leave you with an empty pool.
Here’s the before and after of removing a tag.
One final note. This example configuration has the BIG-IP in
one resource group and the application servers in another resource group but
they are all on the same Vnet. If you have separate networks in Azure, you’ll
need to create a peering so they can communicate. Similarly, in AWS, you need
to make sure the networking is set up so the BIG-IP can see the application
servers. But, once the initial set up is working, there’s no manual
intervention required.
You can use the Service Discovery method to add and remove application
servers all day long without having to manually update the BIG-IP. Again, and
as always, thanks to our Technical Communications team for the great material
and watch the video demo
here.
ps
Related:
- Onboarding F5 in Cloud Part 2 - Service Discovery
- Deploy the Service Discovery iApp on a BigIP Cluster across two Availability Zones
No comments:
Post a Comment