openskills.info
Course catalog
Ansible Fundamentals logoCourse Preview

Ansible Fundamentals

Ansible is an agentless automation tool that configures systems, deploys software, and orchestrates multi-step tasks over SSH or WinRM. You describe desired state in YAML playbooks, and Ansible pushes the necessary changes to target machines without requiring a resident agent.

itInfrastructure and operations

Don't Panic — Ansible Fundamentals

Nothing called Ansible runs on the machines Ansible manages. There is a control node with the tooling on it, a list naming what to talk to, and a connection — SSH mostly, PowerShell remoting for Windows — down which code is pushed, executed and reported on.

Most of the tool's character follows: nothing to install across a fleet, nothing to keep alive, and equally nothing watching in between runs.

The second thing worth internalising is what a task is. A shell script says what to execute. A task says what ought to be true — this package present, this service running, this file with these contents — and the module doing the work checks the current state before acting, so a second run over an already-correct machine reports nothing done.

That property is idempotency: running the same thing twice leaves the same result, which is what makes repetition safe rather than a gamble. It belongs to individual modules, not to the tool as a whole. Reach for command or shell, which run something and check nothing, and it has quietly been opted out of.

The shape underneath is a pipeline. What the inventory matches is the blast radius, which is why it gets inspected before anything else. A play attaches an ordered task list to a group of hosts, each task hands work to a module, and each module answers ok, changed or failed.

Those answers are what later work keys off — chiefly handlers, tasks that fire only because something upstream genuinely changed. Deploy an identical config and the restart never happens: either elegant, or precisely why a service failed to restart.

Three things nobody says early enough. There is no transaction anywhere in this. A run across two hundred machines ends with a hundred and ninety changed, seven unreachable and three failed, and nothing rolls back the hundred and ninety.

The fleet is now in mixed condition and the next run starts from there, so the design question for any playbook is what it looks like stopped halfway. Read the unreachable column of the summary first: it counts machines the automation has silently stopped describing.

Second, changed is the only signal the tool emits, and it is spendable. A playbook reporting a change on every run carries no information, a genuine surprise hides in it perfectly, and within weeks nobody reads the summary.

Third, the wall is runtime rather than syntax. By default only five machines are worked on at once, and the default strategy waits for all five to finish a task before starting the next, so the slowest in each batch sets the pace — and collecting facts about every machine charges for that before the first real task runs. Raising the parallelism, reusing connections and caching those facts are the levers. The shipped defaults assume a laptop.

One more, because it otherwise costs an afternoon: a variable can be set in twenty-two places with a defined override order, which is why "where did this value come from" stops being answerable by reading. Define each in one place.

Commands and the safe-run sequence are on the Cheatsheet, the model is set out in full in the Intro, and Field Notes has the one ratio worth tracking.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources