BIG-IP Next Automation: AS3 Basics

I need a little Mr. Miyagi right now to grab my face and intently look me in the eye and give me a "Concentrate! Focus power!" For those of you youngins' who don't know who that is, he's the OG Karate Kid mentor. Anyway, I have a thousand things I want to say about AS3 but in this article, I'll attempt to cut this down to a narrow BIG-IP Next-specific context to get you started.

It helps that last December I did a five-part streaming series on AS3 in the BIG-IP classic context. If you haven't seen that, you have my blessing to stop right now, take some time to digest AS3 conceptually and practice against workloads and configurations in BIG-IP classic that you know and understand, before returning here to embrace all the newness of BIG-IP Next.

AS3 is FOUNDATIONAL in BIG-IP Next

In classic BIG-IP, you could edit the bigip.conf file directly, use tmsh commands, or iControlREST commands to imperatively create/modify/delete BIG-IP objects. With the exception of system configuration and shared configuration objects, this is not the case with BIG-IP Next. All application configuration is AS3 at its lowest state level.

Foundations matter!

This doesn't mean you have to work primarily in AS3 configuration. If you utilize the migration utility in Central Manager, it will generate the AS3 necessary to get your apps up and running. Another option is to use the built-in http FAST template (we'll cover FAST in later articles) to build out an application from scratch in the GUI. But if you use features outside the purview of that template, or you need to edit your migration output, you'll need to work in the AS3 configuration declaration, even if just a little bit.

Apples to Apples

It's a fun card game, no? My family takes it to snarky absurd levels of sarcasm, to the point that when we play with "outsiders" we get lots of blank looks and stares as we're all rolling on the floor laughing. Oh well, to each his own. But we're here to talk about AS3, right? Well, in BIG-IP Next, there is a compatibility API for AS3, such that you can take a declaration from BIG-IP classic and as long as the features within that declaration are supported, it should "just work" via the Central Manager API. That's pretty cool, right? Let's start with a basic application declaration from the recent video posted by Mark_Dittmer exploring the API differences between classic and Next.

{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "generated-for-testing",
    "Tenant_1": {
        "class": "Tenant",
        "App_1": {
            "class": "Application",
            "Service_1": {
                "class": "Service_HTTP",
                "virtualAddresses": [
                    "10.0.0.1"
                ],
                "virtualPort": 80,
                "pool": "Pool_1"
            },
            "Pool_1": {
                "class": "Pool",
                "members": [
                    {
                        "servicePort": 80,
                        "serverAddresses": [
                            "10.1.0.1",
                            "10.1.0.2"
                        ]
                    }
                ]
            }
        }
    }
}

A simple VIP with a pool with two pool members. A toy config to be sure, but it is useful here to show the format (JSON) of an AS3 declaration and some of the schema as well. With the compatibility API, this same declaration can be posted to a classic BIG-IP like this:

POST https://<BIG-IP IP Address>/mgmt/shared/appsvcs/declare

Or a BIG-IP Next instance like this:

POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/declare?target_address=<BIG-IP Next instance IP Address>

For those already embracing AS3, this compatibility API in BIG-IP Next should make the transition easier.

AS3 Workflow in BIG-IP Next

With BIG-IP classic, you had to install the AS3 package (technically an iControl LX, or sometimes referenced as an iApps v2 package) onto each BIG-IP system you wanted to use the AS3 declarative configuration model on. Each BIG-IP was an island, and the configuration management of the overall system of BIG-IPs was reliant on an external system for source of truth. With BIG-IP Next, the Central Manager API has native AS3 support so there are no packages to install to prepare the environment. Also, Central Manager is the centralized AS3 interface for all Next instances. This has several benefits:

A singular and centralized source of truth for your configuration management
No external package management requirements
Tremendous improvement in API performance management since most of the heavy lifting is offloaded from the instances and onto Central Manager and the control-plane functionality that remains on the instance is intentionally designed for API-first operations

The general application deployment workflow introduced exclusively for Next, which I'll reference as the documents API, is twofold:

Create an application service

First, you create the application service on Central Manager. You can use the same JSON declaration from the section above here, only the API endpoint is different:

POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/documents

A successful transaction will result in an application service document on Central Manager.

A couple notes on this at time of writing:

Documents created through the API are not validated against the journeys migration tool that is available for use in the Central Manager GUI.
Documents are not schema validated at the attribute level of classes, so whereas a class used in classic might be supported in Next, some of the attributes might not be.

This means that whereas the document creation process can appear successful, the deployment will fail if classes and/or class attributes supported in classic BIG-IP are present in the AS3 declarations when an attempt to apply to an instance occurs.

Deploy the application service

Assuming, however, all your AS3 work is accurate to the Next-supported schema, you post the specified document by ID to the target BIG-IP Next instance, here as a JSON payload versus a query parameter on the compatibility API shown earlier.

POST https://<Central Manager IP Address>/api/v1/spaces/default/appsvcs/documents/<Document ID>/deployments

{
    "target": "<BIG-IP Next Instance IP Address>"
}

At this point, your service should be available to receive traffic on the instance it was deployed on.

Next Up...

Now that we have the theory in place, join me next time where we'll take a look at working with a couple application services through both approaches.