Ansible Explained
Ansible is an agentless configuration management and automation tool that uses SSH to configure servers, deploy applications, and orchestrate multi-step workflows. You describe the desired state of your infrastructure in YAML playbooks, and Ansible ensures the servers match that state.
Why Ansible?
Ansible's key differentiator is that it is agentless — it connects to servers over SSH (or WinRM for Windows) and requires no software to be installed on managed nodes. This makes it easy to adopt: if you can SSH to a server, Ansible can manage it. The configuration language is YAML, which is readable by anyone, not just developers. Convert between configuration formats with the JSON to YAML Converter.
Inventory
The inventory defines which servers Ansible manages. It can be a simple INI or YAML file:
[webservers]
web1.example.com
web2.example.com
[databases]
db1.example.com
Dynamic inventories can pull server lists from cloud providers (AWS, GCP, Azure) automatically. Groups let you target specific sets of servers in your playbooks.
Playbooks
Playbooks are YAML files that describe the desired state:
- hosts: webservers
become: yes
tasks:
- name: Install nginx
apt:
name: nginx
state: present
- name: Start nginx
service:
name: nginx
state: started
enabled: yes
Each task uses a module (apt, service, copy, template) to manage a specific resource. Playbooks are run with ansible-playbook playbook.yml.
Idempotency
Ansible modules are idempotent — running a playbook twice produces the same result as running it once. If nginx is already installed, the apt module does nothing. If the service is already running, the service module does nothing. This makes playbooks safe to run repeatedly, which is essential for configuration drift management.
Modules and Collections
Ansible ships with thousands of modules covering package management, file operations, user management, cloud provisioning, network configuration, and more. Collections (introduced in Ansible 2.9) are curated sets of modules, roles, and plugins distributed via Ansible Galaxy. The ecosystem covers almost every platform and service you might need to manage. Validate JSON configuration files that Ansible might template with the JSON Formatter.
Roles
Roles are reusable units of Ansible content with a standardised directory structure: tasks/, handlers/, templates/, defaults/, vars/, and files/. A role encapsulates everything needed to configure a specific piece of infrastructure (e.g., a role for nginx, a role for PostgreSQL). Ansible Galaxy hosts thousands of community roles.
Ansible vs Puppet vs Chef
Puppet and Chef use agents and a pull model — nodes periodically check in with a central server. Ansible uses SSH and a push model — you run a playbook and it configures nodes immediately. Puppet and Chef use their own DSLs (Puppet's declarative language, Chef's Ruby-based recipes). Ansible uses YAML, which has a lower learning curve. For large-scale continuous configuration enforcement, Puppet's pull model has advantages; for ad-hoc automation and simpler environments, Ansible's push model is easier to start with. Use the Crontab Calculator to schedule regular Ansible runs via cron.
Best Practices
Use roles for reusable configurations. Keep secrets in Ansible Vault (encrypted). Use --check mode (dry run) before applying changes to production. Tag tasks for selective execution. Use group_vars and host_vars for environment-specific configuration. Test playbooks with Molecule or in a staging environment before production.