Automate BIG-IP in customer environments using Ansible

There are a lot of technical resources on how Ansible can be used to automte the F5 BIG-IP. A consolidated list of links to help you brush up on Ansible as well as help you understand the Ansible BIG-IP solution

I am going to dive directly into how customers are using ansible to automate their infrastructure today. If you are considering using Ansible or have already gone through a POC maybe a few of these use cases will resonate with you and you might see use of them in your environment.

Use Case: Rolling application deployments

Problem

Consider a web application whose traffic is being load balanced by the BIG-IP. When the web servers running this application need to be updated with a new software package, an organization would consider going in for a rolling deployment where rather than updating all servers or tiers simultaneously. This means, the organization installs the updated software package on one server or subset of servers at a time.  The organization would need to bring down one server at a time to have minimal traffic disruption.

Solution

This is a repeatitive and time consuming task for an organization considering there are newer updates coming out every so often. Ansible’s F5 modules can be used to automate operations like disabling a node (pool member), performing an update on that node and then bring that node back into service. This workflow is applicable for every node member of the pool sequentially resulting in zero down time for the application

Modules

• bigip_ltm_facts
• bigip_node

Sample

- name: Update software on Pool Member - "{{node_name}}"
  hosts: bigip
  gather_facts: false
  vars:
    pool_name: "{{pool_name}}"
    node_name: "{{node_name}}"

  tasks:
  - name: Query BIG-IP facts for Pool Status - "{{pool_name}}"
    bigip_facts:
       validate_certs: False
       server: "{{ bigip_ip_address }}"
       user: "{{ bigip_username}}"
        bigip_password: "{{ bigip_password}}"
       include: "pool"
    delegate_to: localhost
    register: bigip_facts

  - name: Assert that Pool - "{{pool_name}}" is available before disabling node
    assert:
     that:
      - "'AVAILABILITY_STATUS_GREEN' in bigip_facts['ansible_facts']['pool']['/Common/{{iapp_name}}/{{pool_name}}']['object_status']['availability_status']|string"
     msg: "Pool is NOT available DONOT want to disable any more nodes..Check your BIG-IP"

  - name: Disable Node - "{{node_name}}"
    bigip_node:
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username}}"
       bigip_password: "{{ bigip_password}}"
      partition: "Common"
      name: "{{node_name}}"
      state: "present"
      session_state: "disabled"
      monitor_state: "disabled"
    delegate_to: localhost

  - name: Get Node facts - "{{node_name}}"
    bigip_facts:
       validate_certs: False
       server: "{{ bigip_ip_address }}"
       user: "{{ bigip_username}}"
        bigip_password: "{{ bigip_password}}"
       include: "node"
    delegate_to: localhost
    register: bigip_facts

  - name: Assert that node - "{{node_name}}" did get disabled
    assert:
     that:
        - "'AVAILABILITY_STATUS_RED' in bigip_facts['ansible_facts']['node']['/Common/{{node_name}}']['object_status']['availability_status']|string"
     msg: "Pool member did NOT get DISABLED"

- name: Perform software update on node - "{{node_name}}"
  hosts: "{{node_name}}"
  gather_facts: false
  vars:
    pool_name: "{{pool_name}}"
    node_name: "{{node_name}}"

  tasks:

  - name: "Update 'curl' package"
    apt: name=curl state=present

- name: Enable Node
  hosts: bigip
  gather_facts: false
  vars:
    pool_name: "{{pool_name}}"
    node_name: "{{node_name}}"

  tasks:

  - name: Enable Node - "{{node_name}}"
    bigip_node:
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username}}"
       bigip_password: "{{ bigip_password}}"
      partition: "Common"
      name: "{{node_name}}"
      state: "present"
      session_state: "enabled"
      monitor_state: "enabled"
    delegate_to: localhost

Use Case: Deploying consistent policies across different environment using F5 iApps

Problem

Consider an organization has many different environments (development/QA/Production). Each environment is a replica of each other and has around 100 BIG-IP’s in each environment. When a new application is added to one environment it needs to be added to other environments in a fast, safe and secure manner. There is also a need to make sure the virtual server bought online adheres to all the traffic rules and security policies.

Solution

To ensure that the virtual server is deployed correctly and efficiently, the entire application can be deployed on the BIG-IP using the iApps module. iApps also has the power to reference ASM policies hence helping to consistently deploy an application with the appropriate security policies

Modules

• bigip_iapp_template
• bigip_iapp_service

Sample

- hosts: localhost
  tasks:

  - name: Get iApp from Github
    get_url:
      url: "{{ Git URL from where to download the iApp }}"
      dest: /var/tmp
      validate_certs: False

  - name: Upload iApp template to BIG-IP
    bigip_iapp_template:
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username }}"
      password: "{{ bigip_password }}"
      content: "{{ lookup('file', '/var/tmp/appsvcs_integration_v2.0.003.tmpl') }}" #Name of iApp
      state: "present"
      validate_certs: False
    delegate_to: localhost

  - name: Deploy iApp
    bigip_iapp_service:
      name: "HTTP_VS_With_L7Firewall"
      template: "appsvcs_integration_v2.0.003"
      parameters: "{{ lookup('file', 'final_iapp_with_asm.json') }}" #JSON blob for body content to the iApp
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username}}"
      password: "{{ bigip_password }}"
      state: "present"
    delegate_to: localhost

Use Case: Disaster Recovery

Problem

All organizations should have a disaster recovery plan in place incase of a catastrophic failure resulting in loss of data including BIG-IP configuration data. Re-configuring the entire infrastructure from scratch can be an administrative nightmare. The procedure in place for disaster recovery can also be used for migrating data from one BIG-IP to another as well as for performing hardware refresh and RMA’s.

Solution

Use BIG-IP user configuration set (UCS) configuration file to restore the configuration on all the BIG-IP’s and have your environment back to its original configuration in minutes.

Modules

• bigip_ucs

Sample

---
- name: Create UCS file
  hosts: bigip
  gather_facts: false

  tasks:

  - name: Create ucs file and store it
    bigip_ucs:
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username }}"
      password: "{{ bigip_password }}"
      ucs: "/root/test.ucs"
      state: "installed"
    delegate_to: localhost

Use Case: Troubleshooting

Problem

Any problem on the BIG-IP for example a backend server not receiving traffic or a virtual server dropping traffic unexpectedly or a monitor not responding correctly needs extensive troubleshooting. These problems can be hard to pin point and need an expert to debug and look through the logs.

Solution

Qkview is a great utility on the BIG-IP which that an administrator can use to automatically collect configuration and diagnostic information from BIG-IP and other F5 systems. Use this ansible module and run it against all BIG-IP’s in your network and collect the diagnostic information to pass it onto to F5 support.

Modules

• bigip_qkview

Sample

- name: Create qkview
  hosts: bigip
  gather_facts: false

  tasks:

  - name: Generate and store qkview file
    bigip_qkview:
      server: "{{ bigip_ip_address }}"
      user: "{{ bigip_username }}"
      password: "{{ bigip_password }}"
      asm_request_log: "no"
      dest: "/tmp/localhost.localdomain.qkview"
      validate_certs: "no"
    delegate_to: localhost

Conclusion

These are just some of the use cases that can be tackled using our BIG-IP ansible modules. We have several more modules in Ansible 2.4 release that the ones mentioned above which can help in other scenarios. To view a complete list of BIG-IP modules available in ansible 2.4 release click here

Module overview at a glance

BIG-IP modules in Ansible release 2.3

New BIG-IP modules in Ansible release 2.4

To get started and save time download a BIG-IP onboarding ansible role from ansible galaxy and run the playbook against your BIG-IP