Configuration Management and Infrastructure as Code

Everything you have configured in this course so far, you configured one device at a time: open a session, type the commands, verify, move on. That works for the four routers in a lab. It does not work for fifty. Setting one Network Time Protocol (NTP) server on fifty routers by hand is fifty sessions, fifty chances to mistype, and no record afterwards of who changed what or how to put it back.

Worse than the typing is what happens next. Someone fixes an outage at 2 a.m. and leaves a temporary command in place. A switch is replaced and its replacement is configured from memory. A push fails on three devices out of fifty and nobody notices. Slowly, devices that are supposed to be identical stop being identical. That divergence between what a device is actually running and what it is supposed to be running is called configuration drift, and its defining feature is that nothing announces it. You discover it when two supposedly identical switches behave differently.

Configuration management is the practice of defining a device's intended configuration in a file, storing that file the way software is stored — in version control, reviewed, diffable, revertible — and having a tool apply it repeatedly. Infrastructure as code (IaC) is the same idea taken one step further out: not just the configuration of devices that already exist, but the existence of the infrastructure itself, declared in files and built from them.

Before any tool names, learn the four vocabulary items every one of these tools shares. Questions about Ansible and Terraform are usually really questions about these.

Desired state is the first. Instead of describing the steps to take, you describe the condition you want to be true — "NTP server 10.0.0.1 is configured on every core router". The tool inspects the device, compares it to that statement, and works out for itself what, if anything, to change.

Declarative versus imperative is the second, and it is the same distinction named more formally. A declarative definition states the end state and leaves the route there to the tool. An imperative — also called procedural — definition states the sequence of operations: do this, then this, then this. A shell script that logs into a router and types commands in order is imperative. A file that says "this line should be present" is declarative. Terraform is fully declarative: you never order its resources, and it works out the dependency order itself. Ansible sits slightly to the imperative side of that line — each task declares a desired state, but the tasks in a play run top to bottom in the order you wrote them.

Idempotency is the third, and it is what makes declarative automation safe to re-run. An operation is idempotent when applying it twice leaves the same end state as applying it once. Run the automation on a device that already matches, and the tool changes nothing and reports "ok" or "unchanged". That is why these tools can be run on a schedule against production: a run that finds nothing to fix does nothing.

Configuration drift is the fourth, defined above. Idempotent automation is also the cure for it: because a re-run is harmless when nothing has changed, you can re-run continuously, and any device that has drifted is quietly pulled back to the declared state. A tool that reports what it would change without changing it — Ansible's check mode, Terraform's plan — turns the same mechanism into a drift detector.

Two independent questions separate the tools, and the exam likes both. The first: does the managed device need extra software installed on it? A tool is agent-based when a piece of its own software — an agent — must be installed and running on every managed device. It is agentless when it does not, connecting instead over something the device already speaks: Secure Shell (SSH) on TCP 22, or a network management interface such as NETCONF on TCP 830 or RESTCONF over HTTPS.

The second: who starts the conversation? In a push model, a central control node initiates the connection and sends configuration out to the devices, when an operator or a pipeline says so. In a pull model, the agent on each device wakes up on a timer, contacts the central server, downloads its intended configuration, and applies it locally. Pull is self-healing by design — a drifted device is corrected at its next check-in without anyone asking — at the cost of needing that agent everywhere.

The current CCNA 200-301 v1.1 blueprint names Ansible and Terraform. Puppet and Chef were named in the previous revision and are still worth recognising, because they are the agent-based, pull-model contrast that makes Ansible's model meaningful. Know them at name-and-model depth; you will not be asked to write a Puppet manifest or a Chef recipe.

Read that table by column rather than by row and the shape of the exam question appears. Ansible and Terraform are agentless and push; Puppet and Chef are agent-based and pull. Terraform is the only one of the four that keeps a persistent state file. Ansible is the only one whose files are plain YAML.

Ansible runs from a control node — a machine with Ansible installed, which may be an engineer's laptop or a build server. It needs to know which devices it manages, and that list is the inventory: hosts, arranged into named groups, optionally with variables attached to a host or to a group. Referring to a group by name in a playbook is how one file targets forty switches.

all:
  children:
    routers:
      hosts:
        r1.campus.example:
        r2.campus.example:
      vars:
        ntp_server: 10.0.0.1

A playbook is the file describing what should be true. It contains one or more plays; a play targets a group from the inventory and contains a list of tasks; each task calls a module, which is the unit of code that knows how to inspect a device and bring one thing into the desired state idempotently. `cisco.ios.ios_config` is a module. So is `user`, and `file`, and several thousand others.

# site.yml — ensure NTP is configured on every router in the inventory
- name: Configure NTP on core routers      # a play
  hosts: routers                            # a group from the inventory
  gather_facts: false
  tasks:
    - name: Add NTP server                  # a task
      cisco.ios.ios_config:                 # the module that does the work
        lines:
          - ntp server 10.0.0.1             # the line that should be present

Run that today and the line is added. Run it again tomorrow and Ansible reports ok with no change, because the module checks before it writes. That is idempotency in practice, and it is why the same playbook can safely run nightly.

A template is the last piece, and it is what stops one playbook per device. A template is a configuration file containing placeholders instead of literal values; the tool fills those placeholders from variables at run time to produce the finished configuration for each device. Ansible uses the Jinja2 templating language for this, and template files conventionally end in `.j2`. One template plus per-host variables from the inventory produces forty correct, individual configurations from one reviewed source file.

# banner.j2 — the template
hostname {{ inventory_hostname }}
ntp server {{ ntp_server }}

# rendered for r1.campus.example
hostname r1.campus.example
ntp server 10.0.0.1

Terraform, from HashiCorp, is the infrastructure-as-code tool of the pair. You write HCL — HashiCorp Configuration Language — declaring the resources that should exist. You never write the order in which to build them; Terraform reads the references between resources, builds a dependency graph, and works the order out.

# main.tf
resource "example_network" "campus" {
  name = "campus-core"
  cidr = "10.10.0.0/16"
}

The state file is what makes Terraform different from everything else in this lesson. It is a record Terraform keeps of the resources it has actually built and their current known properties. On every run, Terraform compares three things: your declaration, the state file, and reality as reported by the platform's API. From that comparison it produces a plan — the precise list of resources to add, change, or destroy in order to converge. `terraform plan` shows you that list and changes nothing; `terraform apply` carries it out.

terraform plan     # show the difference between declaration, state file, and reality
terraform apply    # converge: create, update, or destroy to match the declaration

That three-way comparison is also Terraform's drift detection. If someone changes a managed resource by hand, the next plan shows it as a difference from the declaration, and the next apply corrects it. Because the state file records what already exists, Terraform can also tell the difference between "build this" and "this is already built", which is what stops it recreating infrastructure on every run.

• Configuration management and infrastructure as code replace box-by-box CLI with reviewed, version-controlled, repeatable files.
• Configuration drift is the silent divergence of a device from its intended configuration; idempotent automation both detects and corrects it.
• Declarative states the end condition and lets the tool find the route; imperative (procedural) states the sequence of steps.
• Idempotency means a second run changes nothing — which is what makes running automation on a schedule safe.
• Ansible: agentless, push, YAML playbooks over SSH or a network API, driven by an inventory, using modules and Jinja2 templates. No state file.
• Terraform: agentless, push, declarative HCL, keeps a state file, converges with plan then apply, detects drift from that state.
• Puppet and Chef: agent-based and pull. An agent on each device checks in with a central server and applies its configuration locally.
• Recognition tells: YAML is key: value with hyphenated lists; HCL is braces with equals signs.