Ansible for network engineers

Netmiko-style scripts are great for one-off tasks. Once you're managing configuration state across dozens or hundreds of devices — not just running a command, but making sure they all match an intended configuration — Ansible's declarative model starts to pay off.

Declarative beats imperative at scale

A script says "do these steps." A playbook says "this is the state I want" and lets the module figure out whether anything needs to change. Run the same playbook against a device that's already compliant and nothing happens — no side effects, no risk of re-applying a change that was only supposed to happen once. That idempotency is what makes it safe to run playbooks on a schedule instead of only by hand.

What a real playbook looks like

- name: Ensure NTP servers are configured
  hosts: routers
  gather_facts: false
  tasks:
    - name: Configure NTP
      cisco.ios.ios_ntp_global:
        config:
          servers:
            - server: 10.0.0.10
            - server: 10.0.0.11

Run this against 200 routers and only the ones missing an NTP server actually change. The other 198 report "ok, no change needed" — which is exactly the audit trail you want when someone asks "did we touch anything in that maintenance window."

Inventory is the part people underinvest in

The playbook is the easy part. The inventory — which devices exist, which group they belong to, which credentials and variables apply to them — is what determines whether Ansible scales cleanly or turns into another spreadsheet nobody trusts. Structuring inventory by role and site (not just a flat device list) from the start saves a painful rewrite once the fleet grows past what fits in your head.