Ansible
Also known as: Ansible playbook, Red Hat Ansible, AWX, Ansible Tower
Ansible automates repetitive IT tasks -- configuring servers, deploying applications, managing packages -- using simple YAML files called playbooks.
It's agentless (no software needs to be installed on the servers being managed) and connects over SSH, making it easier to adopt than competing tools.
Ansible, explained at three levels
At home
Ansible lets you write a list of tasks ('install Nginx', 'copy this config file', 'start the service') and then run them automatically across any number of servers. Instead of SSH-ing into each server and doing it manually, Ansible does it all at once.
At work
IT and DevOps teams use Ansible to keep servers consistently configured. Instead of 'we think server A has the right settings', Ansible's playbooks define exactly how every server should be configured and can enforce that state on demand.
At home
Ansible's core concepts: Inventory (list of servers to manage), Playbooks (YAML files with ordered tasks), Roles (reusable groups of tasks and templates), Modules (built-in tasks for managing packages, files, services, AWS resources, etc.), and Variables for parameterizing playbooks. Ansible connects via SSH and runs commands remotely -- no agent required on managed nodes.
At work
Teams use Ansible for: post-provisioning server configuration (install packages, set up users, apply hardening), application deployment (pull code, run migrations, restart services), compliance enforcement (ensure audit rules are in place), and orchestrating rolling updates across server groups without downtime.
At home
Ansible's execution model is push-based: the control node SSHes into managed nodes and runs tasks sequentially per host (or in parallel with forks). Tasks are idempotent by design -- running a playbook twice should produce the same result as running it once. The check mode ('--check') performs a dry run showing what would change.
At work
Ansible Tower (now Red Hat Ansible Automation Platform) adds a web UI, RBAC, credentials management, scheduling, and audit logging to Ansible. AWX is the upstream open-source version. For large fleets, dynamic inventories pull server lists from AWS, Azure, or GCP APIs rather than static files. Ansible Galaxy is the community hub for sharing roles and collections.
Real-world examples
At home
Sophie wrote an Ansible playbook to set up her home lab servers consistently. One command installs and configures Docker, sets up her monitoring stack, and creates the user accounts she needs -- reproducible in minutes on any fresh Linux server.
At work
Thomas's team uses Ansible to enforce security baseline configuration on 500 production servers. A CI/CD pipeline runs the playbook in check mode to detect drift, and applies it nightly to correct any deviations from the defined state.
Common confusions
- Ansible and Terraform do the same thing — Terraform provisions infrastructure (create a server, set up a network). Ansible configures that infrastructure (install software, set up users). They're complementary: Terraform creates the server, Ansible configures it.
- Ansible is only for Linux servers — Ansible manages Windows (via WinRM), network devices (Cisco, Juniper), cloud APIs (AWS, Azure), and containers. The module ecosystem covers most infrastructure types.
For analysts
Operations teams use Ansible to automate data pipeline server maintenance -- scheduled playbooks can apply security patches, rotate credentials, or restart services during maintenance windows without manual intervention.
History & origin
Ansible was created by Michael DeHaan and released in 2012 with a focus on simplicity -- it should work without installing agents or learning a programming language. Red Hat acquired Ansible in 2015 for $150 million, integrating it into the Red Hat Enterprise Linux ecosystem. Ansible remains one of the most popular infrastructure automation tools alongside Terraform (infrastructure provisioning) and Puppet/Chef (configuration management).