Ansible Playbook Linter

It checks for: hardcoded secrets/passwords in vars, missing required 'hosts:' and 'tasks:' fields, use of non-idempotent 'command:' and 'shell:' modules, missing task names, 'become: yes' without 'become_user:', 'ignore_errors: yes' usage, package modules without 'state:', tab characters, undefined variable checks, and 'notify:' without 'handlers:'.

Ansible's power comes from idempotency — running a playbook multiple times should produce the same result. Built-in modules like 'apt', 'service', 'copy', and 'template' are designed to check current state and only make changes when needed. The 'command:' and 'shell:' modules run blindly every time, breaking idempotency unless you add 'changed_when:', 'creates:', or 'removes:' conditions.

Use Ansible Vault to encrypt sensitive values. You can encrypt entire variable files with 'ansible-vault encrypt vars/secrets.yml' or encrypt individual string values with 'ansible-vault encrypt_string'. Never put plaintext passwords, API keys, or tokens directly in playbooks or unencrypted var files.

Idempotency means running a task multiple times produces the same result as running it once. For example, 'apt: name=nginx state=present' is idempotent — if nginx is already installed, Ansible reports 'ok' and makes no change. This is critical for safe playbook re-runs and configuration drift correction.

Named tasks make playbook output readable and help diagnose failures. When a task fails, Ansible shows the task name in the error output. Anonymous tasks show the module name and arguments, which can be cryptic. Names also serve as documentation for what each step does.

No. All linting runs entirely in your browser using JavaScript. Your playbook YAML — which may contain hostnames, usernames, or structural information about your infrastructure — never leaves your machine.