Validate an Ansible Playbook

Ansible playbooks define infrastructure automation as readable YAML files that describe the desired state of your servers. Unlike imperative shell scripts, Ansible modules are idempotent by default — running the same playbook twice leaves the system in the same state as running it once. This makes playbooks safe to run repeatedly, which is essential for configuration drift correction and zero-downtime rolling updates across a fleet of servers. This example playbook configures a web server. The play targets the "webservers" group from the inventory file, becomes: true elevates privileges to run tasks as root (via sudo), defines two variables (app_port and app_user), runs two tasks to install and configure nginx, and uses a handler to restart nginx only when the configuration file changes. Key YAML structure points: the --- at the top indicates this is a YAML document (optional but conventional for Ansible). The file starts with a list because a playbook can contain multiple plays. The tasks and handlers keys are lists, with each item preceded by a dash. The indentation of name, apt, template, and service inside their respective task or handler blocks is critical — Ansible expects each module's parameters at the same indent level as the module name. The handler pattern is elegant: the template task includes notify: Restart nginx, which means when the task makes a change (the config file was different and was updated), Ansible queues the "Restart nginx" handler. Handlers run after all tasks complete, and only if they were notified — if the config file didn't change, the handler doesn't fire. Multiple tasks can notify the same handler, but it only runs once per play regardless of how many tasks notified it. Real-world scenarios: rolling out a new nginx configuration across fifty web servers, verifying each restart succeeds before moving to the next server; ensuring all servers in a cluster have the same version of a package installed; correcting configuration drift that accumulated from manual changes by re-applying the authoritative playbook. Tips: validate YAML syntax before running ansible-playbook to catch indentation errors that would cause partial runs. Use --check flag (dry-run mode) to preview what changes would be made without actually executing them. Use --diff to see exactly what content in configuration files would change.

Example
---
- name: Configure web server
  hosts: webservers
  become: true
  vars:
    app_port: 8080
    app_user: deploy

  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
        update_cache: true

    - name: Copy nginx config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted
[ open in YAML Validator → ]

FAQ

What is the become directive in Ansible?
become: true tells Ansible to run tasks with elevated privileges (sudo by default), required for tasks that install packages or modify system files.
What are handlers in Ansible?
Handlers are tasks that only run when notified by another task. They are commonly used to restart services after configuration changes, and run once at the end of a play even if notified multiple times.
What is the difference between a play and a task?
A playbook contains one or more plays. Each play targets a group of hosts and contains a list of tasks. Tasks are the individual units of work executed by Ansible modules.

Related Examples