What Ansible is, and why it changes how operations work

Conversations about infrastructure automation almost always start from the same place: an engineer has accumulated a collection of bash scripts, each one works, and each one is dangerous. Dangerous not because it is badly written, but because a script describes steps, not an outcome. Run it a second time and it repeats those steps on a system where they have already been applied, and the result stops being predictable.

Ansible is built on exactly that distinction. You do not describe what to do; you describe what the system should look like. The rest — inspecting, comparing against the current state, and applying only the difference — is the tool's job.

Four concepts that explain the whole thing#

Inventory — the list of devices and servers, arranged into groups. A group might be "core routers", "access switches", "VPS in Amsterdam". Variables attach to a group or to an individual host.

Playbook — a YAML file saying which state should hold for which group. This is the file that lives in version control and goes through code review like any other code.

Module — the thing that performs one action: install a package, place a file, start a service, add a configuration line on a router. The module itself decides whether a change is needed.

Role — a reusable unit of playbooks, variables and templates. "Our standard Linux host" is one role, applied identically across fifty servers.

Idempotency — the one property that actually matters#

If you remember a single term, make it this one. An idempotent operation produces the same result whether you run it once or fifty times.

In practice it looks like this: the playbook says "this interface should have MTU 9000". The first run changes the configuration and reports changed. The second run inspects it, sees the MTU is already 9000, changes nothing and reports ok. The third run, and the hundredth, do the same.

Two consequences follow, and they are what changes how operations work:

• Running a playbook stops being a risky act. It can go on a schedule, daily, with no ceremony around it.
• --check mode becomes a real instrument. It changes nothing but tells you what would change. That is the cheapest configuration-drift detector there is: if a run that should change nothing promises thirty changes, somebody edited something by hand.

Why being agentless is decisive#

Ansible is agentless: nothing is installed on the managed device. It connects over SSH (on network hardware, often NETCONF or the vendor's API), runs the task, and closes the connection.

In the server world that is a convenience. On network hardware it is frequently the only option — there is nowhere to install your agent on a router or a switch. That is why Ansible is one of the few tools that reaches a Linux host and a MikroTik, Juniper or Cisco device through the same logic.

The other side of it: because there is no agent, there is no continuous monitoring either. Ansible acts at the moment you run it. Between two runs the system can drift into any state at all, and Ansible will not tell you.

Automation on a schedule#

Putting playbooks on a schedule is the answer to precisely that gap. A playbook run once cannot catch configuration drift; a playbook standing on a schedule can.

enlarge

Semaphore, in this frame, is a layer on top of Ansible, and it solves three practical problems that a bare ansible-playbook command has:

• Scheduling — a cron expression per job, each one enabled or disabled on its own.
• Access and secrets — SSH keys live in a central key store rather than on an engineer's laptop, and who may run which inventory is decided by role.
• History — every run leaves a log. "When did this last run, and what did it say" is the same class of question as "which configuration was in place on Tuesday".

Where Ansible stops#

An honest answer here is more useful than a list of what it can do:

• It is not a monitoring system. Ansible says "I applied the state"; it does not tell you how the service is behaving now. That belongs to Zabbix, LibreNMS or Prometheus.
• It is not a CMDB. The inventory is what you wrote down, not what is actually on the network. Discovery is a separate problem.
• The push model is slow at scale. Sequential SSH connections across thousands of hosts are felt; forks, pipelining and splitting into groups stop being optional.
• YAML becomes code. A large set of playbooks acquires every problem code has — duplication, a need for tests, refactoring. ansible-lint and a decomposition into roles are no longer a matter of taste.

How we use it#

Ansible sits in three places here: applying a standard configuration to new hosts, recurring checks on a schedule (latency, DNS, service state), and rolling out a change across a group of devices when the same change has to land in many places.

Collecting configurations and keeping them versioned is a separate tool's job — it gathers RouterOS, JunOS, IOS and EOS configurations daily and keeps them in git. The two complement each other: Ansible changes the state, and the archive remembers what that state was before the change.