Ansible

Ansible is a tool for automating the work of setting up and managing servers. Instead of logging into 50 machines by hand to install Nginx, edit a config file, and restart a service, you write down those steps once in a file and Ansible carries them out on all 50 machines for you.

It was created by Michael DeHaan in 2012 and acquired by Red Hat in 2015. Its biggest distinguishing feature is that it is agentless. Tools like Puppet and Chef require a running daemon installed on every managed machine. Ansible needs nothing on the target except an SSH server and Python, both of which almost every Linux box already has. The control node, your laptop or a CI runner, pushes instructions out over SSH.

You describe the desired end state in YAML, not the steps to get there. You say the package nginx should be present and the service nginx should be running. Ansible figures out whether it needs to act. This property is called idempotency: running the same playbook five times produces the same result as running it once, and tasks that are already in the right state are reported as ok rather than changed.

The three core pieces are the inventory, modules, and playbooks. The inventory is a list of the hosts Ansible manages, grouped into named sets like webservers or databases. It can be a static INI or YAML file, or generated dynamically by querying AWS, GCP, or Azure for the live list of machines.

Modules are the small programs that do the actual work, one per task type. The apt module installs Debian packages, the copy module pushes files, the service module starts and stops daemons, the user module manages accounts. There are thousands of them. When a play runs, Ansible copies the relevant module to the target over SSH, executes it there, captures the JSON result, and deletes the module file. Nothing is left behind.

A playbook ties it together. It is a YAML file containing one or more plays, and each play maps a group of hosts to an ordered list of tasks. Reusable bundles of tasks, files, and variables are packaged as roles, and the public Ansible Galaxy registry hosts thousands of community roles you can pull in. Ansible runs tasks across many hosts in parallel, five at a time by default, controlled by the forks setting.

Reach for Ansible when you need configuration management (keeping a fleet of servers in a known state), application deployment (rolling new code out across tiers in order), or one-off orchestration (run a database migration, then restart the app servers, then clear the cache). It shines for managing existing servers and network gear, and for gluing together steps across many machines.

The trade-offs are real. Because it pushes over SSH and copies Python to each host, Ansible is slower than agent-based tools on very large fleets of thousands of nodes, though strategies like free mode and mitogen help. There is no constantly running agent enforcing state, so drift between runs is not auto-corrected; you have to re-run the playbook on a schedule or via a controller like AWX or Red Hat Ansible Automation Platform.

It is also worth knowing where Ansible stops and Terraform begins. Terraform provisions infrastructure (it creates the VMs, networks, and load balancers and tracks them in state). Ansible configures what runs inside those machines. Many teams use Terraform to build the servers and Ansible to set them up, and the two are complementary rather than competing.

Say you run three web servers behind a load balancer and need to deploy a new release with zero downtime. You write a playbook with a play targeting the webservers group. The serial keyword set to 1 tells Ansible to handle one server at a time instead of all three at once.

For each server, the tasks remove it from the load balancer pool, pull the new code with the git module, run any database-safe migrations, restart the app service using the systemd module, wait for a health check URL to return 200 with the uri module, then add the server back to the pool. Ansible moves to the next server only after the current one is healthy.

If the health check fails on server two, the play aborts and servers one and three are untouched, so you never take the whole fleet down. Run the same playbook a second time on already-updated servers and the package, file, and service tasks report ok with no changes, because the desired state already matches.