Mastering Ansible: A Comprehensive Step-by-Step Guide

Ansible is an open-source automation tool that configures servers, deploys applications and runs repeatable maintenance from one machine, over plain SSH. You describe the state you want in YAML, and Ansible makes each server match it. This guide takes you from installation to inventories, playbooks, variables, roles and Vault, using current Ansible practice for 2026.

1. How Ansible works

Ansible is agentless and push-based. You run it on a control node (your laptop, a CI runner or a small management server). It connects to each managed node over SSH (or WinRM for Windows), copies a small Python module across, runs it and removes it. Nothing stays installed on the target except Python, which almost every Linux server already has.

The building blocks:

Most modules are idempotent: they check the current state first and change something only when needed. Running the same playbook twice should report changed=0 the second time.

2. Install Ansible and connect to your servers

Ansible's control node runs on Linux or macOS. On Windows, use it inside WSL. The simplest cross-platform install is through pipx, which keeps Ansible in its own Python environment:

pipx install --include-deps ansible
ansible --version

The ansible package includes ansible-core plus the popular community collections. Distribution packages (sudo dnf install ansible-core on AlmaLinux or Rocky, sudo apt install ansible on Ubuntu) also work, but they are often older.

Ansible logs in with SSH keys. Create a modern key and copy it to each server:

ssh-keygen -t ed25519 -C "ansible"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Use a normal user with sudo rights rather than logging in as root, and once key login works, turn off password login in /etc/ssh/sshd_config on the server.

3. Build your inventory

A static inventory can be INI or YAML. INI is the quickest to read:

# inventory.ini
[web]
web1 ansible_host=203.0.113.10
web2 ansible_host=203.0.113.11

[db]
db1 ansible_host=203.0.113.20

[all:vars]
ansible_user=deploy
ansible_python_interpreter=auto_silent

Test every host:

ansible all -i inventory.ini -m ansible.builtin.ping

A reply of "ping": "pong" means SSH and Python both work. Put group and host variables in group_vars/web.yml and host_vars/web1.yml rather than on the inventory lines, and never store passwords in the inventory; section 7 covers secrets.

For cloud fleets, a dynamic inventory plugin reads hosts from the provider's API instead of a file, for example amazon.aws.aws_ec2 from the amazon.aws collection. The old standalone inventory scripts are replaced by these plugins.

4. Run one-off commands

The ansible command runs a single module across hosts, which is handy for quick checks:

ansible web -i inventory.ini -a "uptime"
ansible web -i inventory.ini -b -m ansible.builtin.dnf -a "name=chrony state=present"

-b means "become" (sudo). For anything you will run twice, write a playbook instead.

5. Write your first playbook

This playbook installs and starts nginx on AlmaLinux or Rocky Linux, and deploys a config file from a template:

# site.yml
- name: Configure web servers
  hosts: web
  become: true
  vars:
    http_port: 80

  tasks:
    - name: Install nginx
      ansible.builtin.dnf:
        name: nginx
        state: present

    - name: Deploy site config
      ansible.builtin.template:
        src: templates/site.conf.j2
        dest: /etc/nginx/conf.d/site.conf
        mode: "0644"
      notify: Reload nginx

    - name: Start and enable nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Run it, dry-run first:

ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml

Two habits keep playbooks portable. Use fully qualified collection names (ansible.builtin.template, not template). And when a playbook must run on both Ubuntu and AlmaLinux, use ansible.builtin.package, or pick apt or dnf with when: ansible_facts['os_family'] == "Debian".

6. Variables, facts, conditionals and loops

Variables can live in the play, in group_vars and host_vars, in role defaults or on the command line. When the same name is set in several places, the more specific source wins. In practice: role defaults are the weakest, inventory variables beat them, play variables beat those, and --extra-vars on the command line always wins.

Facts are details Ansible gathers from each host at the start of a play: OS family, IP addresses, memory and more. Read them through ansible_facts:

- name: Show the OS
  ansible.builtin.debug:
    msg: "{{ inventory_hostname }} runs {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}"

Conditionals and loops combine naturally:

- name: Install base packages on RHEL-family hosts
  ansible.builtin.dnf:
    name: "{{ item }}"
    state: present
  loop:
    - git
    - curl
    - firewalld
  when: ansible_facts['os_family'] == "RedHat"

For a package list, passing the whole list to name: in one task is faster than a loop.

7. Keep secrets in Ansible Vault

Vault encrypts files or single values with a password, so you can commit them to Git safely:

ansible-vault create group_vars/db/vault.yml
ansible-vault edit group_vars/db/vault.yml
ansible-playbook -i inventory.ini site.yml --ask-vault-pass

A common pattern is to keep vault_db_password in the encrypted file and reference it from a plain vars.yml as db_password: "{{ vault_db_password }}", so you can still search for variable names. For automation, read the vault password from a file outside the repository (--vault-password-file), and add no_log: true to any task that would print a secret.

8. Organise with roles and collections

Once a playbook grows past a page, split it into roles:

ansible-galaxy role init roles/nginx

This creates tasks/, handlers/, templates/, files/, defaults/, vars/ and meta/. Your playbook then becomes a short list of roles. Pin external roles and collections in a requirements.yml and install them with ansible-galaxy install -r requirements.yml, so every machine uses the same versions.

9. Test, debug and run safely

Common errors: "Permission denied (publickey)" means the key or user is wrong; "Missing sudo password" needs --ask-become-pass or passwordless sudo for the deploy user; "couldn't resolve module" usually means a collection is not installed.

For a web interface, scheduling and access control, AWX is the free upstream project (installed on Kubernetes with the AWX Operator), and Red Hat Ansible Automation Platform is the supported commercial product that replaced Ansible Tower. You do not need either to start.

10. Running Ansible with Domain India

Ansible fits a Domain India VPS: KVM virtualisation, full root access and a choice of Linux distribution, so every example above runs as written. The VPS is self-managed, which is exactly where Ansible earns its keep: your server setup lives in Git and can be rebuilt quickly. To combine Ansible with Terraform, see Infrastructure as Code on a Domain India VPS: Terraform and Ansible.

On shared hosting (cPanel, DirectAdmin, Webuzo), jailed SSH is available on every plan but off by default; ask support to enable it for your account. It is a restricted shell with key-only login, so Ansible cannot install packages or change server settings there. For shared hosting, deploy your site with Git or SFTP instead; see enabling and accessing jailed SSH.

Prices on the cards are live Domain India list prices and exclude 18% GST.

Ready to automate? Compare VPS plans, then follow the Terraform and Ansible guide to keep your whole server setup in Git.