Day 45
Ansible & Configuration Management
ansible-configuration-management
At a glance
Focused on Ansible execute; Puppet/Chef/Terraform as compare-and-contrast. Config tools: Ansible (agentless playbooks), Puppet/Chef (agent models), Terraform (declarative infra) — pick based on ops culture. Maps to CCNA v2.0 objective(s) 5.5.
Deep chapter
Long-form companion reading (original prose).
Ansible agentless
Ansible is agentless for network devices: the control node pushes over SSH (or API plugins) without installing a daemon on the switch. Inventories list hosts; modules perform tasks; playbooks order those tasks. Connection plugins and become/enable handling matter on network devices—practice privilege escalation paths.
Agentless means less device software sprawl and easy enablement—if SSH/API is already on, Ansible can talk. Credentials and inventory hygiene become the operational focus. Collections on Galaxy/Automation Hub package modules; pin versions for repeatability.
Network modules (IOS, EOS, etc.) render config or CLI snippets idempotently when well written. Prefer declarative modules over raw `command` when available. F-gas: too many forks can overwhelm device CPUs—tune parallelism for network gear lower than for Linux fleets.
Exam trap: agentless is Ansible’s headline contrast to Puppet/Chef agent models—not “Ansible cannot use APIs.” Agentless still needs reachable management IPs and stable DNS names in inventory.
Playbooks
An Ansible playbook is YAML listing plays: hosts, variables, and tasks. Each task calls a module (`ios_config`, `ios_facts`, …). Handlers, roles, and collections organize larger projects. Roles split reusable NTP/AAA tasks from site playbooks that only pass vars.
Run with `ansible-playbook site.yml`. Check mode (`--check`) estimates changes. Limit (`-l`) scopes hosts. Vault encrypts secrets in vars files. Tags let you run subset tasks (`--tags ntp`) during careful rollouts.
Keep playbooks in Git. Code review ACL changes like application code. Idempotent tasks let you re-run safely after failure mid-batch. `ansible-doc ios_config` style help teaches module parameters faster than blog posts.
Exam trap: a playbook is not a shell script with YAML paint—modules and inventory are the core abstractions. Playbooks that only wrap `command:` everywhere throw away idempotence—refactor when you can.
Puppet agent model
Puppet typically uses an agent on each node that pulls desired state from a Puppet server on a schedule. Manifests describe resources; the agent converges the node. Catalog compiles on the server; agents apply resources and report back status.
Pull model helps at huge scale and when nodes are intermittently connected—they catch up next run. Agents add software footprint and lifecycle work on each node. Certificate signing of agents is part of trust onboarding—ops overhead unique to agent worlds.
For network gear, agent models are less common than SSH/API push tools, but exams still contrast the architecture. Know agent + pull as Puppet’s classic story. Scheduled runs mean drift may exist until the next interval—know your SLO.
Exam trap: Puppet’s agent pull vs Ansible’s push agentless is a standard matching question. Exam stems saying “pull model with agents” point here or to Chef.
Chef glance
Chef also centers on an agent (client) model with cookbooks/recipes describing resources, historically pull-based from a Chef server. Concepts parallel Puppet: desired state, agents, cookbooks vs manifests. Cookbooks bundle recipes, attributes, and templates—parallel to Ansible roles in spirit.
CCNA depth is recognition and comparison, not writing Ruby DSL recipes. Chef appears in “which tool uses agents/cookbooks” style stems. Chef Infra Client runs on the node; workstation/server roles appear in older topologies.
In mixed enterprises, Chef may manage Linux servers while Ansible configures network boxes—tools coexist by domain. Recognize the brand and agent nature; leave deep Ruby to specialists.
Exam trap: Chef ≠ Terraform. Chef converges OS resources; Terraform provisions infrastructure graphs. If a comparison table has a blank for Chef, fill agent + desired state + cookbooks.
Terraform IaC
Terraform is Infrastructure as Code focused on provisioning resources via providers (cloud VPCs, some network controllers) using declarative HCL. A state file tracks what it owns. Providers authenticate to clouds/APIs; resources declare objects; state maps them to real IDs.
`terraform plan` shows the delta; `apply` makes it so. State makes Terraform aware of prior creates so it can update/destroy safely—protect state like production data. Remote state locking prevents two operators from applying divergent graphs.
Terraform shines building/destroying infra graphs; Ansible shines configuring OS/network details. They often combine: Terraform spawns, Ansible configures. Destroy plans are as important as create plans—review before teardown days.
Exam trap: Terraform is not primarily an SSH CLI pusher like Ansible—its model is provider resources + state. Use Terraform for lifecycle of infra objects; use Ansible for deep device config when that split helps.
Push vs pull
Push: control node initiates changes now (Ansible typical). Pull: agents fetch catalogs periodically (Puppet/Chef typical). Both can be scheduled; the initiator differs. Scheduled Ansible (push on a timer) is still push—the control node initiates.
Push gives immediate operator-driven windows. Pull scales when thousands of nodes check in and when you cannot reach into a node freely. Pull can reduce inbound firewall holes to endpoints that only need outbound to the server.
Network devices often favor push/API because installing agents on appliances is awkward. Server fleets historically favored pull agents. Network devices behind jump hosts still usually see push tools via the jumphost.
Exam trap: push vs pull is about who initiates convergence—not about whether the tool is good or bad. Match the model to connectivity and scale constraints named in the stem.
Idempotence
Idempotence (idempotency) means running the same automation repeatedly yields the same end state without stacking duplicate changes. Desired-state tools aim here. Check mode and Terraform plans approximate idempotent intent before mutating.
Example: “ensure NTP servers are A and B” run daily should not append infinite NTP lines. Poor raw CLI `command` tasks often break idempotence; stateful modules do better. Order of tasks can still matter even when each task is idempotent—dependencies exist.
Terraform plans toward declared resources; Ansible modules should check-then-act. Retries and CI re-runs depend on this property. External side effects (ticket APIs, emails) are rarely idempotent—gate them carefully.
Exam trap: idempotent is not “harmless.” Ensuring a package is absent still deletes it once. Say “desired state” in answers when stems ask why re-running is safe.
Exam compare tools
Compare grid: Ansible—agentless, push, YAML playbooks; Puppet—agent, pull, manifests; Chef—agent, cookbooks; Terraform—IaC provisioning, HCL, state. Memorize that grid cold. Redraw the four-tool grid weekly until you can do it blank.
If the stem says “no agent on network devices,” Ansible is the usual answer. If it says “agent pulls catalog,” Puppet/Chef. If it says “plan/apply infrastructure,” Terraform. Watch distractors that mix Terraform state with Puppet catalogs—different worlds.
All can participate in CI. None replaces understanding the network features they configure. “Configure NTP on switches without agents” is a classic Ansible hint.
Exam trap: “best tool” without criteria is a trap. Match the criterion in the stem to the grid. “Provision cloud networks with plan/apply” is a classic Terraform hint.
Lab choose a tool
Lab choice: configure banner/NTP on two IOS devices—pick Ansible for speed to value. Provision a cloud VPC lab—pick Terraform. Leave Puppet/Chef to a Linux VM converge demo if you have time. Write the justification before installing anything—forces criteria-based thinking.
Write one paragraph justifying the choice using agent, push/pull, and IaC vocabulary. That paragraph is exam gold. Limit first Ansible lab to facts + banner; resist boiling the ocean.
Do not install all four tools the same weekend. Depth on one push tool plus conceptual comparison beats shallow installs. For Terraform, use a free-tier cloud or local provider so `plan` is real.
Exam trap: choosing Terraform to “SSH a banner” fights the tool’s strength—use the right hammer. After the lab, update your compare grid with what surprised you.
Inventory
Inventory lists hosts/groups/variables—YAML or INI for Ansible; node classifiers for Puppet; workspaces/state for Terraform addressing. Without inventory, automation has no targets. Child groups inherit vars; use that for `americas` → `amer-access` hierarchies.
Dynamic inventory pulls from CMDB/cloud APIs so you do not hand-maintain every hostname. Static inventory is fine for small labs. Sanitize inventory exports from CMDBs—stale hosts cause noisy failures.
Group by role (`access`, `core`, `wlc`) and attach group vars (NTP, AAA). Host vars override for snowflakes you have not eliminated yet. Terraform workspaces or separate state files segment environments (dev/stage/prod).
Exam trap: inventory is not optional glue—it is a first-class automation artifact like the playbook. Inventory accuracy problems look like “automation is flaky” until you measure reachability.
Secrets glance
Secrets (passwords, API keys, enable secrets) belong in vaults—Ansible Vault, HashiCorp Vault, cloud secret stores—not plaintext in Git. Rotate when people leave. Short-lived credentials from a vault agent beat long-lived embedded passwords.
CI needs secret injection at runtime. Mask logs so playbook output does not print enable passwords. Least privilege service accounts beat shared god logins. Scan repos with automated secret detectors in CI.
Terraform state can contain sensitive values—encrypt state backends and restrict access. Treat state as secret-adjacent. Break-glass passwords stored offline still need rotation after use.
Exam trap: “put secrets in group_vars unencrypted because the repo is private” is still wrong on exam ethics and real ops. State files, log files, and debug mode all leak secrets—review each channel.
Checklist
Tooling checklist: inventory defined, secrets vaulted, idempotent tasks, dry-run/plan reviewed, limited blast radius, Git history clean, rollback known. Pin tool versions (Ansible, providers, collections) on the checklist.
Compare checklist: can you recite agent vs agentless and push vs pull without notes? Can you place Terraform beside Ansible correctly? Include outbound proxy/firewall needs for agents or control nodes.
Safety checklist: pilot group first, monitor diffs, keep OOB access, peer review ACL/playbook changes. Name who approves production applies—tools do not replace change authority.
Exam trap: a green apply with no verification plan is incomplete automation. Verification queries after apply belong beside the apply command in runbooks.
Ops reality
Ops reality: mixed tools, partial coverage, emergency CLI still happens, and culture lags tooling. Celebrate inventory accuracy before fancy AIOps slides. Expect exceptions: one legacy OS that cannot be agents, one appliance with only GUI.
Start with compliance checks and read-only facts collection to earn trust, then graduate to config pushes. Trust is the real deployment gate. Metrics: percent of changes executed via automation this month—track it honestly.
Measure drift: how many devices differ from SoT this week? Automation without drift metrics becomes folklore again. Training time is ops investment; untrained push access is risk.
Exam trap: reality questions still expect the clean architecture answers—state the model, then note hybrids if asked. Reality still maps to the exam grid when someone asks which tool fits next.
Course wrap
Wrap: wireless architectures → security → WLC config, then automation intro → data formats → REST → SDN → config tools. You can explain how a WLAN policy becomes controller intent and how Ansible/REST might push related wired standards. Skim Days 56–62 headings once and ensure you can teach each in two sentences.
Revisit weak flashcards: CAPWAP ports, WPA3 SAE, CRUD verbs, northbound vs southbound, Ansible agentless. Say them aloud once more. Schedule a mixed practice set: one wireless join question, one REST code, one tool compare.
Keep building tiny labs—one API GET, one playbook, one Flex sketch. Small reps lock the final CCNA automation and wireless domain. Keep building—CCNA automation is an on-ramp, not a ceiling.
Exam trap: the wrap is integration, not new protocol trivia. Connect the days; do not memorize isolated logos. Walk into the exam able to connect CAPWAP, RADIUS, JSON, REST, controllers, and Ansible in one story.
Key ideas
- Focused on Ansible execute; Puppet/Chef/Terraform as compare-and-contrast.
- Ansible: SSH/API agentless, YAML playbooks, inventories.
- Puppet/Chef: agents converge toward declared state.
- Terraform: declarative provisioning, state files, clouds/network objects.
- Idempotency and dry-runs reduce blast radius.
- Secrets belong in vaults, not plain repos.
- Network modules wrap device APIs/CLI.
- Exam: match tool → agentless vs agent → playbook vs manifest.
Self-check
- Why is Ansible called agentless?
- Puppet agent role?
- Terraform state purpose?
- Playbook vs ad-hoc command?
- Where should production credentials live?