Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

In this lesson we focus on one of the most important parts of Ansible: playbooks. Understanding how playbooks are structured and how they execute gives you a reliable foundation to automate system configuration, application deployment, and operational tasks. What is a playbook? Think of a playbook as an automation blueprint: a human-readable, declarative description of the desired end state for one or more hosts. Ansible evaluates the declaration and makes the remote systems match that state. Playbooks use YAML for readability and maintainability so teams can review, share, and version control automation easily.
A slide titled "What Is a Playbook?" showing four numbered cards labeled 01 Blueprint, 02 Desired state, 03 YAML file, and 04 Human-readable and repeatable, each with a small icon.
Key benefits of using playbooks
  • Consistency: Running the same playbook produces the same result every time.
  • Scale: Apply the same configuration across many hosts in a single run.
  • Idempotence: Re-running a playbook leaves systems unchanged when they already match the desired state.
  • Readability: Playbooks double as documentation for what your automation does.
A presentation slide titled "Playbooks – Benefits" with four turquoise circular icons across the top. The icons are labeled "Consistency," "Saves time," "Safe and idempotent," and "Readable."
Basic skeleton of a playbook A playbook is one or more plays, and a play targets one or more hosts. At minimum, a play typically contains:
  • name: a descriptive label for the play
  • hosts: the inventory group or host pattern to target
  • become: whether to use privilege escalation (e.g., sudo)
  • tasks: a list of steps (each task calls a module)
Every playbook begins with the YAML document marker ---. Example minimal playbook: 
---
- name: My play
  hosts: all
  become: true
  tasks:
    - name: Ensure nginx is installed
      apt:
        name: nginx
        state: present
Everything else — variables, handlers, roles, loops, and conditionals — builds on this same foundation. Playbook components explained Below is a quick reference for the main building blocks you’ll use in playbooks.
ComponentPurposeCommon examples
TasksOrdered steps executed on target hostsUse modules like apt, yum, file, service
ModulesIdempotent units that perform actionsapt, copy, template, uri
HandlersTasks triggered only when notified (useful for restarts)notify: Restart nginx
RolesDirectory layout for reusable code and separation of concernsroles/nginx/tasks/main.yml
VariablesParameterize values across environmentsInventory vars, vars_files, host_vars
Loops & ConditionalsIterate or run tasks conditionally to avoid duplicationloop, when
A slide titled "Playbook Components" showing six labeled cards in two columns—left: Tasks, Modules, Handlers; right: Roles, Variables, Loops & Conditionals—each paired with a simple icon. The layout uses a dark blue background with teal accents.
Running and validating playbooks Use ansible-playbook to execute playbooks. Before applying changes to real systems, validate syntax and structure. Commands: 
# Run a playbook
ansible-playbook site.yml

# Check playbook syntax without connecting to hosts
ansible-playbook --syntax-check site.yml
Quick command references
TaskCommand
Run a playbookansible-playbook site.yml
Syntax checkansible-playbook --syntax-check site.yml
Check inventoryansible-inventory --list -i inventory/
Best practices and habits Adopt these habits to keep playbooks reliable and maintainable:
  • Always include a name for plays and for every task — it improves readability and troubleshooting.
  • Run ansible-playbook --syntax-check before applying changes.
  • Use handlers to avoid unnecessary service restarts when multiple tasks might trigger the same action.
  • Prefer loops and conditionals over duplicating similar tasks to keep your playbooks concise and adaptable.
Additional tips:
  • Keep roles focused and small; one role should do one job.
  • Use check_mode (ansible-playbook --check) for dry runs where appropriate.
  • Store secrets in Ansible Vault and avoid committing secrets to version control.
  • Keep host- and group-level variables in separate host_vars/ and group_vars/ directories for clarity.
Conclusion These fundamentals — structure, modules, handlers, roles, variables, and the habit of validating before running — are the building blocks of effective Ansible automation. Once comfortable with these basics, you can expand into advanced topics like custom modules, dynamic inventories, and complex role reuse. Further reading

Watch Video