Onboarding F5 in Cloud Part 2 - Service Discovery

Onboarding F5 in Cloud Part 1 - Startup Scripts

For Part 2, we'll talk about another critical component of the auto scaled or dynamic environment ... service discovery. As instances or pool members are now more ephemeral, it becomes absolutely required to automate. The task is really quite simple, you need to use the platform's database to populate the pool. 

The first built-in approach we had of this was the fqdn node. 

tmsh create ltm node my_fqdn_node fqdn { name www.example.com }

The database we were queriying was DNS. The pool definition could now simply encompass a dns name.  

The natural evolution of this is query other databases like the virtual infrastructure's controller.   Tagging or labeling things in these environments is the defacto way of finding / auditing your objects as well as general best practices. As things become more ephemeral, network addresses themselves lose value (to a end user at least). So instead of explicitily configuring IP addresses in the pool, you just describe what to look for.   

Now, we're happy to introduce the Service Discovery iApp which makes the pool defintion simply a tag (or label) to query.

https://github.com/F5Networks/f5-cloud-iapps/blob/master/f5-service-discovery/f5.service_discovery.tmpl

We've begun bundling this in our official templates

• https://github.com/F5Networks/f5-aws-cloudformation
• https://github.com/F5Networks/f5-azure-arm-templates

so if you use a template to deploy BIG-IPs, the iApp will be there when you login. From the previous article, there are also startup script examples of installing it 

• AWS: https://github.com/f5devcentral/f5-terraform/blob/master/modules/providers/aws/infrastructure/proxy/standalone/1nic/util/user_data.tpl
• Azure: https://github.com/f5devcentral/f5-terraform/blob/master/modules/providers/azure/infrastructure/proxy/standalone/1nic/util/user_data.tpl

Otherwise, you can download the iApp template above and install manually as you would any iApp.  

As we discussed in previous articles, in order for BIG-IP to interact with the infrastrcture, the BIG-IP needs to have certain permissions. In AWS, it requires you to apply an IAM role (example) to the BIG-IP instance so the BIG-IP has permissions to query your infrastructure. It also has a special "assume role" feature that a tenant with different authentication domain can provide you with an "ARN" so you can query their infrastructure.  In Azure, it requires you to create a service account and configure API keys in the iApp.  

Using this iApp, you just tag an instance or nic you want to add, and the IP (first IP of the first nic) will be automatically be added to the pool. If you want to track an AWS autoscale group or Azure scale set, simply tag the members in that group something unique (configure tags in the launch config).

Lets take a look at this iApp in action.

The other approach, is spin up two seperate autoscale groups and manually toggle the tag searched for in the iApp.

You can automate/reconfigure the iApp via REST Call like below.

ex. create file called app-payload.json with content below:

 
(virt1)user1@desktop:~ $ cat iapp-payload.json
{
    "name": "www_sd",
    "partition": "Common",
    "subPath": "www_sd.app",
    "execute-action": "definition",
    "template": "/Common/f5.service_discovery",
    "variables": [
        {
            "name": "cloud__aws_use_role",
            "value": "no"
        },
        {
            "name": "cloud__cloud_provider",
            "value": "aws"
        },
        {
            "name": "cloud__aws_region",
            "value": "us-west-2"
        },
        {
            "name": "pool__interval",
            "value": "10"
        },
        {
            "name": "pool__member_conn_limit",
            "value": "0"
        },
        {
            "name": "pool__member_port",
            "value": "80"
        },
        {
            "name": "pool__pool_to_use",
            "value": "/Common/www.example.com"
        },
        {
            "name": "pool__public_private",
            "value": "private"
        },
        {
            "name": "pool__tag_key",
            "value": "Name"
        },
        {
            "name": "pool__tag_value",
            "value": "www-instance-green"  <== change this value for tag, ex. from blue to green, v0.0.1 to v0.0.2, etc.
        }
    ]
}

Then run:

(virt1)user1@desktop:~ $curl -sk -u ${bigip_username}:${bigip_password} -H "Content-type: application/json" -X PATCH --d @iapp-payload.json https://${bigip_host}:${bigip_port}/mgmt/tm/sys/application/service/~Common~www_sd.app~www_sd?ver=13.0.0 | python -m json.tool

For more general information on updating iApps, see

https://devcentral.f5.com/s/articles/building-application-delviery-services-from-templates-using-the-rest-api-for-people-like-me

ex. Updating via Ansible Module:

https://github.com/F5Networks/f5-ansible/blob/devel/library/bigip_iapp_service.py

There are also other vaild approaches to service discovery.  For instance, in some of our container ecosystem integrations, we do this with off box solution called our Container Connector.

• https://github.com/F5Networks/k8s-bigip-ctlr
• https://github.com/F5Networks/marathon-bigip-ctlr

It uses a more dynamic pub/sub approach where the container connector (running seperately in a container itself) subscribes to the controller for events and then when controller publishes updates to container connector, the container connector then remotely updates the BIG-IP configuration.

In either approach, manually updating pool member lists will be a thing of the past.  

Happy Discovering!