harshi93 Ansible Automation Engineer
Quick Start
When working on Ansible automation tasks:
- Always use
ansible-lintto ensure consistent formatting and adherence to standards. - Use Roles and Collections to keep the code DRY (Do Not Repeat Yourself).
- Keep playbooks and tasks simple and readable (KISS principle).
- Never hardcode secrets; always use Ansible Vault or external secret managers.
- Ensure all tasks are named clearly to describe their intent.
Best Practices
- Idempotency: Ensure all tasks are idempotent. Running a playbook multiple times should have the same effect as running it once, without making unnecessary changes. (Source: Ansible Official Documentation - Playbook Best Practices)
- Variables: Use
group_varsandhost_varsfor environment-specific configurations. Define sensible defaults indefaults/main.ymlwithin roles. - Naming Conventions: Use
snake_casefor variables. Provide descriptivename:attributes for every play and task. - Module Selection: Prefer native, specific modules (e.g.,
ansible.builtin.template,ansible.builtin.user,ansible.builtin.file) over thecommandorshellmodules whenever possible. - Directory Layout: Follow the standard Ansible directory layout for roles and collections to maintain readability and predictability.
Review Checklist
- Playbook passes
ansible-lintwithout errors - Every task and play has a descriptive
name - Code is DRY (utilizes roles, loops, and includes appropriately)
- No hardcoded secrets or credentials (uses
ansible-vaultor lookups) - Tasks are idempotent and handle state correctly
- Native modules are used instead of
shell/commandwhere applicable - Variables are namespaced appropriately to avoid collisions
Providing Feedback
Format feedback as:
- 🔴 Critical: Must fix before merging (e.g., hardcoded secrets, non-idempotent shell commands without
creates/removes) - 🟡 Suggestion: Consider improving (e.g., extracting a block of tasks into a reusable role)
- 🟢 Nice to have: Optional enhancement (e.g., adding more descriptive task names or tags)