Skip to main content

Declarative Intent and Orchestration with F5 AS3

By July 15, 2021No Comments

Declarative Intent and Orchestration with F5 AS3

Not already deploying your applications from code or in a declarative manner? F5 AS3 and Configuration as Code are here to change that!

F5 BIG-IP has long been the industry leader in secure traffic management and application delivery. With the continued adoption of Infrastructure as Code (IaC) for network automation teams and now Configuration as Code (CaC) for DevOps and application teams, it only seems appropriate that the folks at F5 take an "application-first" approach and introduce Application Services 3 Extension.

This API framework allows us to "declare" how the application should be deployed and configured. No longer are we using ad-hoc commands and inconsistent processes to apply change to our environments, we are now integrating our workflows and deployments to use Source Code Management (SCM) as the source of truth.

Getting Started with Application Services 3 Extension (AS3)

During a recent event, Arctiq explored some technical use cases using declarative Configuration as Code to deploy applications and highlight some great real-world use cases. AS3 enhances application development pipelines and workflows to incorporate networking and traffic control configuration as part of the deployment by creating Virtual IP’s, Pools and Node members on the BIG-IP all declared from code in a Git repository.

Note: In upcoming releases of AS3, F5 will be incorporating support for Application Security Manager (ASM) and Advanced Firewall Manager (AFM). The current version only supports declarative definition for Local Traffic Manager ([LTM]

A few highlights about AS3:

  • Javascript iControl LX Worker
  • Runs on Nodejs, exposes REST endpoint
  • RPM installed on BIG-IP
  • On-prem and Cloud
  • Works anywhere BIG-IP is deployed
  • Exposes declarative endpoint (JSON service definitions)

Lab Environment:

We used a common deployment topology for the lab environment, Production and DR. In the Ansible automation, the inventory had groups and hosts for both environments, Ansible Tower used a survey to populate variables that selected which hosts the automation tasks would be run against.

Use Case #1: AS3 Declarative Application Setup

This use case demonstrated how to use the Ansible module bigip_iapplx_package to automate the installation of AS3 and the Git Webhook server on the F5 BIG-IP. These two tools are used together to ensure the latest application declarations from the Git repository are applied to the BIG-IP. The third part of the workflow used the API to setup a webhook within the project repository described in the workflow below:


The Git workflow is shown below and is broken into these steps:

  • Code commit or more preferably a merge to the "Master" Git branch via Pull Request
  • Webhook triggers commit message to the BIG-IP Git Webhook server
  • BIG-IP Git Webhook server fetches the application declaration from the GitHub repository

<img src="" position="center" size="XXL" alt="git" %}

Here is a code snip from the AS3 and Git Webhook standup:

AS3 Installation

{% highlight yaml %}

  • name: Enable AS3 on F5 file: path: /var/config/rest/iapps/enable state: touch modification_time: "preserve" access_time: "preserve" delegate_to: f5_as3

  • name: Install AS3 bigip_iapplx_package: package: "{{playbook_dir}}/roles/f5-as3/files/f5-appsvcs-3.8.1-1.noarch.rpm" server: f5_as3 validate_certs: no server_port: "443" {% endhighlight %}

Git Webhook Server Install and Setup

The Git Webhook server requires a minimal amount of configuration after the install. There are two requirements:

  • URL of the Git API Endpoint
  • Git Access Token (PAT)

Below is an Ansible task to copy and install the GitHub Webhook Server RPM on the BIG-IP:

{% highlight yaml %}

  • name: Install GitHub WebHook Server bigip_iapplx_package: package: "/roles/f5-webhook/files/GithubWebhookServer-0.3.0-0005.noarch.rpm" server: f5_as3 validate_certs: no server_port: "443" {% endhighlight %}

Note: These parameters must be passed to the Webhook server via API.

{% highlight yaml %}

  • name: Configure Git Webhook Server uri: url: https://f5_as3/mgmt/shared/webhook/github-settings method: POST validate_certs: no user: username password: password body: "lookup(‘template’,’git-settings.j2′)" force_basic_auth: yes status_code: 200 return_content: yes body_format: json register: gitwebhook_settings {% endhighlight %}

GitHub Webhook Setup

GitHub uses a Personal Access Token (PAT) for authentication, this PAT was generated with minimal rights to the Git repository to ensure the Webhook server running on the BIG-IP had only the privileges it required to consume declarative code.

{% highlight yaml %}

  • block:
    • name: Create Webhook uri: url: "" method: POST headers: Content-Type: application/json Authorization: "token lookup(‘env’,’GITHUB_PAT’)" body: "lookup(‘template’,’create_webhook_prod.j2′)" status_code: 201 body_format: json register: github_create_webhook {% endhighlight %}

After the installation and configuration of these packages on the BIG-IP, a Package Management LX menu is now visible in the GUI with the details:

<img src="" position="center" size="XXL" alt="as3" %}

Use Case #2: Configuration as Code (CaC) with Branch Protection and Rollback

Use case 2 is a real-world example of Configuration as Code and how Git provides approval control (release management), branch protection, auditing and collaboration. One key advantage to using this Git-integrated declarative model is the ability to rollback if erroneous or unintended code did pass the approval process and was deployed to the BIG-IP. It is as simple as reverting back to the previous commit, or another preferred commit to meet the desired state of the application.

The branch protection model is critical to protect the integrity of the production code. An application developer must create a new branch in which all changes are contained and committed. A Pull Request facilities the approval workflow to have their new branch merged with "Master" and deployed to the BIG-IP upon merge.

Using the GitHub team permissions structure, there are two different types of users in this demo:

  1. Approvers
  2. Contributors

Approvers are able to merge Pull Requests and revert back to previous commits. Contributors are able to create branches, commit code additions and changes as well as open Pull Requests to merge their code to deploy/redeploy their application.

//merge to master branch

A Pull Request to merge a new branch was raised, in the example, a new web server node was added to existing pool members.

<img src="" position="center" size="XXL" alt="merge" %}


The web server added to the pool in the first example was removed using the revert capability within GitHub. This reverted the repository back to the previous commit, triggering the webhook to initiate a pull of the code to the BIG-IP. The webserver was removed from the BIG-IP as the configuration from code did no longer specify it should be present.

<img src="" position="center" size="XXL" alt="revert" %}

This Configuration as Code workflow also allows an approver to deny any updates and close the Pull Request if the code does not look correct or is not applicable.

To take it a step further, the GitHub repository was integrated with a Slack App to send notifications to the channel for commits, pull requests and merges to the project repository. A great way to keep the app team updated and notified of new release requests and admins to perform required approvals.

Use Case #3: DR Restore App Services from Code

In many cases, DR means running parallel systems that mimic Production workloads. This requires replicating application code and critical file data in real-time and most importantly, determining when and how to failover to a secondary environment. Shifting to a "as code" model with supporting automation workflows can evolve that traditional way of performing DR to an agile approach where systems, configurations and environments can be brought online "as needed" in the event of a failure or to allow maintenance to be performed.

Combined with global DNS traffic management, this can be a very seamless process and provide vast cost savings, following the now-common consumption model (pay-as-you-go/grow).

In this use case, we simulated a physical link failure to the Production site BIG-IP. A workflow was triggered to bring the DR site and the application online which included:

  • Install AS3 and Git Webhook server on the BIG-IP in DR
  • Clone the Production Git repository
  • Create new GitHub repository for DR using the API
  • Copy over the application declarations to the DR repository
  • Create a Webhook to trigger a call to the DR BIG-IP on commit/merge to the Master branch
  • Commit the locally cloned DR repository to GitHub

These steps above were performed using an Ansible Tower workflow.

<img src="" position="center" size="XXL" alt="workflow" %}

Upon completion of the automated workflow in Tower, the Beer Giphy application was available through the F5 BIP-IP at the DR site.

// presentation recap

In case you missed the Arctiq, F5 and RedHat event, live recordings of all the content can be found on our YouTube channel:

Part 1:

AS3 & Git Webhook Server

Part 2:

AS3 and F5 Container Connector with OpenShift