Ansible for Network Automation: — From Zero to Your First Playbook

① Why Ansible for networks — drift, typos and 2 a.m. callbacks

Meet Rahul, an L1 engineer at Infosys looking after 500 branch switches. The standard rollout — say, a new login banner and an NTP server on every box — means he opens PuTTY, SSHes in, pastes four lines, saves, logs out, and repeats. Five hundred times. By switch 347 he fat-fingers an IP, by switch 480 he is copy-pasting yesterday's banner, and a week later no two configs are identical. That slow divergence is called configuration drift, and it is the quiet disease of every hand-run network.

There is also no record. When something breaks at 2 a.m., nobody can say who changed what on which box. Rahul is not lazy or careless — he is human, and humans do not scale to 500 identical tasks. This is exactly the gap Ansible was built to fill.

Three properties define Ansible, and you must be able to say each one in an interview. Agentless: you install no agent on the device — Ansible logs in over SSH (or an API) the same way you do, runs its work, and disconnects. Nothing to install, patch or break on 500 switches. Declarative: you describe the desired state ("this interface should have this description"), not the keystrokes to get there. Idempotent: run the same playbook ten times and it makes a change only the first time — after that it sees the state already matches and does nothing.

One more thing that trips up beginners: for routers and switches, Ansible does not use its normal SSH/shell module (the one it uses for Linux servers). Network gear has a CLI, not a shell, so Ansible loads a special network_cli connection. You point it at the right OS with ansible_network_os, and it knows how to handle the Cisco prompt, paging, and enable mode. We will set those variables in the next section.

The three words, one tap each

Tap each card — these are the answers to "what is Ansible?" that a hiring manager wants to hear.

② The pieces — control node, inventory, modules, collections, plays

Ansible has a small number of moving parts. Learn the names once and the rest of the series clicks. The control node is the only box with Ansible on it — your laptop or a jump host. Everything else is a managed device with nothing installed.

The inventory lists your devices and sorts them into groups — [routers], [switches], [mumbai]. Groups matter because you attach shared settings to a group once via group_vars, instead of repeating them per host. A task calls a module; a group of tasks aimed at a set of hosts is a play; one or more plays in a YAML file is a playbook.

Modules do not all ship in the box anymore. They live in collections you install from Ansible Galaxy. For Cisco IOS you install cisco.ios; for Arista, arista.eos; for Juniper, junipernetworks.junos; for VyOS, vyos.vyos. The Cisco collection depends on the shared ansible.netcommon collection, so installing cisco.ios pulls it in.

Now the network-specific part. By default Ansible would try to SSH and run a shell — useless on a router. So in your inventory or group_vars you set three things. ansible_connection: ansible.netcommon.network_cli loads the CLI connection. ansible_network_os: cisco.ios.ios tells it the platform. And to get into enable mode, you add become: yes with ansible_become_method: enable and an ansible_become_password (the enable secret).

# inventory.ini
[routers]
rtr-mum-01 ansible_host=10.10.1.1
rtr-pun-01 ansible_host=10.10.2.1

# group_vars/routers.yml
ansible_connection: ansible.netcommon.network_cli
ansible_network_os: cisco.ios.ios
ansible_user: netauto
ansible_become: yes
ansible_become_method: enable
ansible_become_password: "{{ vault_enable_secret }}"

# group_vars apply to every host in [routers],
# so you set the connection ONCE, not per device.
# The enable secret is pulled from an Ansible Vault
# variable — never hard-coded in the file.

A word on YAML, because it causes more first-day pain than any module. YAML uses spaces, never tabs, and indentation defines structure — two spaces in is "inside" the line above. A list item starts with - (dash-space). A key: value needs the space after the colon. Mis-indent one line and you get a cryptic "could not find expected ':'" error. When in doubt, run ansible-playbook --syntax-check site.yml before anything else.

③ Your first playbook — gather facts, push one line, run with --check

Time to build something real. A first playbook should do two safe things: read state and write one line. We will use ios_facts to gather facts, then ios_config to set an interface description. Both come from the cisco.ios collection.

---
- name: First IOS playbook
  hosts: routers
  gather_facts: false
  tasks:
    - name: Collect device facts
      cisco.ios.ios_facts:

    - name: Show the IOS version we found
      ansible.builtin.debug:
        msg: "Running IOS {{ ansible_net_version }} on {{ ansible_net_model }}"

    - name: Set the WAN interface description
      cisco.ios.ios_config:
        parents: interface GigabitEthernet0/1
        lines:
          - description WAN-uplink-to-Pune

PLAY [First IOS playbook] ******************************
TASK [Collect device facts] ***************************
ok: [rtr-mum-01]
TASK [Set the WAN interface description] *************
changed: [rtr-mum-01]
PLAY RECAP ********************************************
rtr-mum-01 : ok=3  changed=1  unreachable=0  failed=0

Notice gather_facts: false at the play level — the normal Linux fact-gathering does not work on a router, so we disable it and use the network-specific ios_facts task instead. The facts land in variables like ansible_net_version and ansible_net_model, which you can print or reuse. In ios_config, parents is the section header (interface GigabitEthernet0/1) and lines are the commands inside it.

You never run a new playbook straight at production. The flags are your seatbelt. --check is a dry run — it reports what would change and touches nothing. --diff shows the precise lines. --limit scopes the run to one box for a first test. And -v (up to -vvvv) turns up verbosity when something misbehaves.

# 1) dry run on ONE box, show the diff — changes nothing
ansible-playbook -i inventory.ini site.yml --limit rtr-mum-01 --check --diff

# 2) apply for real
ansible-playbook -i inventory.ini site.yml --limit rtr-mum-01

# 3) run again — proof it is idempotent
ansible-playbook -i inventory.ini site.yml --limit rtr-mum-01

# run 2 -> changed: [rtr-mum-01]   ok=3 changed=1 failed=0
# run 3 -> ok: [rtr-mum-01]        ok=3 changed=0 failed=0
# changed=0 the second time = the box already matches
# desired state. That is idempotency, proven.

④ From toy to real — variables, idempotency, ad-hoc & where to grow

Hard-coding one description in one playbook is a demo. Real automation drives data. You move per-device values into group_vars and host_vars, and your tasks reference variables instead of literals. Now the same playbook configures 500 different switches, each with its own NTP server or VLAN, just by changing the data.

# group_vars/routers.yml (added)
ntp_server: 10.20.0.10
banner_text: "Authorised access only - Infosys NetOps"

# task in site.yml
- name: Enforce NTP + banner from group_vars
  cisco.ios.ios_config:
    lines:
      - ntp server {{ ntp_server }}
      - banner motd ^{{ banner_text }}^

changed: [rtr-mum-01]   (first run, lines added)
ok:      [rtr-mum-01]   (second run, already present)
# change ntp_server in group_vars -> next run
# re-converges every router to the new value.

The reason re-running is safe bears repeating because it is the heart of the job: idempotency means "changed: false" on the second run. ios_config reads the running-config, compares your lines, and only sends what is missing. So a playbook is not a one-shot script — it is a statement of how the box should look that you can apply as often as you like.

Not everything needs a playbook. For a quick one-off — "show me the version on every router right now" — use an ad-hoc command. It is the ansible command (not ansible-playbook) with -m for the module and -a for arguments.

# gather facts from every router, one line
ansible routers -i inventory.ini -m cisco.ios.ios_facts

# run a show command on one box
ansible rtr-mum-01 -i inventory.ini \
  -m cisco.ios.ios_command -a "commands='show ip int brief'"

rtr-mum-01 | SUCCESS => {
  "ansible_facts": { "ansible_net_version": "17.9.4a",
    "ansible_net_model": "ISR4331", ... },
  "changed": false }

Where do you grow next? Three steps. Roles package your tasks into reusable bundles. Templates (Jinja2) build a whole per-device config from variables — one template, every switch. And Ansible Vault encrypts your enable passwords and tokens so the repo is safe to commit. Those are the next lessons.

For certification, this lesson maps onto the RHCE EX294 and the broader Ansible Network track. EX294 is a hands-on exam: you write real playbooks, use inventories and group_vars, run with the right modules, and rely on idempotency — exactly what you just did. The same building blocks (inventory, connection vars, modules, check mode) are what every "Ansible Network Automation" blueprint tests, and what a netauto interviewer probes in the first ten minutes.