SkarpChapter 28 of 29
Configuration Management with Ansible and Terraform Basics
Automate repetitive tasks and treat your network as code by learning how tools like Ansible and Terraform fit into Cisco environments at an introductory level.
Configuration Management and Network as Code
From CLI to Code
Instead of typing commands on each device, configuration management lets you describe the desired network state in files and push it consistently using tools.
Where Ansible and Terraform Fit
Ansible and Terraform sit above device APIs and SSH. They orchestrate changes across many devices and systems based on code you write.
Why This Matters for CCNA
CCNA expects you to understand network automation basics: desired state, declarative vs imperative, and how tools apply configs to Cisco devices.
Declarative vs Imperative Automation
Imperative: Step by Step
Imperative automation describes how to do something: a sequence of commands or API calls. CLI configuration and basic scripts are typically imperative.
Declarative: Desired State
Declarative automation describes the desired end state. The tool figures out the steps to reach that state and avoids changing things already correct.
Idempotency and Exams
Idempotent tools can run repeatedly without breaking things. Terraform and Ansible network modules aim for this, a common exam concept.
Ansible Basics for Network Automation
What Is Ansible?
Ansible is an open-source, agentless automation tool that connects to network devices over SSH or APIs to configure and collect information.
Key Pieces: Inventory and Playbooks
The inventory lists devices and groups. Playbooks are YAML files that describe what tasks to run on which groups of devices.
Modules and Variables
Network modules like iosconfig or nxosvlan perform actions. Variables hold values like VLAN IDs or IPs so you can reuse them cleanly.
Reading a Simple Ansible Network Playbook
Study this basic Ansible playbook and inventory for Cisco IOS XE. Your goal is to understand, at a high level, what configuration it will apply.
```ini
inventory.ini
[access_switches]
SW1 ansible_host=192.0.2.11
SW2 ansible_host=192.0.2.12
```
```yaml
create_vlans.yml
---
- name: Configure VLANs on access switches
hosts: access_switches
connection: network_cli
gather_facts: no
vars:
vlans:
- id: 10
name: USERS
- id: 20
name: VOICE
tasks:
- name: Ensure VLANs are present
cisco.ios.ios_vlan:
vlan_id: "{{ item.id }}"
name: "{{ item.name }}"
state: present
loop: "{{ vlans }}"
```
Questions to ask yourself as you read:
- Which devices will this playbook target?
- Which VLAN IDs and names will be configured?
- Is this more declarative or imperative in style?
Do not worry about every YAML detail yet. Focus on mapping the playbook to what you already know from CLI: creating VLANs on multiple switches consistently.
Step-by-Step: What the Ansible Playbook Actually Does
Targeting Devices
The play targets all hosts in the accessswitches group (SW1 and SW2). Ansible will log in to each switch using SSH and networkcli.
Defining VLANs as Data
The vars section lists VLANs as data: ID and name. This replaces typing vlan commands manually on each switch.
Module Behavior
The ios_vlan module loops over each VLAN, ensuring it exists. If it is already correct, nothing changes, showing idempotent, declarative behavior.
Terraform Basics and How It Differs from Ansible
What Terraform Does
Terraform is a declarative infrastructure as code tool. You describe resources in .tf files, and it creates or updates them to match.
Providers and State
Providers know how to talk to platforms like AWS or Cisco APIs. Terraform stores a state file to track real resources vs your config.
Terraform vs Ansible
Terraform is strong at provisioning new infrastructure. Ansible excels at configuring existing devices and handling day-2 changes.
Reading a Simple Terraform Network Configuration
Here is a simplified Terraform example using a generic cloud provider to create a virtual network and subnet that your Cisco edge router might connect to. You do not need to memorize provider names; focus on understanding the pattern.
```hcl
terraform {
required_providers {
examplecloud = {
source = "example/examplecloud"
version = "~> 1.0"
}
}
}
provider "examplecloud" {
region = "eu-central-1"
}
resource "examplecloud_vpc" "main" {
name = "corp-vpc"
cidr_block = "10.20.0.0/16"
}
resource "examplecloud_subnet" "users" {
name = "users-subnet"
vpcid = examplecloudvpc.main.id
cidr_block = "10.20.10.0/24"
}
```
Questions to consider:
- What is the overall network CIDR of the virtual network?
- How does the subnet relate to the parent virtual network?
- What kind of real-world topology might this represent when combined with a Cisco router or VPN?
Again, focus on the declarative nature: you are not writing commands to create a VPC or subnet; you simply declare that they must exist with certain properties.
Thought Exercise: Choosing Ansible vs Terraform
Work through these scenarios and decide which tool (Ansible, Terraform, or either) is the better fit and why. Think in terms of declarative vs imperative, provisioning vs configuration, and Cisco-related use cases.
- Scenario A: You already have 200 Cisco access switches deployed. You need to standardize interface descriptions, enable port security on all user-facing ports, and ensure the same set of VLANs is present on every switch.
- Which tool is more natural here? Why?
- Scenario B: Your company is expanding to a new region using a cloud provider. You need to create a new virtual network, subnets, and security groups, then later connect them to your on-premises Cisco WAN via VPN.
- Which tool is usually used to create the cloud network pieces? Where might Ansible still be useful?
- Scenario C: You want to periodically verify that all your branch routers still have the correct OSPFv2 configuration and ACL entries, and fix any drift if someone changed the CLI manually.
- Which tool is better for detecting and correcting configuration drift on existing Cisco devices?
Pause and actually write down your answers (even in bullet form). Comparing your reasoning to the explanations in this module will help lock in the differences between the tools.
Quiz 1: Declarative vs Imperative and Ansible Basics
Answer this question to check your understanding of automation styles and Ansible.
You run an Ansible playbook that uses the cisco.ios.ios_vlan module with state: present to configure VLAN 30 on a group of switches. VLAN 30 already exists with the correct name on some switches, but not on others. What is the MOST accurate description of what happens?
- Ansible fails on switches where VLAN 30 already exists, because the configuration is duplicated.
- Ansible skips changes on switches where VLAN 30 is already correct and only creates or fixes VLAN 30 on switches that need it.
- Ansible deletes VLAN 30 on all switches first, then recreates it to ensure consistency.
- Ansible pushes the VLAN configuration blindly to all switches, overwriting any existing VLAN 30 configuration.
Show Answer
Answer: B) Ansible skips changes on switches where VLAN 30 is already correct and only creates or fixes VLAN 30 on switches that need it.
Using a declarative, idempotent module like cisco.ios.ios_vlan with state: present means Ansible compares the current state to the desired state. If VLAN 30 already exists with the correct attributes, it does nothing; if it is missing or incorrect, it creates or fixes it. This is core declarative behavior and a common exam concept.
Quiz 2: Terraform Concepts in Network Context
Check your understanding of Terraform and where it fits in network automation.
Which statement best describes Terraform's role in a hybrid Cisco and cloud environment?
- Terraform directly logs into Cisco routers over SSH to configure interfaces and routing protocols line by line.
- Terraform is mainly used to provision and manage infrastructure resources (such as virtual networks and subnets) via providers and APIs, while tools like Ansible often handle detailed device configuration.
- Terraform replaces the need for any Cisco controllers or REST APIs by acting as a full network operating system.
- Terraform is only useful for Linux server configuration and has no role in network automation.
Show Answer
Answer: B) Terraform is mainly used to provision and manage infrastructure resources (such as virtual networks and subnets) via providers and APIs, while tools like Ansible often handle detailed device configuration.
Terraform is an infrastructure as code tool that uses providers to manage resources via APIs, including cloud networks and some network platforms. It is not primarily an SSH-based configuration tool for Cisco routers; Ansible and similar tools are more common for that role. In hybrid environments, Terraform often builds the cloud side, while Ansible configures Cisco devices.
Key Term Review: Ansible, Terraform, and Automation Styles
Flip through these cards to reinforce core concepts from this module.
- Imperative automation
- An approach where you specify how to perform a task step by step (for example, typing individual CLI commands or scripting each action in order). The focus is on the procedure rather than just the desired end state.
- Declarative automation
- An approach where you specify the desired end state (for example, which VLANs should exist) and let the tool figure out the steps to reach that state, often in an idempotent way.
- Idempotency
- A property of an operation where running it multiple times has the same effect as running it once. In network automation, this means you can reapply configurations safely without causing unintended changes.
- Ansible inventory
- A file that lists managed devices (hosts) and groups them logically, such as access_switches or branch_routers, so playbooks can target them.
- Ansible playbook
- A YAML file that defines one or more plays, each targeting a set of hosts and running a sequence of tasks using Ansible modules.
- Ansible module (network context)
- A reusable unit of work that performs specific actions on network devices, such as configuring VLANs or interfaces. Examples include cisco.ios.ios_config and cisco.ios.ios_vlan.
- Terraform provider
- A plugin that allows Terraform to manage resources on a specific platform (such as a cloud or network system) by talking to its APIs.
- Terraform state file
- A file where Terraform records which real-world resources it manages and how they map to configuration blocks, allowing it to compute changes between current and desired state.
- REST API
- A Representational State Transfer (REST) API is a web-based interface that uses HTTP methods and resource-oriented URIs to enable programmatic access to network devices and controllers.
- Typical Ansible use case in Cisco networks
- Automating configuration of existing routers and switches over SSH or controller APIs, such as applying standard VLANs, ACLs, or routing configurations across many devices.
- Typical Terraform use case in networking
- Provisioning network infrastructure resources (such as virtual networks, subnets, and security groups) in clouds or platforms via APIs, often as part of building hybrid topologies connected to Cisco devices.
Key Terms
- State
- In Terraform, the recorded mapping between configuration and real-world resources, used to determine what changes are needed to reach the desired state.
- Module
- In Ansible, a reusable component that performs a specific action (such as configuring an interface or VLAN) on a managed device.
- Ansible
- An open-source, agentless automation tool that uses inventories, playbooks, and modules to configure and manage devices, including Cisco network equipment, typically over SSH or APIs.
- Playbook
- In Ansible, a YAML file that describes one or more plays, specifying which hosts to target and which tasks (modules) to run on them.
- Provider
- In Terraform, a plugin that implements the logic required to manage resources on a specific platform or service by using that platform's APIs.
- Inventory
- In Ansible, a file that lists managed hosts and organizes them into groups so that playbooks can target them logically.
- Terraform
- An infrastructure as code tool that uses declarative configuration files and providers to create, modify, and destroy resources (including network resources) via APIs, tracking them in a state file.
- Idempotent operation
- An operation that can be applied multiple times without changing the result beyond the initial application, important for safe, repeatable automation.
- Imperative automation
- An automation style where you specify the exact sequence of commands or operations needed to accomplish a task.
- Declarative automation
- An automation style where you describe the desired end state of the system and let the tool determine the necessary changes to reach that state.
- Infrastructure as Code (IaC)
- The practice of defining and managing infrastructure (servers, networks, services) using machine-readable configuration files instead of manual processes or ad-hoc scripts.