What Is Ansible? Configuration Management Guide

What is Ansible and where does it fit in configuration management?

Ansible is open-source automation for maintaining system configuration, deploying software and running rolling updates. You declare the desired state of a system in a human-readable playbook and Ansible keeps the system in that state. This guide takes the configuration management angle. For the wider picture of provisioning tools, read our guide to infrastructure as code.

For an enterprise leader, the question is not whether Ansible can install a package. It is whether configuration, patching and compliance settings can be written once, reviewed like code and applied the same way to every host. Below we cover how Ansible works, what changed in 2026, how it relates to Red Hat Ansible Automation Platform, and how to adopt it with governance. Compare the wider toolchain in our DevOps tools guide and the infrastructure as code tools guide.

How does Ansible work?

Per the Ansible basic concepts page, you run Ansible from a control node against managed nodes, which are listed in an inventory. Ansible copies modules to the managed nodes to carry out each task, and normally nothing is installed on them. It is decentralised and uses SSH with existing operating system credentials (Ansible introduction).

What does a playbook look like?

The example below is illustrative. It targets a group of web servers, installs a package, deploys a templated file and makes sure a service is running. It states the desired state explicitly and uses fully qualified collection names, both practices from the Ansible tips page.

---
- name: Configure web servers
  hosts: webservers
  tasks:
    - name: Install the web server package
      ansible.builtin.apt:
        name: apache2
        state: present

    - name: Deploy the site configuration
      ansible.builtin.template:
        src: site.conf.j2
        dest: /etc/apache2/sites-available/site.conf

    - name: Ensure the service is running
      ansible.builtin.service:
        name: apache2
        state: started

Because playbooks are idempotent, running one again on a host that is already in the described state changes nothing. That is what makes repeated runs safe and drift visible. A quick connectivity check across the whole inventory is ansible all -m ping.

Video: an overview of Ansible from XenonStack.

What has changed in Ansible in 2026?

Ansible ships a major ansible-core release roughly every six months, in May and November, with patch releases every four weeks. The latest release and the two before it are maintained. The table is from the release and maintenance page, read on 12 November 2026.

Versions 2.17 and earlier are listed as end of life. Control nodes support the three most recent Python versions, and managed nodes support the six most recent, so an old Python on a managed host can block an upgrade. From 2.21 each release also supports the latest PowerShell 7.x LTS alongside Windows PowerShell 5.1. Pin your ansible-core version, test upgrades in staging and plan around the end-of-life column.

What do Red Hat Ansible Automation Platform and Event-Driven Ansible add?

Ansible itself is open source. Red Hat sells Red Hat Ansible Automation Platform, which its page lists as including automation controller, automation execution environments, automation mesh, Ansible Content Collections, automation hub, Event-Driven Ansible, a self-service automation portal and an automation dashboard and analytics. The older name "Ansible Tower" still appears in searches, but we could not confirm the rename on Red Hat pages, so check the current product names with Red Hat before you plan a purchase.

Event-Driven Ansible works through rulebooks. An event source reports a condition, the engine matches it to a rule and the action runs, for example an existing playbook, template or module. Red Hat gives the example of an unresponsive network router that triggers a configuration reapply, a reset or a service ticket.

How should enterprises govern Ansible and control the risk?

Configuration management changes production at scale, so the control points matter more than the syntax. The Ansible tips page recommends the following, and each maps to a risk a CISO or platform lead will recognise.

Where AI agents begin to trigger automation like this, the same questions apply to the agent: what it may change, under which policy, with what evidence. AgentGRC keeps autonomous agent actions within policy and records evidence that audit and risk teams can review, and ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents. Our guide to compliance as code covers the policy side.

What are the best practices for Ansible playbooks and inventory?

1. Keep it simple. Use advanced features only when necessary.
2. Name plays, tasks and blocks so the output says what each one does and why.
3. State the state. Set state: present or state: absent instead of relying on module defaults.
4. Use fully qualified collection names, for example ansible.builtin.copy.
5. Group inventory by function, such as webservers and dbservers, and use dynamic inventory with clouds.
6. Use comments where the code does not explain what, how and why.
7. Test in staging and update in batches.

These come from the Ansible tips and tricks page. Ansible fits inside a delivery pipeline as well, see our guide to the CI/CD pipeline.

When is Ansible not the right fit, and what are the trade-offs?

• Windows control nodes. Windows without WSL is not natively supported as a control node.
• Python and SSH on targets. Managed nodes need Python and an SSH account to a POSIX shell, except network modules, which do not need Python on the device.
• Version churn. With a release every six months and three maintained versions, upgrade planning is a standing task.
• Subscription features. Controller, hub and Event-Driven Ansible belong to the paid Platform. Check the licence before relying on them.
• Provisioning. Ansible configures hosts. For cloud resource creation, compare the tools in our infrastructure as code tools guide.

How should you adopt Ansible, step by step?

1. Pick one repeatable task, such as a baseline server configuration, and write it as a playbook.
2. Create a function-grouped inventory with separate production and staging.
3. Put everything in version control and review changes like code.
4. Add vault for secrets and run in staging with --syntax-check first.
5. Roll out in batches with serial, then add roles and collections for reuse.
6. Decide whether shared governance justifies Ansible Automation Platform, and whether events should trigger runs.

For teams extending this into agent-driven operations, ElixirClaw is an agentic OS platform to build, orchestrate and govern AI agents and automation workflows while keeping humans in control. See also our guide to intelligent automation with agentic AI.

To map one configuration or remediation decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.

Frequently asked questions about Ansible

What is Ansible used for?

Ansible is open-source automation. Its documentation lists eliminating repetitive work, maintaining system configuration, deploying software and zero-downtime rolling updates as typical uses.

Is Ansible agentless?

Yes. Ansible does not need to be installed on managed nodes. It reaches them over SSH using existing operating system credentials, and managed nodes need Python (network modules are the exception).

Which ansible-core version is current?

On 12 November 2026 the support matrix lists ansible-core 2.21 as the newest release, generally available in May 2026. Versions 2.20 and 2.19 are also maintained, and 2.19 reaches end of life in November 2026.

What is Event-Driven Ansible?

Event-Driven Ansible is a Red Hat Ansible Automation Platform feature. Rulebooks match incoming events from sources such as observability tools to conditions, then run an action such as an existing playbook, template or module.

Should I use Ansible or Terraform?

Treat them as different jobs rather than rivals. Our infrastructure as code guide covers provisioning tools, while this guide covers configuring the machines once they exist, so many teams use both.