Managing a handful of servers by hand is fine. Managing fifty, or five hundred, with SSH and bash scripts gets old fast. Ansible turns infrastructure work into repeatable, version-controlled code that runs the same way every time. No agents to install, no master server to babysit, no proprietary language to learn.
This page is a structured learning path. Whether you’re writing your first playbook or building production-grade automation across hundreds of nodes, every topic links to a focused, tested guide. Start from the top if you’re new, or jump to the section that matches where you are. Each linked article has been tested on real systems with real output, not theoretical examples.
Updated April 2026 for ansible-core 2.16.14 (package manager) and ansible 13.5.0 (pip). All linked guides tested on Rocky Linux 10.1 and Ubuntu 24.04.
What Makes Ansible Different
Ansible connects to your servers over SSH, runs tasks, and disconnects. No daemon running on managed nodes, no database tracking state, no PKI infrastructure to maintain. If you can SSH into a box, Ansible can manage it.
Playbooks are written in YAML. That’s a deliberate choice. A junior sysadmin can read a playbook and understand what it does without learning a DSL. Compare that to Puppet manifests or Chef recipes, which require understanding Ruby-based syntax before you can be productive.
Every Ansible module is idempotent by design. Run a playbook once or ten times, the result is the same. The apt module doesn’t reinstall a package that’s already present. The lineinfile module doesn’t duplicate entries. This means you can run playbooks as a form of drift detection: if nothing changes, your systems match your code.
The module library covers nearly everything: package management, file manipulation, user accounts, firewall rules, cloud provisioning, container orchestration, network devices. For a side-by-side breakdown against Chef, Puppet, and SaltStack, see our infrastructure automation tools comparison.
Getting Started
These guides cover the fundamentals. Work through them in order if you’re new to Ansible, or pick the ones you need if you already have some experience. Each one builds on concepts from the previous articles.
Install Ansible
Before anything else, you need a working Ansible installation on your control node. The control node is the machine you run playbooks from (your laptop, a jump box, a CI runner). Managed nodes only need Python and SSH.
On Rocky Linux 10, ansible-core 2.16.14 is available directly from the package manager. For the latest features (ansible 13.5.0 with ansible-core 2.20.4), install via pip with Python 3.12.
ansible --versionA working installation shows the core version, config file path, and Python interpreter:
ansible [core 2.16.14]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/root/.ansible/plugins/modules']
ansible python module location = /usr/lib/python3.12/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.12.8Full installation walkthrough for multiple distros and methods:
- RHEL family – Install Ansible on Rocky Linux and Ubuntu
- Debian – Install Ansible on Debian
- General Linux – Install and Configure Ansible on Linux
Ad-Hoc Commands
Ad-hoc commands let you run one-off tasks across your inventory without writing a playbook. Restarting a service on 20 servers, checking disk space everywhere, copying a file to a group of hosts. Think of them as Ansible’s equivalent of a quick SSH loop, but with module-level intelligence and parallel execution.
ansible webservers -m service -a "name=nginx state=restarted"That single command restarts Nginx on every host in the webservers group, in parallel, with proper service management (not a raw kill and start).
Full guide: Ansible Ad-Hoc Commands
Inventory Management
The inventory file tells Ansible which servers exist and how to group them. A simple INI file works for small environments. As you scale, you’ll move to YAML inventories, group variables, and eventually dynamic inventories that pull from cloud APIs.
Getting inventory structure right early saves significant refactoring later. A well-organized inventory with logical groups (webservers, databases, staging, production) makes playbooks cleaner and limits the blast radius of mistakes.
Full guide: Ansible Inventory Management
Your First Playbook
Playbooks are where Ansible becomes powerful. A playbook is a YAML file describing the desired state of your systems: packages installed, services running, config files in place, firewall rules applied. You declare what should be true, and Ansible figures out the steps to get there.
A playbook that installs and configures Nginx with a custom virtual host might look like this:
---
- name: Configure web servers
hosts: webservers
become: true
tasks:
- name: Install Nginx
ansible.builtin.dnf:
name: nginx
state: present
- name: Deploy virtual host config
ansible.builtin.template:
src: templates/vhost.conf.j2
dest: /etc/nginx/conf.d/app.conf
notify: Restart Nginx
handlers:
- name: Restart Nginx
ansible.builtin.service:
name: nginx
state: restartedEven without Ansible experience, you can read that and understand what it does. That readability is one of Ansible’s strongest selling points.
Full guide: Ansible Playbook Tutorial
Variables and Facts
Variables make playbooks reusable. Instead of hardcoding package names, paths, and port numbers, you define them as variables and override per host, per group, or per environment. Ansible also gathers “facts” automatically: OS family, IP addresses, memory, disk layout. You can use these facts in conditionals and templates to write playbooks that adapt to each server’s characteristics.
Conditionals and Loops
Not every task should run on every host. The when keyword lets you skip tasks based on facts, variables, or the results of previous tasks. Install httpd on RHEL, apache2 on Debian. Open port 443 only if SSL is enabled. Loops let you iterate over lists of packages, users, or configuration items without duplicating task definitions.
Handlers
Handlers solve a common problem: you only want to restart a service when its configuration actually changed. If you update nginx.conf and nothing is different from what’s already on disk, Ansible skips the task and the handler never fires. This prevents unnecessary service restarts during routine playbook runs.
Jinja2 Templating
Templates turn static config files into dynamic ones. A single nginx.conf.j2 template can generate different configurations for each server based on variables: different worker counts based on CPU cores, different upstream blocks for each environment, different SSL certificate paths. Jinja2 is the same templating engine used by Flask and Django, so the syntax is well-documented and widely understood.
Ansible Roles
Roles bring structure to complex automation. Instead of one massive playbook with 200 tasks, you organize related tasks, templates, variables, and handlers into self-contained roles. A nginx role, a postgresql role, a security_baseline role. Each can be developed, tested, and reused independently. Ansible Galaxy hosts thousands of community roles you can use as starting points.
Full guide: Ansible Roles Tutorial
Debugging Playbooks
When a playbook fails (and it will), you need to know how to investigate. The debug module prints variable values during execution. Increasing verbosity with -v, -vv, or -vvv shows connection details, module arguments, and raw responses. The --check flag does a dry run. The --diff flag shows what would change in files. Mastering these tools turns a 30-minute debugging session into a 2-minute one.
Intermediate Skills
Once you’re comfortable writing playbooks and roles, these topics take your automation to the next level. This is where Ansible stops being “a better SSH loop” and becomes a real configuration management platform.
Ansible Vault
Vault encrypts sensitive data (passwords, API keys, certificates) so you can commit them to version control safely. No more passing secrets via environment variables or keeping them in plaintext files outside the repo. Vault integrates directly into playbooks, so encrypted variables are decrypted at runtime without extra tooling.
Reference: Ansible Vault Cheat Sheet and Reference Guide
Dynamic Inventory
Static inventory files don’t work when your infrastructure is elastic. In AWS, GCP, or OpenStack, servers come and go. Dynamic inventory scripts query your cloud provider’s API and build the inventory at runtime. Ansible includes inventory plugins for all major cloud platforms, VMware, and container orchestrators.
Collections
Collections are Ansible’s packaging format for distributing modules, roles, and plugins together. Since Ansible 2.10, most modules live in collections rather than the core package. You install them with ansible-galaxy collection install and reference modules by their fully qualified name (like ansible.builtin.copy or community.postgresql.postgresql_db). Understanding collections is essential for working with current Ansible versions.
Molecule Testing
Molecule provides a framework for testing Ansible roles in isolation. It spins up containers or VMs, runs your role, then runs verification tests (usually with Testinfra or Ansible itself). Catching bugs in a disposable container is far better than discovering them on production servers at 2 AM. Molecule integrates with CI/CD pipelines so every commit to a role triggers automated testing.
Filters and Data Manipulation
Jinja2 filters transform data within playbooks. Parse JSON output from API calls, extract specific fields from complex data structures, format strings, calculate values, manipulate IP addresses. Filters like json_query, regex_replace, ipaddr, and combine are used constantly in production playbooks. Learning the common filters saves you from writing custom modules for simple data transformations.
Error Handling and Recovery
Production playbooks need to handle failures gracefully. The block/rescue/always pattern lets you try a set of tasks, catch failures, and run cleanup regardless of outcome. The ignore_errors directive, failed_when conditions, and retries with until loops give you fine-grained control over how failures are handled. The difference between a playbook that works in the lab and one that survives production is usually error handling.
Docker with Ansible
Ansible manages Docker containers, images, networks, and volumes through the community.docker collection. Build images, deploy containers with specific configurations, manage Docker Compose stacks, and orchestrate multi-container applications. This is particularly useful when you need to manage Docker across a fleet of hosts, not just a single development machine.
Full guide: Manage Docker Containers with Ansible
Ansible Cheat Sheet
A compact reference covering every common command, module pattern, and playbook keyword. Keep it open in a tab while working. It covers ad-hoc syntax, playbook structure, vault commands, Galaxy usage, and debugging flags in a scannable format.
Full reference: Ansible Cheat Sheet
Advanced Topics
These topics are for engineers running Ansible at scale or integrating it into complex workflows. If you’re automating across hundreds of hosts, building custom modules, or implementing zero-downtime deployments, this section covers what you need.
Event-Driven Ansible
Event-Driven Ansible (EDA) reacts to events from monitoring tools, webhooks, or message queues and triggers playbook runs automatically. A Prometheus alert fires, EDA catches it, runs a remediation playbook. A new VM comes online, EDA detects it and applies the baseline configuration. This shifts Ansible from “push on demand” to “respond in real time.”
Custom Modules
When the 6,000+ existing modules don’t cover your use case, you write your own. Custom modules are Python scripts that follow Ansible’s module interface. They receive arguments as JSON, perform work, and return structured results. If you’re managing in-house applications or proprietary hardware, custom modules give you first-class Ansible integration instead of relying on shell and command tasks.
Zero-Downtime Deployments
Rolling updates, canary deployments, blue-green switches. Ansible’s serial keyword controls how many hosts are updated simultaneously. Combined with load balancer drain commands and health check verification, you can deploy application updates across a cluster without dropping a single request. The strategy depends on your architecture, but Ansible provides the building blocks.
Compliance Scanning
Ansible can enforce compliance policies across your fleet. CIS benchmarks, STIGs, PCI-DSS requirements. Write playbooks that check (and optionally remediate) compliance settings: password policies, SSH hardening, filesystem permissions, audit logging. The --check mode generates reports without making changes, which is exactly what auditors want to see.
Scaling Ansible
Managing 10 servers and managing 10,000 servers requires different approaches. Connection plugins, SSH pipelining, mitogen for faster execution, fact caching with Redis, pull-mode with ansible-pull, and AWX/AAP for centralized management with RBAC and scheduling. Understanding these scaling strategies is the difference between a 5-minute playbook run and a 5-hour one.
Kubernetes with Ansible
The kubernetes.core collection lets Ansible manage Kubernetes resources: deployments, services, configmaps, secrets, namespaces. This fills the gap between Terraform (which provisions the cluster) and Helm (which packages applications). Ansible can bootstrap a cluster, deploy applications, and configure cluster-level settings in a single workflow.
Performance Tuning
Default Ansible settings are conservative. Bumping forks from 5 to 50, enabling SSH pipelining, using gather_facts: false when you don’t need facts, switching to the free strategy, and caching facts between runs can dramatically reduce execution time. For large inventories, these optimizations compound.
Integration Guides
Ansible rarely works alone. These guides show how to connect it with other tools in your stack, from infrastructure provisioning to monitoring to CI/CD pipelines.
Terraform + Ansible
Terraform provisions infrastructure (VMs, networks, load balancers), then hands off to Ansible for configuration management. Terraform creates the servers, Ansible makes them useful. This combination is one of the most common patterns in modern infrastructure automation, and getting the handoff right (dynamic inventory from Terraform state, or provisioner integration) determines how smooth the workflow is.
Full guide: Terraform and Ansible Tutorial
Ansible + Proxmox
The community.general.proxmox modules let Ansible create, clone, start, stop, and configure Proxmox VMs and containers. Useful for homelab automation, development environments, and private cloud setups where Proxmox is the hypervisor. Guide coming soon.
Ansible + Windows Server
Ansible manages Windows servers over WinRM instead of SSH. The ansible.windows collection provides modules for IIS, Active Directory, Windows features, registry, services, and PowerShell execution. Configuration is slightly different from Linux (WinRM setup, credential handling), but once connected, the playbook experience is similar. Guide coming soon.
Ansible + GitLab CI/CD
Running Ansible from a GitLab pipeline turns your infrastructure code into a proper CI/CD workflow. Merge requests trigger --check mode for review, merges to main trigger the actual deployment. Combined with Ansible Vault for secrets and GitLab’s protected variables, this gives you auditable, reviewable infrastructure changes.
Ansible + Grafana/Prometheus
Automate the deployment and configuration of your monitoring stack. Ansible installs Prometheus, configures scrape targets from inventory, deploys Grafana with provisioned dashboards and data sources, and sets up Alertmanager rules. When your monitoring infrastructure is defined in code, rebuilding it after a disaster takes minutes instead of hours.
Real-World Projects
Theory is useful, but production experience is what makes the difference. These project-based guides walk through complete automation scenarios you’ll encounter in real infrastructure work.
LAMP/LEMP Stack Deployment
A classic first project: deploy a complete web application stack (Linux, Nginx, MySQL/MariaDB, PHP) with Ansible. One playbook provisions the entire stack, configures virtual hosts, sets up database credentials, and deploys application code. It covers the full loop from bare server to running application.
Server Hardening
A hardening playbook that applies security baselines across your fleet: SSH key-only authentication, fail2ban, unattended security updates, firewall rules, kernel hardening parameters, audit logging. Run it on every new server as part of provisioning. Covers both RHEL and Debian family differences.
User and Group Management
Managing user accounts, SSH keys, sudo rules, and group memberships across dozens of servers is painful without automation. An Ansible role handles all of it from a single source of truth: a YAML file listing users, their keys, their groups, and which servers they should have access to.
Full guide: Manage Users and Groups on Linux Using Ansible
Database Management
Automate PostgreSQL or MySQL/MariaDB deployments: install the server, configure authentication, create databases and users, set replication, manage backups. The community.postgresql and community.mysql collections provide dedicated modules that handle database operations properly, including idempotent user creation and privilege management.
Full guide: Manage PostgreSQL Database with Ansible
SSL Certificate Management
Generate and distribute SSL certificates across your infrastructure with Ansible. Whether you’re using Let’s Encrypt for public services or self-signed certificates for internal communication, automating certificate lifecycle prevents the dreaded expired-certificate outage.
Full guide: Generate OpenSSL Self-Signed Certificates with Ansible
Backup Automation
Automate backup jobs across your fleet: database dumps, config file archives, log rotation, offsite transfer to object storage. A well-designed backup role handles scheduling via cron, retention policies, compression, and notification on failure. The role should be idempotent so running it again doesn’t create duplicate cron entries.
Quick Reference: Ansible CLI Commands
These are the core command-line tools you’ll use daily. For the full reference with examples and flags, see the Ansible Cheat Sheet.
| Command | Purpose | Example |
|---|---|---|
ansible | Run ad-hoc commands on hosts | ansible all -m ping |
ansible-playbook | Execute a playbook | ansible-playbook site.yml |
ansible-galaxy | Install roles and collections | ansible-galaxy install geerlingguy.nginx |
ansible-vault | Encrypt/decrypt sensitive files | ansible-vault encrypt secrets.yml |
ansible-inventory | Display or dump inventory data | ansible-inventory --list |
ansible-doc | View module documentation locally | ansible-doc ansible.builtin.copy |
ansible-config | View and validate configuration | ansible-config dump --changed |
ansible-pull | Pull playbooks from git and run locally | ansible-pull -U https://repo.git |
How Ansible Works: Architecture Overview
Understanding the execution flow helps you debug problems and write better playbooks.
The control node is where you run Ansible. It reads your inventory to determine which hosts to target, parses the playbook to build a task list, then connects to each managed node over SSH (or WinRM for Windows). For each task, Ansible copies a small Python script (the module) to the managed node, executes it, captures the JSON result, and removes the script. The control node collects results from all hosts and reports success or failure.
The key components in this flow:
- Inventory – Defines hosts and groups. Can be static (INI/YAML files) or dynamic (scripts/plugins that query cloud APIs)
- Playbook – YAML file describing desired state. Contains plays, which target host groups, which contain tasks
- Modules – Self-contained units of work (install a package, copy a file, manage a service). Over 6,000 available across collections
- Facts – System information gathered from each managed node at the start of a play (OS, IPs, hardware, mounts)
- Plugins – Extend Ansible’s behavior: connection plugins (SSH, WinRM), callback plugins (output formatting), lookup plugins (external data sources)
- Handlers – Tasks that run only when notified by other tasks. Used for service restarts after config changes
Execution order is deterministic: tasks run top to bottom, one at a time, across all targeted hosts in parallel (controlled by the forks setting). Handlers run at the end of each play, after all tasks complete. This predictability is what makes Ansible reliable in production.
Ansible Concepts for Beginners
If you’re coming from shell scripting or manual administration, these are the mental model shifts that matter most.
Declarative, not imperative. You don’t write “run apt install nginx.” You write “the package nginx should be present.” Ansible checks if it’s already there and only acts if needed. This is why playbooks are safe to run repeatedly.
Push, not pull. By default, you push configuration from the control node to managed nodes on demand. No agent polling a server every 30 minutes. You decide when changes deploy. (Pull mode exists via ansible-pull for specific use cases, like auto-configuring new cloud instances at boot.)
Inventory is everything. A well-structured inventory with logical groups, group variables, and host variables is what separates a maintainable Ansible setup from a messy one. Spend time getting this right early.
For a broader introduction to Ansible’s philosophy and design principles, see our Introduction to Ansible Automation on Linux.
Choosing How to Install: Package Manager vs Pip
This comes up often enough that it deserves its own section.
On Rocky Linux 10, dnf install ansible-core gives you version 2.16.14. Stable, tested with the OS Python (3.12), and covered by RHEL security advisories. This is the right choice for most production control nodes.
Installing via pip (pip install ansible) gives you ansible 13.5.0 with ansible-core 2.20.4. More modules, newer features, faster bug fixes. Use this when you need a specific collection that requires a newer core version, or when you want to run the same Ansible version across different OS platforms.
# Package manager (Rocky Linux 10)
sudo dnf install -y ansible-core
# Pip (any Linux with Python 3.12+)
pip install --user ansibleBoth methods are covered in detail in the installation guide. Pick one and be consistent across your team.
Where to Go from Here
If you’re starting from scratch, begin with installation, then work through ad-hoc commands, inventory, and your first playbook. That sequence gives you working knowledge in a single afternoon.
For the official module index and full documentation, the Ansible documentation is the canonical reference. The collections index lists every available module organized by vendor and platform.
This page is updated as new guides are published. Bookmark it and check back. Every linked article is tested on real infrastructure with verified output, not recycled documentation.
