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.<\/p>\n\n
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.<\/p>\n\n
Updated April 2026<\/strong> for ansible-core 2.20.4 and ansible 13.5.0. All linked guides tested on Rocky Linux 10.1 and Ubuntu 24.04. 17 articles published in the series.<\/em><\/p>\n\n\n 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.<\/p>\n\n 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.<\/p>\n\n Every Ansible module is idempotent by design. Run a playbook once or ten times, the result is the same. The The module library covers nearly everything: package management, file manipulation, user accounts, firewall rules, cloud provisioning, container orchestration, network devices. For a detailed comparison with Chef, Puppet, and SaltStack, see Ansible vs Chef vs Puppet vs Salt<\/a>.<\/p>\n\n\n 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.<\/p>\n\n\n 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.<\/p>\n\n 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.<\/p>\n\n\n A working installation shows the core version, config file path, and Python interpreter:<\/p>\n\n\n Full installation walkthrough for multiple distros and methods:<\/p>\n\n 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.<\/p>\n\n\n That single command restarts Nginx on every host in the Full guide: Ansible Ad-Hoc Commands<\/a><\/p>\n\n\n 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.<\/p>\n\n Getting inventory structure right early saves significant refactoring later. A well-organized inventory with logical groups ( Full guide: Ansible Inventory Management<\/a><\/p>\n\n\n 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<\/em> should be true, and Ansible figures out the steps to get there.<\/p>\n\n A playbook that installs and configures Nginx with a custom virtual host might look like this:<\/p>\n\n\n Even without Ansible experience, you can read that and understand what it does. That readability is one of Ansible’s strongest selling points.<\/p>\n\n Full guide: Ansible Playbook Tutorial<\/a><\/p>\n\n\n 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.<\/p>\n\n Full guide: Ansible Variables: Facts, Defaults, and Custom Setup<\/a><\/p>\n\n\n Not every task should run on every host. The Full guide: Ansible Conditionals and Loops<\/a><\/p>\n\n\n Handlers solve a common problem: you only want to restart a service when its configuration actually changed. If you update Templates turn static config files into dynamic ones. A single Full guide: Ansible Jinja2 Templating<\/a><\/p>\n\n\n 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 Full guide: Ansible Roles Tutorial<\/a><\/p>\n\n\n When a playbook fails (and it will), you need to know how to investigate. The 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.<\/p>\n\n\n 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.<\/p>\n\n Full guide: Ansible Vault Tutorial<\/a> | Quick reference: Vault Cheat Sheet<\/a><\/p>\n\n\n 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.<\/p>\n\n Full guide: Ansible Dynamic Inventory<\/a><\/p>\n\n\n 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 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.<\/p>\n\n\n 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 Production playbooks need to handle failures gracefully. The Ansible manages Docker containers, images, networks, and volumes through the Full guide: Manage Docker Containers with Ansible<\/a><\/p>\n\n\n 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.<\/p>\n\n Full reference: Ansible Cheat Sheet<\/a><\/p>\n\n\n 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.<\/p>\n\n\n 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.”<\/p>\n\n Full guide: Event-Driven Ansible (EDA) Tutorial<\/a><\/p>\n\n\n 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 Rolling updates, canary deployments, blue-green switches. Ansible’s 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 Managing 10 servers and managing 10,000 servers requires different approaches. Connection plugins, SSH pipelining, The Default Ansible settings are conservative. Bumping 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.<\/p>\n\n\n 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.<\/p>\n\n Full guide: Terraform and Ansible Tutorial<\/a><\/p>\n\n\n The Full guide: Ansible + Proxmox Tutorial<\/a><\/p>\n\n\n Ansible manages Windows servers over WinRM instead of SSH. The Full guide: Ansible for Windows Server<\/a><\/p>\n\n\n Running Ansible from a GitLab pipeline turns your infrastructure code into a proper CI\/CD workflow. Merge requests trigger 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.<\/p>\n\n\n 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.<\/p>\n\n\n 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.<\/p>\n\n\n 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.<\/p>\n\n\n 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.<\/p>\n\n Full guide: Manage Users and Groups on Linux Using Ansible<\/a><\/p>\n\n\n Automate PostgreSQL or MySQL\/MariaDB deployments: install the server, configure authentication, create databases and users, set replication, manage backups. The Full guide: Manage PostgreSQL Database with Ansible<\/a><\/p>\n\n\n 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.<\/p>\n\n Full guide: Generate OpenSSL Self-Signed Certificates with Ansible<\/a><\/p>\n\n\n 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.<\/p>\n\n\n These are the core command-line tools you’ll use daily. For the full reference with examples and flags, see the Ansible Cheat Sheet<\/a>.<\/p>\n\n\nWhat Makes Ansible Different<\/h2>\n\n\n
apt<\/code> module doesn’t reinstall a package that’s already present. The lineinfile<\/code> 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.<\/p>\n\nGetting Started<\/h2>\n\n\n
Install Ansible<\/h3>\n\n\n
ansible --version<\/code><\/pre>\n\n\nansible [core 2.16.14]\n config file = \/etc\/ansible\/ansible.cfg\n configured module search path = ['\/root\/.ansible\/plugins\/modules']\n ansible python module location = \/usr\/lib\/python3.12\/site-packages\/ansible\n executable location = \/usr\/bin\/ansible\n python version = 3.12.8<\/code><\/pre>\n\n\n\n
Ad-Hoc Commands<\/h3>\n\n\n
ansible webservers -m service -a \"name=nginx state=restarted\"<\/code><\/pre>\n\n\nwebservers<\/code> group, in parallel, with proper service management (not a raw kill<\/code> and start).<\/p>\n\nInventory Management<\/h3>\n\n\n
webservers<\/code>, databases<\/code>, staging<\/code>, production<\/code>) makes playbooks cleaner and limits the blast radius of mistakes.<\/p>\n\nYour First Playbook<\/h3>\n\n\n
---\n- name: Configure web servers\n hosts: webservers\n become: true\n tasks:\n - name: Install Nginx\n ansible.builtin.dnf:\n name: nginx\n state: present\n\n - name: Deploy virtual host config\n ansible.builtin.template:\n src: templates\/vhost.conf.j2\n dest: \/etc\/nginx\/conf.d\/app.conf\n notify: Restart Nginx\n\n handlers:\n - name: Restart Nginx\n ansible.builtin.service:\n name: nginx\n state: restarted<\/code><\/pre>\n\n\nVariables and Facts<\/h3>\n\n\n
Conditionals and Loops<\/h3>\n\n\n
when<\/code> keyword lets you skip tasks based on facts, variables, or the results of previous tasks. Install httpd<\/code> on RHEL, apache2<\/code> 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.<\/p>\n\nHandlers<\/h3>\n\n\n
nginx.conf<\/code> 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.<\/p>\n\n\nJinja2 Templating<\/h3>\n\n\n
nginx.conf.j2<\/code> 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.<\/p>\n\nAnsible Roles<\/h3>\n\n\n
nginx<\/code> role, a postgresql<\/code> role, a security_baseline<\/code> role. Each can be developed, tested, and reused independently. Ansible Galaxy hosts thousands of community roles you can use as starting points.<\/p>\n\nDebugging Playbooks<\/h3>\n\n\n
debug<\/code> module prints variable values during execution. Increasing verbosity with -v<\/code>, -vv<\/code>, or -vvv<\/code> shows connection details, module arguments, and raw responses. The --check<\/code> flag does a dry run. The --diff<\/code> flag shows what would change in files. Mastering these tools turns a 30-minute debugging session into a 2-minute one.<\/p>\n\n\nIntermediate Skills<\/h2>\n\n\n
Ansible Vault<\/h3>\n\n\n
Dynamic Inventory<\/h3>\n\n\n
Collections<\/h3>\n\n\n
ansible-galaxy collection install<\/code> and reference modules by their fully qualified name (like ansible.builtin.copy<\/code> or community.postgresql.postgresql_db<\/code>). Understanding collections is essential for working with current Ansible versions.<\/p>\n\n\nMolecule Testing<\/h3>\n\n\n
Filters and Data Manipulation<\/h3>\n\n\n
json_query<\/code>, regex_replace<\/code>, ipaddr<\/code>, and combine<\/code> are used constantly in production playbooks. Learning the common filters saves you from writing custom modules for simple data transformations.<\/p>\n\n\nError Handling and Recovery<\/h3>\n\n\n
block<\/code>\/rescue<\/code>\/always<\/code> pattern lets you try a set of tasks, catch failures, and run cleanup regardless of outcome. The ignore_errors<\/code> directive, failed_when<\/code> conditions, and retries<\/code> with until<\/code> 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.<\/p>\n\n\nDocker with Ansible<\/h3>\n\n\n
community.docker<\/code> 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.<\/p>\n\nAnsible Cheat Sheet<\/h3>\n\n\n
Advanced Topics<\/h2>\n\n\n
Event-Driven Ansible<\/h3>\n\n\n
Custom Modules<\/h3>\n\n\n
shell<\/code> and command<\/code> tasks.<\/p>\n\n\nZero-Downtime Deployments<\/h3>\n\n\n
serial<\/code> 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.<\/p>\n\n\nCompliance Scanning<\/h3>\n\n\n
--check<\/code> mode generates reports without making changes, which is exactly what auditors want to see.<\/p>\n\n\nScaling Ansible<\/h3>\n\n\n
mitogen<\/code> for faster execution, fact caching with Redis, pull-mode with ansible-pull<\/code>, 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.<\/p>\n\n\nKubernetes with Ansible<\/h3>\n\n\n
kubernetes.core<\/code> 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.<\/p>\n\n\nPerformance Tuning<\/h3>\n\n\n
forks<\/code> from 5 to 50, enabling SSH pipelining, using gather_facts: false<\/code> when you don’t need facts, switching to the free<\/code> strategy, and caching facts between runs can dramatically reduce execution time. For large inventories, these optimizations compound.<\/p>\n\n\nIntegration Guides<\/h2>\n\n\n
Terraform + Ansible<\/h3>\n\n\n
Ansible + Proxmox<\/h3>\n\n\n
community.general.proxmox<\/code> 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.<\/p>\n\nAnsible + Windows Server<\/h3>\n\n\n
ansible.windows<\/code> 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.<\/p>\n\nAnsible + GitLab CI\/CD<\/h3>\n\n\n
--check<\/code> 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.<\/p>\n\n\nAnsible + Grafana\/Prometheus<\/h3>\n\n\n
Real-World Projects<\/h2>\n\n\n
LAMP\/LEMP Stack Deployment<\/h3>\n\n\n
Server Hardening<\/h3>\n\n\n
User and Group Management<\/h3>\n\n\n
Database Management<\/h3>\n\n\n
community.postgresql<\/code> and community.mysql<\/code> collections provide dedicated modules that handle database operations properly, including idempotent user creation and privilege management.<\/p>\n\nSSL Certificate Management<\/h3>\n\n\n
Backup Automation<\/h3>\n\n\n
Quick Reference: Ansible CLI Commands<\/h2>\n\n\n