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]https://www.f5.com/products/big-ip-services/local-traffic-manager)).
A few highlights about AS3:
- 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)
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 GitHub.com 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
Here is a code snip from the AS3 and Git Webhook standup:
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:
Note: These parameters must be passed to the Webhook server via API.
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.
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:
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:
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.
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.
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.
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: