7.6. Configuration Management (Ansible, Terraform)

💡 First Principle: Configuration management tools treat network configuration as code—define the desired state in files, and the tool makes reality match. Think of it like a recipe: instead of manually configuring each device, you write down what you want and let the tool do the cooking.

Consider this scenario: You have 200 switches. A security policy changes, requiring a new ACL on every device. Without Ansible: SSH to each one, paste the config, hope you don't typo, and document that you did it. With Ansible: update one playbook, run it, and it applies the change everywhere in minutes—with a log of exactly what changed. The difference is hours of manual work versus minutes of automated execution.

What happens without configuration management: Over time, devices drift. Someone makes an emergency change on one switch but forgets to document it. Another switch gets configured slightly differently. Six months later, traffic behaves oddly on some devices but not others. Without config management, you can't even prove what changed. With it, every change is versioned in Git—you see exactly who changed what and when, and you can roll back instantly.

Ansible:

• Agentless: Uses SSH to connect to devices (no software to install)
• YAML playbooks: A playbook is an ordered list of tasks executed top to bottom (a procedural style), while each module call describes the end state it wants (e.g., "VLAN 10 present")
• Idempotent: Running multiple times produces same result (won't duplicate VLANs). The run report shows changed for a device that had to be modified and ok for one already in the desired state
• Inventory: A file listing the managed devices, organized into groups (by site, role, etc.) that playbooks target; modules do the work of individual tasks, and roles package reusable sets of tasks
• Push model: Controller pushes config to devices
• Contrast: Puppet, Chef, and SaltStack are traditionally agent-based—software (an agent or minion) runs on each managed node, and Puppet/Chef agents pull their configuration from a central server

# Example Ansible playbook
- name: Configure VLAN
  hosts: switches
  tasks:
    - name: Create VLAN 10
      cisco.ios.ios_vlans:
        config:
          - vlan_id: 10
            name: HR

Terraform

• Infrastructure as Code: Define resources in HCL files
• Declarative provisioning: You describe the end state (which networks, VMs, and cloud resources should exist); Terraform compares it with its state and creates, changes, or destroys only what differs. Its strength is provisioning infrastructure through provider APIs; configuring software inside a running OS or device is traditionally the job of a configuration-management tool such as Ansible
• Provider-based: Plugins for different platforms (AWS, Azure, network vendors)
• State management: Tracks what's deployed so it knows what to change
• Plan before apply: Preview changes before making them—no surprises