Ansible and NetDevOps: playbooks, inventories and CI/CD for networks

What Ansible is

Ansible is an open-source automation tool that is popular with network teams because it is agentless (nothing to install on devices; it connects over SSH or APIs) and uses readable YAML playbooks instead of programming. Vendors publish collections of modules for their devices, such as cisco.ios, arista.eos and junipernetworks.junos.

Inventory and variables

# inventory.yml
all:
  children:
    branch_switches:
      hosts:
        br1-sw1:
          ansible_host: 192.168.99.11
        br2-sw1:
          ansible_host: 192.168.99.21
      vars:
        ansible_network_os: cisco.ios.ios
        ansible_connection: ansible.netcommon.network_cli
        ansible_user: netadmin

Store passwords with ansible-vault or a secrets manager, never in plain text.

A playbook

# vlans.yml: make sure every branch switch has the standard VLANs
- name: Standard branch VLANs
  hosts: branch_switches
  gather_facts: false
  tasks:
    - name: Configure VLANs
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 10
            name: STAFF
          - vlan_id: 20
            name: GUEST
          - vlan_id: 30
            name: CAMERAS
        state: merged

    - name: Save the configuration if it changed
      cisco.ios.ios_config:
        save_when: modified

Run it with ansible-playbook -i inventory.yml vlans.yml --check --diff first: check mode shows what would change without changing anything. Run it again without --check to apply. Because the module is idempotent, a second run reports no changes.

NetDevOps and CI/CD

• Git holds playbooks, templates and variables, so every change has an author, a reason and a history, and can be rolled back.
• Pull requests let a colleague review a change before it is merged.
• CI pipelines automatically run linting (for example yamllint and ansible-lint), lab tests and check-mode runs.
• Deployment happens from the pipeline in an approved change window, and post-checks confirm the network is healthy.

Good practice

• Begin with read-only playbooks: facts, backups and compliance reports.
• Use roles and templates so sites share one standard.
• Limit runs with --limit when testing, and roll out in waves.
• Keep a manual rollback plan for every automated change.
• Combine Ansible for configuration with Python for custom logic and reports.

Real-world example: a reviewed change instead of a late-night typo

A fictional logistics firm had suffered two outages caused by typing mistakes during night-time changes. The network team moved its standard changes, such as adding VLANs and updating NTP servers, into Ansible playbooks stored in Git. An engineer now makes a change on a branch and opens a pull request. The pipeline runs yamllint and ansible-lint, then runs the playbook in check mode against a lab copy of the network and posts the diff. A second engineer reviews the diff and approves the merge, and the pipeline applies the change during the agreed window and runs post-checks. In the first six months the team made more changes than in the previous year, with no change-related outages, and every change can be traced to an author and an approver.