Ansible, Terraform and configuration management

A real-life situation

Three months ago you rolled out VLAN 30 for cameras. Since then, someone added it by hand on SW2 with a different name, someone else changed an NTP server on SW1 "just for a test", and a new switch was configured from an old copy of the template. Every switch is now slightly different, and nobody knows which one is right.

This is configuration drift: devices that were meant to match slowly drift apart through manual changes. Configuration management tools stop it by keeping the correct configuration in files and applying it automatically.

What it is

Configuration management means defining how devices should be configured in text files, storing those files in one place (often a Git repository, which records every change and who made it), and using a tool to make the devices match. Treating configuration like program code is called infrastructure as code (IaC).

The tools differ in a few ways the CCNA expects you to know:

• Agent vs. agentless: an agent is software installed on the managed device. Agentless tools use what the device already has (SSH, NETCONF, a REST API). Most network devices can't run agents, so agentless tools fit networking well.
• Push vs. pull: in a push model the central server connects out and sends the configuration. In a pull model each device's agent regularly asks the server for its configuration.
• Declarative vs. procedural: declarative means you describe the end state ("VLAN 30 exists, named CAMERAS") and the tool works out the steps. Procedural (imperative) means you list the steps to run in order.

Why it works that way

• One source of truth: the files say what is correct. If a device differs, the device is wrong, not the file.
• Idempotence: good modules check the current state first and only change what differs. Running the same playbook ten times leaves the device exactly as running it once would. That is what makes scheduled "fix the drift" runs safe.
• Review and rollback: because changes are files in Git, a colleague can review them before they run, and you can go back to last week's version.
• Scale: the effort to change 2 switches or 200 is the same: edit one file, run one command.

How Ansible works step by step

Ansible needs three things on the control node (the NetOps PC in the lab):

• An inventory: the list of devices, in groups, with how to reach them.
• A playbook: a YAML file with one or more plays, each a list of tasks.
• Modules: the code each task calls. The cisco.ios collection has modules such as ios_vlans, ios_interfaces and ios_config.

How Terraform works step by step

Terraform is declarative and keeps a state file: its record of every resource it manages. Each run compares three things: your files, the state file, and the real infrastructure.

How to configure it

On the Cisco devices

An agentless tool only needs management access. On SW1 and SW2 give Ansible its own account, so its changes are easy to spot in logs:

The steps to turn on RESTCONF are in REST APIs and JSON.

The Ansible inventory and playbook

[access_switches]
SW1 ansible_host=10.10.1.11
SW2 ansible_host=10.10.1.12

[access_switches:vars]
ansible_network_os=cisco.ios.ios
ansible_connection=ansible.netcommon.network_cli
ansible_user=automation

---
- name: Standard VLANs on access switches
  hosts: access_switches
  gather_facts: false

  tasks:
    - name: Ensure VLANs exist
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 10
            name: USERS
          - vlan_id: 20
            name: VOICE
          - vlan_id: 30
            name: CAMERAS
          - vlan_id: 99
            name: MGMT
        state: merged

YAML uses indentation (spaces, never tabs) instead of braces. A list item starts with - , and key: value pairs work like JSON objects. Unlike JSON, YAML allows comments with #.

Run it first in check mode, which reports what would change without touching the devices, then for real:

The same VLAN with Terraform

terraform {
  required_providers {
    iosxe = {
      source = "CiscoDevNet/iosxe"
    }
  }
}

provider "iosxe" {
  username = "automation"
  password = var.device_password
  url      = "https://10.10.1.11"
}

resource "iosxe_vlan" "cameras" {
  vlan_id = 30
  name    = "CAMERAS"
}

How to verify it

netops$ ansible-playbook -i inventory.ini vlans.yml --ask-pass
SSH password:

PLAY [Standard VLANs on access switches] ***************************************

TASK [Ensure VLANs exist] ******************************************************
changed: [SW1]
ok: [SW2]

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

SW1#show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/13, Gi1/0/14
10   USERS                            active    Gi1/0/1, Gi1/0/2
20   VOICE                            active
30   CAMERAS                          active
99   MGMT                             active
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

netops$ terraform plan
Terraform will perform the following actions:

  # iosxe_vlan.cameras will be created
  + resource "iosxe_vlan" "cameras" {
      + id      = (known after apply)
      + name    = "CAMERAS"
      + vlan_id = 30
    }

Plan: 1 to add, 0 to change, 0 to destroy.

What goes wrong and how to troubleshoot it

Common mistakes

• Calling Ansible agent-based. It is agentless and pushes over SSH; Puppet and Chef are the agent-based, pull-model tools.
• Using tabs in YAML, or getting the indentation wrong: the playbook won't parse.
• Skipping --check (or terraform plan) before a change to many devices.
• Storing device passwords in plain text in the inventory or .tf files.
• Fixing a device by hand after automating it, which creates the very drift the tool is there to remove.

💡 Exam tip: the CCNA asks you to recognize the capabilities of configuration management tools such as Ansible and Terraform. Know that both are agentless; Ansible uses YAML playbooks and pushes over SSH; Terraform uses HCL, is declarative, and tracks what it built in a state file. If Puppet or Chef come up, they are agent-based and pull their configuration. Also know what configuration drift is and why idempotence matters.

Key takeaways

• Configuration drift: devices drift from the standard through manual changes.
• Infrastructure as code keeps the intended config in files, ideally in Git.
• Ansible: agentless, push, YAML playbooks, inventory, modules such as cisco.ios.ios_vlans.
• Terraform: agentless, declarative HCL, providers, plan then apply, state file.
• Puppet and Chef: agent-based, pull model.
• Verify on the device too: show commands still have the final word.

Check yourself