Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 

Ansible is an orchestration and automation engine. It provides a means for you to automate the administration of different devices, from Linux to Windows and different special purpose appliances in-between. Ansible falls into the world of DevOps related tools. You may have heard of others that play in this area as well including.

  • Chef
  • Puppet
  • Saltstack

In this article I'm going to briefly skim the surface of what Ansible is and how you can get started using it. I've been toying around with it for some years now, and (most recently at F5) using it to streamline some development work I've been involved in.

If you, like me, are a fan of dabbling with interesting tools and swear by the "Automate all the Things!" catch-phrase, then you might take an interest in Ansible.

We're going to start small though and build upon what we learn. My goal here is to eventually bring you all to the point where we're doing some crazy awesome things with Ansible and F5 products. I'll also go into some brief detail on features of Ansible that make it relatively painless to interoperate with existing F5 products. Let's get started!

So why Ansible?

Any time that it comes to adopting some new technology for your everyday use, inevitably you need to ask yourself "what's in it for me?". Why not just use some custom shell scripts and pssh to do everything? Here are my reasons for using Ansible.

  • It is agent-less
  • The only dependencies (on the remote device) are SSH and python; and even python is not really a dependency
  • The language that you "do" stuff in is YAML. No CS degree or programming language expertise is required (Perl, Ruby, Python, etc)
  • Extending it is simple (in my opinion)
  • Actions are idempotent
  • Order of operations is well-defined and work is performed top-down

Many of the original tools in the DevOps space were agent-based tools. This is a major problem for environments where it's literally (due to technology or politics) impossible to install an agent. Your SLA may prohibit you from installing software on the box. Or, you might legitimately not be able to install the software due to older libraries or other missing dependencies. Ansible has no agent requirement; a plus in my book. Most of the systems that you will come across can be, today, manipulated by Ansible. It is agent-less by design.

Dependency wise you need to be able to connect to the machine you want to orchestrate, so it makes sense that SSH is a dependency. Also, you would like to be able to do higher-order "stuff" to a machine. That's where the python dependency comes into play. I say dependency loosely though, because Ansible provides a way to run raw commands on remote systems regardless of whether Python is installed. For professional Ansible development though, this method of orchestrating devices is largely not recommended except in very edge cases.

Ansible's configuration language is YAML. If you have never seen YAML before, this is what it looks like

- name: Deploy common hosts files settings
  hosts: all
  connection: ssh
  gather_facts: true
      - name: Install required packages
            name: "{{ item }}"
            state: "present"
            - ntp
            - ubuntu-cloud-keyring
            - python-mysqldb

YAML is generally composed of simple key/value pairs, lists, and dictionaries. Contrast this with the Puppet configuration language; a special DSL that resembles a real programming language.

class sso {
  case $::lsbdistcodename {
    default: {
      $ssh_version = 'latest'
  class { '::sso':
    ldap_uri          => $::ldap_uri,
    dev_env          => true,
    ssh_version      => $ssh_version,
    sshd_allow_groups => $::sshd_allow_groups,

Or contrast this with Chef, in which you must know Ruby to be able to use.

servers = search(
  "is_server:true AND chef_environment:#{node.chef_environment}"
).sort! do
  |a, b| <=>
rescue Chef::Exceptions::ResourceNotFound
  service 'mysql'
template "#{mysql_dir}/etc/my.conf" do
  source 'my.conf.erb'
  mode 0644
  variables :servers => servers, :mysql_conf => node['mysql']['mysql_conf']
  notifies :restart, 'service[mysql]'

In Ansible, work that is performed is idempotent. That's a buzzword. What does it mean?

It means that an operation can be performed multiple times without changing the result beyond its initial application. If I try to add the same line to a file a thousand times, it will be added once and then will not be added again 999 times. Another example is adding user accounts. They would be added once, not many times (which might raise errors on the system).

Finally, Ansible's workflow is well defined. Work starts at the top of a playbook and makes its way to the bottom. Done. End of story. There are other tools that have a declarative model. These tools attempt to read your mind. "You declare to me how the node should look at the end of a run, and I will determine the order that steps should be run to meet that declaration."

Contrast this with Ansible which only operates top-down. We start at the first task, then move to the second, then the third, etc.

This removes much of the "magic" from the equation. Often times an error might occur in a declarative tool due specifically to how that tool arranges its dependency graph. When that happens, it's difficult to determine what exactly the tool was doing at the time of failure.

That magic doesn't exist in Ansible; work is always top-down whether it be tasks, roles, dependencies, etc. You start at the top and you work your way down.


Let's now take a moment to install Ansible itself. Ansible is distributed in different ways depending on your operating system, but one tried and true method to install it is via pip; the recommended tool for installing python packages.

I'll be working on a vanilla installation of Ubuntu 15.04.2 (vivid) for the remaining commands.

Ubuntu includes a pip package that should work for you without issue. You can install it via apt-get.

sudo apt-get install python-pip python-dev

Afterwards, you can install Ansible.

sudo pip install markupsafe ansible==1.9.4

You might ask "why not ansible 2.0". Well, because 2.0 was just released and the community is busy ironing out some new-release bugs. I prefer to give these things some time to simmer before diving in. Lucky for us, when we are ready to dive in, upgrading is a simple task.

So now you should have Ansible available to you.

SEA-ML-RUPP1:~ trupp$ ansible --version
ansible 1.9.4
  configured module search path = None
SEA-ML-RUPP1:~ trupp$

Your first playbook

Depending on the tool, the body of work is called different things.

  • Puppet calls them manifests
  • Chef calls them recipes and cookbooks
  • Ansible calls them plays and playbooks
  • Saltstack calls them formulas and states

They're all the same idea. You have a system configuration you need to apply, you put it in a file, the tool interprets the file and applies the configuration to the system. We will write a very simple playbook here to illustrate some concepts. It will create a file on the system. Booooooring. I know, terribly boring. We need to start somewhere though, and your eyes might roll back into your head if we were to start off with a more complicated example like bootstrapping a BIG-IP or dynamically creating cloud formation infrastructure in AWS and configuring HA pairs, pools, and inje...

So we are going to create a single file. We will call it site.yaml. Inside of that file paste in the following.

- name: My first play
  hosts: localhost
  connection: local
  gather_facts: true
      - name: Create a file
            dest: "/tmp/test.txt"
            content: "This is some content"

This file is what Ansible refers to as a Playbook. Inside of this playbook file we have a single Play (My first play). There can be multiple Plays in a Playbook.

Let's explore what's going on here, as well as touch upon the details of the play itself. First, that Play.

Our play is composed of a preamble that contains the following

  • name
  • hosts
  • connection
  • gather_facts

The name is an arbitrary name that we give to our Play so that we will know what is being executed if we need to debug something or otherwise generate a reasonable status message. ALWAYS provide a name for your Plays, Tasks, everything that supports the name syntax.

Next, the hosts line specifies which hosts we want to target in our Play. For this Play we have a single host; localhost. We can get much more complicated than this though, to include

  • patterns of hosts
  • groups of hosts
  • groups of groups of hosts
  • dynamically created hosts
  • hosts that are not even real

You get the point.

Next, the connection line tells Ansible how to connect to the hosts. Usually this is the default value ssh. In this case though, because I am operating on the localhost, I can skip SSH altogether and simply say local.

After that, I used the gather_facts line to tell Ansible that it should interrogate the remote system (in this case the system localhost) to gather tidbits of information about it. These tidbits can include the installed operating system, the version of the OS, what sort of hardware is installed, etc.

After the preamble is written, you can see that I began a new block of "stuff". In this case, the tasks associated with this Play. Tasks are Ansible's way of performing work on the system. The task that I am running here is using the copy module. As I did with my Play earlier, I provide a name for this task. Always name things! After that, the body of the module is written. There are two arguments that I have provided to this module (which are documented more in the References section below)

  • dest
  • content

I won't go into great deal here because the module documentation is very clear, but suffice it to say that dest is where I want the file written and content is what I want written in the file.

Running the playbook

We can run this playbook using the ansible-playbook command. For example.

SEA-ML-RUPP1:~ trupp$ ansible-playbook -i notahost, site.yaml

The output of the command should resemble the following

PLAY [My first play] ******************************************************
GATHERING FACTS ***************************************************************
ok: [localhost]
TASK: [Create a file] *********************************************************
changed: [localhost]
PLAY RECAP ********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0

We can also see that the file we created has the content that we expected.

SEA-ML-RUPP1:~ trupp$ cat /tmp/test.txt
This is some content

A brief aside on the syntax to run the command. Ansible requires that you specify an inventory file to provide hosts that it can orchestrate. In this specific example, we are not specifying a file. Instead we are doing the following

  1. Specifying an arbitrary string (notahost)
  2. Followed by a comma

In Ansible, this is a short-hand trick to skip the requirement that an inventory file be specified. The comma is the key part of the argument. Without it, Ansible will look for a file called notahost and (hopefully) not find it; raising an error otherwise.

The output of the command is shown next. The output is actually fairly straight-forward to read. It lists the PLAYs and TASKs that are running (as well as their names...see, I told you you wanted to have names). The status of the Tasks is also shown. This can be values such as

  • changed
  • ok
  • failed
  • skipped
  • unreachable

Finally, all Ansible Playbook runs end with a PLAY RECAP where Ansible will tell you what the status of the various plays on your hosts were. It is at this point where a Playbook will be considered successful or not. In this case, the Playbook was completely successful because there were not unreachable hosts nor failed hosts.


This was a brief introduction to the orchestration and automation system Ansible.

There are far more complex subjects related to Ansible that I will touch upon in future posts. If you found this information useful, rate it as such. If you would like to see more advanced topics covered, videos demo'd, code samples written, or anything else on the subject, let me know in the comments below.

Many organizations, both large and small, use DevOps tools like the one presented in this post. Ansible has several features, per design, that make it attractive to these organizations (such as being agent-less, and having minimum requirements).

If you'd like to see crazy sophisticated examples of Ansible in use...well...we'll get there. You need to rate and comment on my posts though to let me know that you want to see more.


Good primer Tim. Could this be used to easily push system changes.. like disabling SSLv3, changing sflow/snmp settings, etc.? If so, perhaps some practical examples?
Oh yes, Ansible makes this very easy and straight forward.
Hey chad, Yes, you could use this approach to push system changes. Ansible's approach, typically, is to encapsulate this ability in modules that target a specific feature. Here's the repo on github that I set up to hold our modules as we work with Ansible and the community to see the upstreamed. If you, or anyone, is interested, feel free to open issues there so I can track modules that folks would like to see created. In the future I'll be posting links to roles and playbooks that have practical examples as well. If you've got any particular ideas, feel free to post them here or as issues on the github and I'll with links to codeshares here. Thanks!
Great Stuff, Can i find some more info on this ?
Tim, thanks for this introduction. I'm currently planning to use ansible for automation tasks like rolling out python scripts and cron jobs to a bunch of bigIPs. It might also become interesting for creating tmsh objects like pools and virtuals, though currently, I'm using iControl REST for that. So, I'd really like to see some practical and more f5-specific examples here, too.

If you found this information useful, rate it as such. - DONE


You need to rate and comment on my posts though to let me know that you want to see more. - DONE


If you would like to see more advanced topics covered, videos demo'd, code samples written, or anything else on the subject, let me know in the comments below - DONE


Now, can we have more, please?





Tim, thank you for the write up ! I just installed Ansible and want to write some small stuff so I can get my feet wet. Can you write up more with examples for beginners like me ? I just want to do small stuff to start with and as I get more confident, create more complex stuff.



I've read information elsewhere suggesting that Ansible is usable with bigip versions 11.6 or 12.x. I've got a mix of 11.4.1 and 11.5.4. Am i out of luck? Initial attempts are generating the following message:


PLAY [F5s] ****************************************************************************************************************************


TASK [create shared directory] ******************************************************************************************************** fatal: [ltm_name]: FAILED! => {"changed": false, "failed": true, "msg": "Error: ansible requires the stdlib json or simplejson module, neither was found!"}


For now I'm just trying to do standard unix admin stuff, setting up a configuration backup job that runs from cron.



What are the current software level dependencies to get ansible f5 to work? no mention of f5-sdk, suds, bigbugs, nothing..



Tim, I'm having trouble with the code in K10531487: Running Ansible tasks on the active BIG-IP in a device group. This build and variables works for other f5 ansible plays and roles. I've been debugging this all day..please help.


This is the playbook:


- name: "Syncing F5 Active config to group"
  hosts: "drhaf5"
  serial: 1
    - "vars/main.yml"
    - "vars/vault.yml"
  gather_facts: "no"
    - "f5syncactive"

    - name: "Get bigip facts"
        server: "{{inventory_hostname}}"
        user: "admin"
        password: "{{adminpass}}"
          - "device"
          - "system_info"
        validate_certs: False
      check_mode: no
      delegate_to: "localhost"

    - name: "Display bigip facts {{inventory_hostname}}"
          - "Hostname: {{ system_info.system_information.host_name }}"
          - "Status: {{ device['/Common/' + system_info.system_information.host_name].failover_state }}"
    - name: "Create pool"
        server: "{{inventory_hostname}}"
        user: "admin"
        password: "{{adminpass}}"
        lb_method: "round-robin"
        monitors: http
        name: "pool1"
        validate_certs: False
        - "Save the running configuration to disk"
        - "Sync configuration from device to group"
      delegate_to: "localhost"
      when: device['/Common/' + system_info.system_information.host_name].failover_state == "HA_STATE_ACTIVE"

    - name: "Save the running {{inventory_hostname}} configuration to disk"
        save: "yes"
        server: "{{inventory_hostname}}"
        user: "admin"
        password: "{{adminpass}}"
        validate_certs: False
      delegate_to: localhost

    - name: "Handler Sync configuration from {{inventory_hostname}} to group"
        device_group: "sync-failover-group"
        sync_device_to_group: "yes"
        server: "{{inventory_hostname}}"
        user: "admin"
        password: "{{adminpass}}"
        validate_certs: False
      delegate_to: localhost

When the play runs on the a standby box it gets facts and skips, as expected:


TASK [Display bigip facts] ******************************************
ok: [] => {}


[u'Hostname:', u'Status: HA_STATE_STANDBY']

TASK [Create pool] ************************************************************************************
skipping: [] => {
    "changed": false,
    "skip_reason": "Conditional result was False"

PLAY [Syncing F5 Active config to group] **************************************************************

TASK [Get bigip facts] ********************************************************************************
ok: [ -> localhost] => {
    "ansible_facts": {
        "device": {
            "/Common/": {

But when it runs on the b box, it fails with "Unexpected **kwargs: {'verify': False}". I have verified that the passwords are equal from a to b boxes. And ansible is able to get facts in the play above.


TASK [Display bigip facts] ******************************************
ok: [] => {}


[u'Hostname:', u'Status: HA_STATE_ACTIVE']

TASK [Create pool] ************************************************************************************
fatal: [ -> localhost]: FAILED! => {
    "changed": false


Unable to connect to on port 443. The reported error was "Unexpected **kwargs: {'verify': False}".

        to retry, use: --limit @/home/eh7305/scripts/ansible/f5tst.retry

PLAY RECAP ******************************************************************************************** : ok=2    changed=0    unreachable=0    failed=0 : ok=2    changed=0    unreachable=0    failed=1

Is F5 still supporting/maintaining f5-ansible? I just realized that Tim Rupp is no longer with F5.

We have a ton of stuff depending on it.

Version history
Last update:
‎20-Jan-2016 10:32
Updated by: