Service Discovery

This section contains declarations that discover pool members automatically or dynamically. This includes declarations that automatically discover members in Cloud deployments, as well as declarations that use an FQDN pool to enable pool member addresses to dynamically follow DNS changes.

Use the index under Current Page on the left to locate specific examples.

1: Using Service Discovery to automatically populate a pool

This example uses the service discovery feature to populate a pool based on tagged resources in AWS. For information on this feature, see the Service Discovery page. In this example, the pool contains two static members on port 443, and then members in our us-west-1 region in AWS that are tagged with foo and bar.

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_sd_01.
  • A virtual server named serviceMain.
  • A pool named web_pool monitored by the default http health monitor. The pool members are autodiscovered from AWS.
{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "urn:uuid:33045210-3ab8-4636-9b2a-c98d22ab425d",
    "controls": {
      "class": "Controls",
      "trace": true,
      "logLevel": "debug"
    },
    "label": "AWS Service Discovery",
    "remark": "Simple HTTP application with a pool using AWS service discovery",
    "Sample_sd_01": {
      "class": "Tenant",
      "verifiers": {
        
      },
      "A1": {
        "class": "Application",
        "template": "http",
        "serviceMain": {
          "class": "Service_HTTP",
          "virtualAddresses": [
            "192.0.2.14"
          ],
          "pool": "web_pool"
        },
        "web_pool": {
          "class": "Pool",
          "monitors": [
            "http"
          ],
          "members": [
            {
              "servicePort": 80,
              "addressDiscovery": "aws",
              "updateInterval": 1,
              "tagKey": "foo",
              "tagValue": "bar",
              "addressRealm": "private",
              "region": "us-west-1"
            },
            {
              "enable": true,
              "servicePort": 443,
              "serverAddresses": [
                "192.0.2.60",
                "192.0.2.61"
              ]
            }
          ]
        }
      }
    }
  }  

Back to top


2: Using remote Service Discovery to automatically populate a pool with BIG-IP VE anywhere

This example uses the remote service discovery feature introduced in v3.4.0 to populate a pool based on tagged resources in AWS, Azure, and Google. For information on this feature, see the Service Discovery page. Remote service discovery allows your BIG-IP VE to be located anywhere, not necessarily in a specific cloud or region. In this example, the declaration runs on the local BIG-IP system, see the next example for using a declaration on a remote BIG-IP. For this feature to work properly, you must provide credentials for your cloud provider as shown in the following example.

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_sd_02.
  • A virtual server named serviceMain.
  • A pool named web_pool monitored by the default http health monitor. The pool members are autodiscovered from AWS, Azure, and Google clouds, each on a different port.

Note: This example does not include actual credentials for any of the clouds, or IDs for Azure. You must supply these items from your cloud provider.

{
    "class": "ADC",
    "schemaVersion": "3.4.0",
    "id": "urn:uuid:33045210-3ab8-4636-9b2a-c98d22ab425d",
    "label": "AWS Azure GCP Service Discovery",
    "remark": "HTTP application with a pool using local nodes and AWS, GCP, and Azure service discovery",
    "Sample_sd_02": {
      "class": "Tenant",
      "A1": {
        "class": "Application",
        "template": "http",
        "serviceMain": {
          "class": "Service_HTTP",
          "virtualAddresses": [
            "192.0.192.3"
          ],
          "pool": "web_pool"
        },
        "web_pool": {
          "class": "Pool",
          "monitors": [
            "http"
          ],
          "members": [
            {
              "servicePort": 8080,
              "addressDiscovery": "azure",
              "updateInterval": 10,
              "tagKey": "foo",
              "tagValue": "bar",
              "addressRealm": "private",
              "resourceGroup": "test_group",
              "subscriptionId": "azure subscription ID",
              "directoryId": "azure directory ID",
              "applicationId": "your azure application ID",
              "apiAccessKey": "your api access key",
              "credentialUpdate": false
            },
            {
              "servicePort": 8081,
              "addressDiscovery": "gce",
              "updateInterval": 10,
              "tagKey": "foo",
              "tagValue": "bar",
              "addressRealm": "private",
              "region": "us-west1",
              "encodedCredentials": "base 64 encoded credentials",
              "credentialUpdate": false
            },
            {
              "servicePort": 8082,
              "addressDiscovery": "aws",
              "updateInterval": 10,
              "tagKey": "foo",
              "tagValue": "bar",
              "addressRealm": "private",
              "region": "us-west-1",
              "accessKeyId": "your key id",
              "secretAccessKey": "your secret access key>",
              "credentialUpdate": false
            },
            {
              "enable": true,
              "servicePort": 80,
              "serverAddresses": [
                "10.128.0.7"
              ]
            }
          ]
        }
      }
    }
  }
    

Back to top

3: Using remote Service Discovery and sending the declaration to a remote BIG-IP

This example uses the remote service discovery feature to populate a pool based on tagged resources in AWS, Azure, and Google, but in this declaration we are sending the declaration to a remote BIG-IP system. You must use the targetHost, targetUserName, and targetPassphrase parameters to set the information for the target BIG-IP device. For information on service discovery, see the Service Discovery page.

For this feature to work properly, you must provide credentials for your cloud provider as shown in the following example.

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_sd_03.
  • A virtual server named serviceMain.
  • A pool named web_pool monitored by the default http health monitor. The pool members are autodiscovered from AWS.

Note: This example does not include actual AWS credentials, you must supply these items.

{
    "class": "AS3",
    "targetHost": "192.0.2.212",
    "targetUsername": "admin",
    "targetPassphrase": "admin",
    "declaration": {
        "class": "ADC",
        "schemaVersion": "3.1.0",
        "id": "TEST_Service_HTTP",
        "Sample_sd_03": {
            "class": "Tenant",
            "Generic_Http": {
                "class": "Application",
                "template": "generic",
                "vghSimple": {
                    "class": "Service_HTTP",
                    "virtualAddresses": [
                    "10.1.88.1"
                    ],
                    "pool": "web_pool"
                },
                "web_pool": {
                    "class": "Pool",
                    "monitors": [
                        "http"
                    ],
                    "members": [
                        {
                            "servicePort": 8082,
                            "addressDiscovery": "aws",
                            "updateInterval": 10,
                            "tagKey": "foo",
                            "tagValue": "bar",
                            "addressRealm": "private",
                            "region": "us-west-2",
                            "accessKeyId": "your-access-key",
                            "secretAccessKey": "your-secret-key",
                            "credentialUpdate": false
                        },
                        {
                            "enable": true,
                            "servicePort": 80,
                            "serverAddresses": [
                                "10.128.0.7"
                            ]
                        }
                    ]
                }
            }
        }
    }
  }

Back to top

4: Using an FQDN pool to identify pool members

This example uses an FQDN pool on the BIG-IP VE, which allows the pool member addresses to dynamically follow DNS changes. For complete information on FQDN pools, see https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-13-1-0/22.html. You must have DNS configured on your BIG-IP system before FQDN pools will function properly. See the BIG-IP documentation for details.

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_sd_04.
  • A virtual server named serviceMain.
  • A pool named fqdn_pool. The pool member addresses are discovered using DNS.
{
    "class": "ADC",
    "schemaVersion": "3.4.0",
    "id": "demo",
    "label": "FQDN pool example",
    "remark": "Example of using an FQDN pool",
    "Sample_sd_04": {
        "class": "Tenant",
        "fqdn_app": {
            "class": "Application",
            "template": "http",
            "serviceMain": {
                "class": "Service_HTTP",
                "virtualAddresses": [
                    "192.0.2.241"
                ],
                
                "pool": "fqdn_pool",
                "virtualPort": 80,
                "persistenceMethods": [
                    "cookie"
                ],
                "profileHTTP": "basic",
                "layer4": "tcp",
                "profileTCP": "normal",
                "snat": "auto"
            },
            "fqdn_pool": {
                "class": "Pool",
                "members": [
                    {
                        "servicePort": 80,
                        "addressDiscovery": "fqdn",
                        "autoPopulate": true,
                        "hostname": "demo.example.com"
                    }
                ]
            }
        }
    }
}
          

Back to top

5: Service Discovery using HashiCorp Consul

This example uses Consul (specifically HashiCorp Consul) for service discovery. For more information HashiCorp Consul, see https://www.consul.io/. This declaration includes an optional Base 64 encoded bearer token required to make requests to the Consul API with the ACL system enabled (stored in the declaration in an encrypted format).

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_sd_05.
  • A virtual server named serviceMain.
  • A pool named web_pool monitored by the default http health monitor. The pool members are autodiscovered via the Consul API.
{
    "class": "ADC",
    "schemaVersion": "3.7.0",
    "id": "urn:uuid:33045210-3ab8-4636-9b2a-c98d22ab425d",
    "label": "Consul Service Discovery",
    "Sample_sd_05": {
      "class": "Tenant",
      "A1": {
        "class": "Application",
        "template": "http",
        "serviceMain": {
          "class": "Service_HTTP",
          "virtualAddresses": [
            "198.0.2.3"
          ],
          "pool": "web_pool"
        },
        "web_pool": {
          "class": "Pool",
          "monitors": [
            "http"
          ],
          "members": [
            {
              "servicePort": 80,
              "addressDiscovery": "consul",
              "updateInterval": 10,
              "uri": "http://demo.exmample.com:8500/v1/catalog/nodes",
              "encodedToken": "base 64 encoded token",
              "credentialUpdate": false
            },
            {
              "enable": true,
              "servicePort": 80,
              "serverAddresses": [
                "192.0.2.7"
              ]
            }
          ]
        }
      }
    }
}
  

Back to top

6: Event-Driven Service Discovery for use in the Docker Container

This example uses a event-driven service discovery, introduced in AS3 3.9.0. With event-driven service discovery, you POST a declaration with the addressDiscovery property set to event. This creates a new endpoint which you can use to add nodes that does not require an AS3 declaration, so it can be more efficient than using PATCH or POST to add nodes. This also enables the ability to configure a service (such as AWS Lambda) to use the event endpoint any time it detects instance changes.

When you use the event value for addressDiscovery, the system creates the new endpoint with the following syntax: https://<host>/mgmt/shared/appsvcs-discovery/task/~<tenant name>~<application name>~<pool name>/nodes.

For example, in the following declaration, assuming 192.0.2.14 is our BIG-IP, the endpoint that is created is: https://192.0.2.14/mgmt/shared/appsvcs-discovery/task/~Sample_event_sd~My_app~My_pool/nodes

Once the endpoint is created, you can use it to add nodes to the BIG-IP pool.

First we show the initial declaration to POST to the BIG-IP system.

{
    "class": "ADC",
    "schemaVersion": "3.9.0",
    "id": "Pool",
    "Sample_event_sd": {
        "class": "Tenant",
        "My_app": {
            "class": "Application",
            "template": "generic",
            "My_pool": {
                "class": "Pool",
                "members": [
                    {
                        "servicePort": 8080,
                        "addressDiscovery": "static",
                        "serverAddresses": [
                            "192.0.2.2"
                        ]
                    },
                    {
                        "servicePort": 8080,
                        "addressDiscovery": "event"
                    }
                ]
            }
        }
    }
}

This declaration creates the following objects on the BIG-IP:

  • Partition (tenant) named Sample_event_sd.
  • A pool named My_pool that is a part of the My_app application. The pool currently contains one member, 192.0.2.2 on port 8080.

Once the declaration has been sent to the BIG-IP, we send the following code to the BIG-IP endpoint (https://192.0.2.14/mgmt/shared/appsvcs-discovery/task/~Sample_event_sd~My_app~My_pool/nodes). Both id and ip are required.

[
    {
        "id": "newNode1",
        "ip": "192.0.2.3"
    },
    {
        "id": "NewNode2",
        "ip": "192.0.2.4"
    }
]

This creates two new named nodes in My_pool, newNode1 and newNode2 at the IP addresses specified.

Note

The list of nodes for this event-driven task are replaced with the list you post, so you should always include all nodes with each request.

Back to top