This knowledge base has moved to the documentation site. Please visit the knowledge base here for the most up to date content. This site is no longer maintained.

Ansible: Simple Playbook Example with a Quagga Template


The following knowledge base article describes a very simple Ansible example. Use it to learn Ansible; don't use it as a production level script. Please refer to the Demos and Training section for more robust examples with Ansible and other DevOp tools.



Requirements for the Ansible Playbook

The following is always required to run a playbook:

Optional files used in this example:

Installing Ansible

The following was performed on Ubuntu:

cumulus@wbench:~$ sudo apt-get update
cumulus@wbench:~$ sudo apt-get install ansible

If you don't have Ubuntu, you can install Ansible on Red Hat, Debian, CentOS, OSX, any BSD distro, and so on. See this page on

Configuring the Necessary Files

Simply cut and paste the code snippets from the code blocks below. Here are all the pieces of code used in the example.

Inventory File

The inventory is a single file called host with the contents "leaf1" inside.

cumulus@wbench:~$ cat host

Again, this is a very simple example. Please read more about creating inventory files on

Playbook .yml File

cumulus@wbench:~$ cat sample-playbook.yml
- hosts: leaf1
    description: “this is a leaf switch”
  remote_user: root
  - name: write the quagga config file
    template: src=quagga.j2 dest=/etc/quagga/Quagga.conf
    - restart quagga
  - name: ensure quagga is running
    service: name=quagga state=started
    - name: restart quagga
      service: name=quagga state=restarted

This sample-playbook.yml contains one variable, two tasks, and a handler. Each component is describedin the table below:

hosts:leaf1 Only run this playbook on the host leaf1.
vars These are the variables defined for the playbook. There is only one variable, called description.
remote_user This is the user who will run the playbook on the remote system.
tasks There are two tasks listed, one is using the template module and one is using the service module.
handlers Handlers are tasks that only run if a task notifies it. A task will only notify it if something has changed. In this example, Quagga gets restarted only if Quagga.conf changes.

jinja2 Template File

The template file can use any of the defined variables. The script below replaces the {{description}} with the one listed under vars:

cumulus@wbench:~$ cat quagga.j2
interface lo
  description {{description}}

Running the Playbook

Use the ansible-playbook command to run the sample-playbook.yml file. Use the optional argument -i to point to the inventory file. If the -i option is not used, and there is no ansible.cfg folder indicating otherwise, Ansible will automatically use /etc/ansible/hosts. Alternately, instead of creating the file host with leaf1 in it, simply add leaf1 to /etc/ansible/hosts.

cumulus@wbench:~$ ansible-playbook sample-playbook.yml -i host

PLAY [leaf1] ******************************************************************

GATHERING FACTS ***************************************************************
ok: [leaf1]

TASK: [write the quagga config file] ******************************************
changed: [leaf1]

TASK: [ensure quagga is running] **********************************************
ok: [leaf1]

NOTIFIED: [restart quagga] ****************************************************
changed: [leaf1]

PLAY RECAP ********************************************************************
leaf1                      : ok=4    changed=2    unreachable=0    failed=0

The playbook above runs both tasks. Since Quagga was changed, it notifies the tasks, which restarts the Quagga service. The playbook assumes that Quagga was already running, otherwise this playbook will fail.

See Also


This support portal has moved

Cumulus Networks is now part of the NVIDIA Networking Business Unit! The NVIDIA Cumulus Global Support Services (GSS) team has merged its operations with the NVIDIA Mellanox support services team.

You can access NVIDIA Cumulus support content from the Mellanox support portal.

You open and update new cases on the Mellanox support portal. Any previous cases that have been closed have been migrated to the Mellanox support portal.

Cases that are still open on the Cumulus portal will continue to be managed on the Cumulus portal. Once these cases close, they will be moved to the Mellanox support portal.

Powered by Zendesk