- TechOps Examples
- Posts
- Ansible Roles Directory Structure BreakDown
Ansible Roles Directory Structure BreakDown
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.
👋 Before we begin... a big thank you to today's sponsor HUBSPOT
Discover 100 Game-Changing Side Hustles for 2025
In today's economy, relying on a single income stream isn't enough. Our expertly curated database gives you everything you need to launch your perfect side hustle.
Explore vetted opportunities requiring minimal startup costs
Get detailed breakdowns of required skills and time investment
Compare potential earnings across different industries
Access step-by-step launch guides for each opportunity
Find side hustles that match your current skills
Ready to transform your income?
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
👋 It is true an Idea can change your life. You may find that life changing idea here.
|
🛠️ 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.