F5 BIG-IP Collection v2

Currently in Preview

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.

This collection is not currently published to Galaxy or Automation Hub while feedback is collected through issues on GitHub. When a 1.0.0 release is ready, the collection will be released into Galaxy and Automation Hub.

Review the following Example Repo for creating an identical application with both the v1 and v2 Collection. It will help identify the primary differences in use cases.

Note

You can leverage both this collection (f5_bigip) and the previous 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) | |icr|
  • 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.

Many years later, the automation landscape has 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:

  • Consider the Ansible v1.x (f5networks.f5_modules) collection in sustaining mode: We will continue to support this collection and provide bug fixes. Enhancements to existing modules will be considered on a case by case basis. We will not consider new modules for our collection v1.x (it would be exceptional if it happens). We do not have plans to deprecate this collection soon. We want to give time to our customers to review our new collection, make sure it fits their needs, and carefully work on a transition strategy. If any constraints are identified, we recommend you open a GitHub issue so we can support your migration.
  • Deliver a new collection that focuses on our declarative APIs. This new collection will be called f5_bigip and is considered to be our v2 collection, because it is a major change to our existing collection)
    • Any requests for new modules that are already covered by AS3, DO, TS is 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).