1-2: First Ansible Playbook

Use Ansible to update the configuration of routers. This exercise will not create an Ansible Playbook, but use an existing one that has been provided.

Learning objectives

By the end of this module, you will be able to:

  • Examine an existing Ansible Playbook

  • Execute an Ansible Playbook on the command line using ansible-navigator

  • Understand and validate idempotency in network automation

  • Use check mode (--check) to preview changes without applying them

  • Use verbose mode (-v) for detailed output

Step 1: Examine Ansible Playbook

Navigate to the network-workshop directory if you are not already there.

[rhel@vscode ~]$ cd ~/network-workshop/
[rhel@vscode network-workshop]$
[rhel@vscode network-workshop]$ pwd
/home/rhel/network-workshop

Examine the provided Ansible Playbook named playbook.yml. Either open the file in Visual Studio Code or cat the file:

---
- name: SNMP ro/rw string configuration
  hosts: cisco
  gather_facts: false

  tasks:
    - name: Ensure that the desired snmp strings are present
      cisco.ios.ios_config:
        commands:
          - snmp-server community ansible-public RO
          - snmp-server community ansible-private RW

  • cat — Linux command allowing us to view file contents

  • playbook.yml — provided Ansible Playbook

We will explore in detail the components of an Ansible Playbook in the next exercise. It is suffice for now to see that this playbook will run two Cisco IOS-XE commands:

snmp-server community ansible-public RO
snmp-server community ansible-private RW

Step 2: Execute Ansible Playbook

Run the playbook using the ansible-navigator command. The full command is:

ansible-navigator run playbook.yml --mode stdout
[rhel@vscode network-workshop]$ ansible-navigator run playbook.yml --mode stdout

PLAY [SNMP ro/rw string configuration] *****************************************

TASK [Ensure that the desired snmp strings are present] ************************
changed: [rtr1]

PLAY RECAP *********************************************************************
rtr1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

[rhel@vscode network-workshop]$

  • --mode stdout — By default ansible-navigator will run in interactive mode. The default behavior can be modified by modifying the ansible-navigator.yml. As playbooks get longer and involve multiple hosts the interactive mode allows you to "zoom in" on data in real-time, filter it, and navigate between various Ansible components. Since this task only ran one task on one host the stdout is sufficient.

Step 3: Verify configuration on router

Verify that the Ansible Playbook worked. Login to rtr1 and check the running configuration on the Cisco IOS-XE device.

[rhel@vscode network-workshop]$ ssh rtr1

rtr1#show run | i snmp
snmp-server community ansible-public RO
snmp-server community ansible-private RW

Step 4: Validate idempotency

The cisco.ios.config module is idempotent. This means, a configuration change is pushed to the device if and only if that configuration does not exist on the end hosts.

Need help with Ansible Automation terminology? Check out the glossary for more information on terms like idempotency.

To validate the concept of idempotency, re-run the playbook:

[rhel@vscode network-workshop]$ ansible-navigator run playbook.yml --mode stdout

PLAY [SNMP ro/rw string configuration] *****************************************

TASK [Ensure that the desired snmp strings are present] ************************
ok: [rtr1]

PLAY RECAP *********************************************************************
rtr1                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
See that the changed parameter in the PLAY RECAP indicates 0 changes.

Re-running the Ansible Playbook multiple times will result in the same exact output, with ok=1 and change=0. Unless another operator or process removes or modifies the existing configuration on rtr1, this Ansible Playbook will just keep reporting ok=1 indicating that the configuration already exists and is configured correctly on the network device.

Step 5: Modify Ansible Playbook

Now update the task to add one more SNMP RO community string named ansible-test.

snmp-server community ansible-test RO

Use Visual Studio Code to open the playbook.yml file to add the command.

The Ansible Playbook will now look like this:

---
- name: SNMP ro/rw string configuration
  hosts: cisco
  gather_facts: false

  tasks:
    - name: Ensure that the desired snmp strings are present
      cisco.ios.ios_config:
        commands:
          - snmp-server community ansible-public RO
          - snmp-server community ansible-private RW
          - snmp-server community ansible-test RO

Make sure to save the playbook.yml with the change.

Step 6: Use check mode

This time however, instead of running the playbook to push the change to the device, execute it using the --check flag in combination with the -v or verbose mode flag:

[rhel@vscode network-workshop]$ ansible-navigator run playbook.yml --mode stdout --check -v
Using /etc/ansible/ansible.cfg as config file

PLAY [SNMP ro/rw string configuration] *****************************************

TASK [Ensure that the desired snmp strings are present] ************************
changed: [rtr1] => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python"}, "banners": {}, "changed": true, "commands": ["snmp-server community ansible-test RO"], "updates": ["snmp-server community ansible-test RO"], "warnings": ["To ensure idempotency and correct diff the input configuration lines should be similar to how they appear if present in the running configuration on device"]}

PLAY RECAP *********************************************************************
rtr1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

The --check mode in combination with the --verbose flag will display the exact changes that will be deployed to the end device without actually pushing the change. This is a great technique to validate the changes you are about to push to a device before pushing it.

Step 7: Verify configuration is not present

Verify that the Ansible Playbook did not apply the ansible-test community. Login to rtr1 and check the running configuration on the Cisco IOS-XE device.

[rhel@vscode network-workshop]$ ssh rtr1

rtr1#show run | i snmp
snmp-server community ansible-public RO
snmp-server community ansible-private RW

Step 8: Re-run the Ansible Playbook

Finally re-run this playbook again without the -v or --check flag to push the changes.

[rhel@vscode network-workshop]$ ansible-navigator run playbook.yml --mode stdout

PLAY [SNMP ro/rw string configuration] *****************************************

TASK [Ensure that the desired snmp strings are present] ************************
changed: [rtr1]

PLAY RECAP *********************************************************************
rtr1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Step 9: Verify configuration is applied

Verify that the Ansible Playbook applied the ansible-test community. Login to rtr1 and check the running configuration on the Cisco IOS-XE device.

[rhel@vscode network-workshop]$ ssh rtr1

rtr1#sh run | i snmp
snmp-server community ansible-public RO
snmp-server community ansible-private RW
snmp-server community ansible-test RO

Module summary

In this module, you learned how to:

  • Examine an existing Ansible Playbook that configures SNMP community strings on Cisco IOS-XE devices

  • Execute playbooks using ansible-navigator run with --mode stdout

  • Verify that the config modules (e.g. cisco.ios.config) are idempotent — meaning they are stateful and only push changes when the desired configuration is not already present

  • Use check mode (--check) to preview changes without applying them to the remote device

  • Use verbose mode (-v) to see detailed output including which commands would be applied

  • This Ansible Playbook could be scheduled in Ansible Automation Platform to enforce the configuration. For example, the playbook could run once a day for a particular network. In combination with check mode, this could be a read-only playbook that detects and reports missing or modified configuration on the network.