- TechOps Examples
- Posts
- Ansible Roles Directory Structure BreakDown
Ansible Roles Directory Structure BreakDown
Govardhana M K
January 15, 2025
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.
IN TODAY'S EDITION
🧠 Use Case
Ansible Roles Directory Structure BreakDown
🚀 Top News
👀 Remote Jobs
3pillar Global is hiring a Technical Lead DevOps
Remote Location: India
Canonical is hiring a Linux Platform Integration Engineer
Remote Location: Worldwide
📚️ Resources
📢 Reddit Threads
🛠️ TOOL OF THE DAY
IAM Policy Tester - Free tool that instantly evaluates IAM policies client side as you type them.
Detailed “Explain” views showing exactly why a statement applies or doesn’t.
One-click sharing for your team and automated policy documentation.
🧠 USE CASE
Ansible Roles Directory Structure BreakDown
Ansible roles are one of the most powerful yet underutilized features in many automation projects.
They provide a modular and reusable structure that not only simplifies complex playbooks but also enforces better organization and maintainability.
Yet, I’ve seen countless teams either avoid roles altogether or misuse them, creating technical debt instead of leveraging their full potential.
It is not as though we lack resources; for instance, RedHat’s Ansible Best Practices - How to Write, How to Execute, and How to Use in Real Life is a fantastic handbook that every DevOps engineer should read at least once.
We just lack adoption.
Here, I have visually broken down the Ansible roles directory structure.
Since it’s self-explanatory and well labeled, I won’t dive into explaining it.
Instead, let’s focus on common traps I’ve witnessed in real-world projects when using roles.
1. Monolithic tasks/main.yml File
Dumping all logic into tasks/main.yml makes debugging harder, as there’s no clear separation of concerns.
Instead do this: Break down tasks into smaller YAML files (e.g., install.yml, configure.yml) and include them in main.yml using include_tasks or import_tasks.
2. Hardcoding Variables
Hardcoding variables directly in tasks/main.yml makes it difficult to override or customize roles.
Instead do this: Define all configurable variables in defaults/main.yml and use vars/main.yml for variables tightly scoped to the role.
3. Ignoring meta/main.yml for Dependencies
Skipping the use of meta/main.yml to define role dependencies results in duplication and unclear inter-role relationships.
Instead do this: Use the dependencies key in meta/main.yml to declare dependent roles explicitly.
4. Misusing the files and templates Directories
Mixing static files and Jinja2 templates in either files or templates creates confusion for maintainers.
Instead do this: Always place static files in files/ and Jinja2 templates in templates/.
5. Not Writing Idempotent Tasks
Writing tasks that perform actions without checking the state causes unintended changes on every execution.
Instead do this: Ensure every task checks for the desired state (e.g., using when, creates, or stat) before execution.
6. Failing to Use Handlers Properly
Adding actions (e.g., service restarts) directly to tasks instead of leveraging handlers results in redundant executions.
Instead do this: Delegate restart/reload operations to handlers and trigger them using notify.
Remember,
Ansible roles are not just a folder structure - they're a methodology. Treat as one.