How does Ansible work without agents, and what are playbooks and inventory?

Think of Ansible like a restaurant manager who walks to each station and gives verbal instructions to cooks, rather than installing an intercom system at every station. The manager (Ansible control node) simply walks over (SSH), tells the cook (managed node) what to do, checks the result, and moves on. No permanent communication system needs to be set up at each station.

At its core, Ansible uses a push-based approach where no software agent is needed on the target machines. The control node is where Ansible is installed and where all automation is kicked off. When you run a playbook, Ansible reads the inventory file to find out which hosts to target, opens SSH connections to those hosts, copies small Python scripts to the remote machines, runs them, grabs the output, and then cleans up the temporary files. This whole cycle happens for each task in the playbook, either one at a time or in parallel depending on how many forks you configure.

Under the hood, Ansible uses a component called the connection plugin to manage SSH sessions. The default plugin uses OpenSSH with ControlPersist, which keeps SSH connections alive across multiple tasks so it does not have to reconnect for every single task. The inventory can be a simple INI or YAML file listing hosts and groups, or it can be a dynamic script that queries cloud APIs like AWS or Azure. Playbooks are YAML files that define a series of plays, where each play maps a group of hosts to a set of tasks. Each task calls a module -- such as apt, copy, template, or service -- that performs a specific action on the remote machine.

In production, Ansible is usually run from a central server or a CI/CD pipeline. Organizations use Ansible Tower or AWX (the open-source version of Tower) to add a web interface, role-based access control, job scheduling, and audit logging. The inventory is typically dynamic, pulling host information from cloud providers like AWS, Azure, or GCP. Playbooks live in version-controlled repositories and run as part of deployment pipelines. SSH keys are managed centrally, and sudo-based privilege escalation is configured for tasks that need root access.

A common mistake is assuming Ansible leaves zero footprint on managed nodes. While it does not install a persistent agent, it does need Python on the target machine for most modules (the raw and script modules are exceptions). Another pitfall is SSH connection limits -- running against hundreds of hosts at once can use up file descriptors or trigger rate limiting on bastion hosts. You also need to be careful with the forks setting and the serial keyword to avoid overwhelming your infrastructure during rolling deployments.