Ansible Playbook Builder

An Ansible playbook is a YAML file that defines automation tasks to run on remote hosts via SSH. Each playbook contains one or more plays — a play specifies which hosts to target and what tasks to execute. Tasks use modules (apt, copy, service, etc.) to perform idempotent operations. Ansible connects to hosts via SSH using an inventory file and runs tasks in order, top to bottom.

become: true enables privilege escalation — equivalent to using sudo. Set it at the play level to make all tasks run as root, or at the task level to elevate only specific tasks. Use become_user to specify a different target user. For system-level operations (installing packages, managing services, modifying /etc/ files) become is required. Avoid using become on the entire play if only some tasks need it — prefer per-task escalation for least privilege.

Idempotency means running a playbook multiple times produces the same result — subsequent runs make no changes if the desired state is already achieved. Ansible modules are designed to be idempotent: apt module checks if a package is already installed before installing, service module checks if a service is already running. This makes playbooks safe to re-run after partial failures. Use the command/shell modules sparingly as they are NOT idempotent by default — use creates or changed_when to manage their behavior.

Handlers are tasks that only run when notified by another task. They run at the end of a play, after all tasks complete — even if notified multiple times, they run only once. Common use: restart services only when their config changes. Define handlers in the handlers: section and trigger them with notify: handler-name in a task. If notify is set but the notifying task reports 'ok' (unchanged), the handler is NOT triggered — only actual changes fire handlers.

command runs a command directly without a shell — no pipes, redirection, or shell builtins. It's more secure and predictable. shell runs the command through /bin/sh — supports pipes (|), redirection (>), environment variables ($VAR), and shell features. Use command when possible; use shell only when you need shell features. Neither module is idempotent by default — add creates: /path/to/file to skip execution if a file already exists, or use changed_when: false if the command is a check.

Define variables in vars: section of the play, in separate vars_files, or in group_vars/host_vars directories. Reference variables with {{ variable_name }} (Jinja2 syntax). The template module renders Jinja2 templates (.j2 files) with your variables and places the result on the remote host — use it for config files like nginx.conf. For simple variable substitution in task parameters, use {{ var }} directly. Variables can also come from facts (gathered with gather_facts: true) like ansible_os_family and ansible_hostname.