Ansible

Ansible is a free, open-source automation tool for sysadmins who manage more than a handful of Windows and Linux machines and are tired of doing the same change by hand on each one. You describe the desired state of servers in YAML playbooks, and Ansible connects over SSH (Linux) or WinRM/SSH (Windows) and makes it so; there is no agent to install on the managed machines.

Typical jobs are patching, installing software, pushing config files, creating users, managing services and scheduled tasks, and running the same command on 200 hosts at once. It is maintained by Red Hat and the Ansible community; Red Hat also sells Ansible Automation Platform, a commercial product built around the same engine, but the command-line tools covered here are free.

Ansible at a glance

What it does

• Runs ad-hoc commands against groups of hosts (ansible web -m ansible.builtin.ping).
• Applies idempotent playbooks: re-running a playbook only changes what is not already in the desired state, and --check --diff shows what would change.
• Manages Windows through the ansible.windows, community.windows, microsoft.ad and chocolatey.chocolatey collections: updates, services, registry, features, scheduled tasks, packages, AD objects.
• Manages Linux packages, services, users, files, firewall rules and templates (Jinja2).
• Groups hosts in static inventory files or dynamic inventories pulled from clouds and hypervisors.
• Keeps passwords and keys encrypted in the repository with Ansible Vault.
• Reuses community roles and collections from Ansible Galaxy.

How sysadmins use it

Patch Windows servers and reboot only when needed

1. On each Windows host, enable remoting in an elevated PowerShell: Enable-PSRemoting -Force (for production, prefer an HTTPS listener or Kerberos in a domain).
2. Create inventory.ini on the control node:

[windows]
srv-app01.corp.example.com
srv-app02.corp.example.com

[windows:vars]
ansible_connection=winrm
ansible_port=5985
ansible_winrm_transport=ntlm
ansible_user=svc-ansible@CORP.EXAMPLE.COM

3. Create win-patch.yml:

- name: Monthly Windows patching
  hosts: windows
  tasks:
    - name: Install security and critical updates
      ansible.windows.win_updates:
        category_names:
          - SecurityUpdates
          - CriticalUpdates
        reboot: true

4. Test connectivity with ansible windows -i inventory.ini -m ansible.windows.win_ping --ask-pass, then run ansible-playbook -i inventory.ini win-patch.yml --ask-pass --limit srv-app01* on one server before the whole group.

Replace hand-made Task Scheduler jobs with code

1. Instead of clicking the same scheduled task into every server, declare it once:

- name: Nightly cleanup task on file servers
  hosts: fileservers
  tasks:
    - community.windows.win_scheduled_task:
        name: NightlyCleanup
        username: SYSTEM
        actions:
          - path: powershell.exe
            arguments: -NoProfile -File C:Scriptscleanup.ps1
        triggers:
          - type: daily
            start_boundary: '2026-10-01T02:00:00'
        state: present
        enabled: true

2. Keep the playbook in Git; the task definition is now reviewed, versioned and identical on every server.

Update Debian/Ubuntu servers

- name: Patch Ubuntu servers
  hosts: linux
  become: true
  tasks:
    - ansible.builtin.apt:
        update_cache: true
        upgrade: dist
    - ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_flag
    - ansible.builtin.reboot:
      when: reboot_flag.stat.exists

Run it with ansible-playbook -i inventory.ini linux-patch.yml -K (-K asks for the sudo password) and add -f 20 to work on 20 hosts in parallel.

Keep secrets out of plain text

1. ansible-vault create group_vars/windows/vault.yml and put ansible_password: ... inside.
2. Run playbooks with --ask-vault-pass (or a vault password file readable only by the automation account).

Install and first run

Linux / macOS control node: the documented method is pipx or pip:

pipx install --include-deps ansible
# or
python3 -m pip install --user ansible
ansible --version

Distribution packages (apt install ansible, dnf install ansible-core) also work but are often older. The ansible package includes curated community collections; ansible-core is the minimal engine.

Windows: Ansible cannot run natively on Windows as a control node. Run it inside WSL or a Linux VM; the official docs note WSL is not supported for production, so a small Linux VM is the usual answer. To manage Windows hosts, also install the WinRM client library on the control node: pipx inject ansible pywinrm.

Managed nodes: Linux hosts need SSH and Python; Windows hosts need Windows Server 2016 / Windows 10 or newer with the built-in PowerShell 5.1, plus WinRM (ports 5985 HTTP / 5986 HTTPS) or OpenSSH (port 22). SSH to Windows has been officially supported since ansible-core 2.18.

Gotchas: WinRM listeners and the Windows firewall rule must allow the control node; NTLM over HTTP is fine in a lab but use HTTPS or Kerberos in production; first SSH connections fail on unknown host keys until you accept them or pre-populate known_hosts.

Limitations

• No native Windows control node; you need Linux, macOS or WSL.
• Push-based: nothing happens until someone or something runs the playbook. For schedules, a web UI and RBAC you add AWX (free, upstream) or Red Hat Ansible Automation Platform (commercial).
• Large fleets over SSH/WinRM can be slow without tuning forks, pipelining and fact caching.
• YAML plus Jinja2 templating has a learning curve, and collection versions must be pinned to keep playbooks reproducible.
• Each ansible-core release has a limited support window, so plan upgrades.

Ansible vs alternatives

Puppet and Chef use an agent on every node and a central server that enforces state continuously; Ansible is agentless and easier to start with but only acts when run. Salt offers both agent and agentless modes and is fast on very large fleets. Terraform provisions infrastructure (VMs, cloud resources) and is often used together with Ansible, which configures what Terraform created. On Windows-only estates, Group Policy and PowerShell DSC cover some of the same ground. Ansible also plugs into tools you may already use: it installs packages through Chocolatey on Windows and works as a provisioner for Vagrant test VMs.

FAQ

Is Ansible free?

Yes. The ansible and ansible-core packages are free and open source under GPL-3.0-or-later, including for commercial use. Red Hat Ansible Automation Platform is a separate paid product.

Can I download Ansible for Windows?

There is no native Windows control node. Install Ansible in WSL or a Linux VM and use it to manage Windows machines over WinRM or SSH.

Can Ansible manage Windows servers?

Yes. Windows Server 2016 / Windows 10 and newer are supported out of the box using WinRM, PSRP or SSH, with modules for updates, services, features, registry, scheduled tasks and Active Directory.

Ansible vs Terraform: which do I need?

Terraform is best at creating and destroying infrastructure; Ansible is best at configuring the operating systems and applications on it. Many teams use both.

How do I run an Ansible playbook?

ansible-playbook -i inventory.ini site.yml. Add --check --diff for a dry run, --limit host1 to target one host and -K for a sudo password.

Is Ansible open source?

Yes. The source is on GitHub under GPL-3.0-or-later; AWX is the open-source upstream project of the Automation Platform controller (the former Ansible Tower).

What is the difference between ansible and ansible-core?

ansible-core is the engine with built-in modules. The ansible package (now version 14) bundles ansible-core 2.21 with a curated set of community collections.

Last checked against official sources: 30 September 2026 (developer website: ansible.com). Versions and licence terms change — confirm on the developer's site before deploying in production.