Last updated on: 2024-04-01 03:24:20.

F5 declarative collection overview

This collection focuses on managing F5 BIG-IP/BIG-IQ through declarative APIs such as AS3, DO, TS, and CFE. The collection includes key imperative modules as well for managing resources and operational tasks outside of declarative workflows. Examples include actions such as saving config, backing up config, uploading security policies, uploading crts/keys, gathering info, and so on.

Review the following Example Repo for creating an identical application with both collections (f5_modules and f5_bigip). It will help identify the primary differences in use cases.

Note

You can leverage both this collection (f5_bigip) and the imperative collection (f5_modules) at the same time.

Offering Background

In 2015, F5 released its first modules to automate tasks related to our BIG-IP Platform (f5networks > f5_modules: https://galaxy.ansible.com/f5networks/f5_modules). This collection includes more than 170 modules today. It is called f5_modules.

This collection:

  • Leverages our IMPERATIVE REST API (i.e. the implementation is procedural - you need to define all the steps needed to reach a specific state) | iControl Rest Docs
  • This Collection is fully supported by F5 (https://support.f5.com/csp/article/K80012344). Customers can either open issues through Github or via F5 Services.

Years later, the automation landscape changed. IT has aligned to business needs and is requested to deliver services more quickly. The infrastructure team is expected to work closely with other teams to empower them and decrease time to market. This has raised new challenges they need to address:

  • How do you tie infrastructure configuration to your application lifecycle?
  • How to build a self-service catalog for infrastructure services like Load Balancing (LB/ADC), Web Application Firewall (WAF), DNS, DDOS, and so on.

To help our customers in their digital transformation, we also need to address new challenges:

  • Even if we have many modules today, we are still far from covering all the “knobs” available on a BIG-IP. We have more than 2500 API endpoints available today! Building so many modules is not scalable and will make it difficult/confusing for our customers.
  • How do we make it easier for non automation experts to leverage our platform for automated application services? Imperative modules lead to more complex orchestration workflows that are difficult to maintain, troubleshoot, upgrade if you are not an F5 expert.
  • We are not talking to NetOps only anymore, which requires us to lower the barrier of adoption to our technology. We cannot expect other personas (architects, app developers) to have the same amount of F5 BIG-IP knowledge as NetOps.
  • Ensure our customers will invest in an API that will remain available across new BIG-IP technologies (new BIG-IP platforms, TMOS refactoring, and so on).

To address those challenges and support our customers, the F5 BIG-IP team has been working on the following:

To enforce those changes to Ansible, F5 has decided to do the following:

  • Deliver a new collection that focuses on our declarative APIs. This new collection is called f5_bigip and is considered to be our latest collection
    • Any requests for new modules that are already covered by AS3, DO, TS are unlikely to be considered.
    • If our declarative API miss a feature/use case, customers should ask for those products to support their use cases via a GitHub issue or an F5 Service Request.
    • For anything that cannot be delivered via our declarative API, a module will be considered (use case example: create/fetch an archive).