Roles are the primary way to organize Ansible content for reuse. They enforce a standard directory structure, allow dependency management, and can be shared via Ansible Galaxy. This lab covers creating roles with ansible-galaxy init, understanding role directory structure, dependencies, requirements.yml, and using roles in playbooks.
Prerequisites
Completed Lab 06 (Ansible Foundations)
Understanding of YAML and playbook structure
Step 1: Create a Role with ansible-galaxy init
dockerrun--rmubuntu:22.04bash-c"apt-get update -qq 2>/dev/null && apt-get install -y -qq python3-pip python3 2>/dev/nullpip3 install ansible --quiet 2>/dev/nullcd /tmpansible-galaxy init webserverecho '=== Role created successfully ==='echo ''echo '=== Role directory structure ==='find webserver -type f | sort"
📸 Verified Output:
💡 Tip:ansible-galaxy init creates all 8 standard directories. Each has a specific purpose. Empty directories are gitignored by default — only add files/ and templates/ when needed. Keep roles focused on a single responsibility.
Step 2: Understand Role Directory Structure
📸 Verified Output:
💡 Tip: Key distinction: defaults/ variables have the lowest priority and are easily overridden. vars/ variables have higher priority and should only be changed intentionally. Use defaults/ for user-configurable settings and vars/ for internal role constants.
Step 3: Build a Complete webserver Role
📸 Verified Output:
💡 Tip: Templates go in templates/ with .j2 extension. Static files go in files/. The template module processes Jinja2; the copy module copies files verbatim. Always use notify in tasks that change configs to trigger handler restarts.
Step 4: Role Dependencies in meta/main.yml
📸 Verified Output:
💡 Tip: Dependency chains are resolved automatically. If multiple roles depend on the same role, Ansible deduplicates — a role only runs once unless allow_duplicates: true is set in its meta/main.yml. Use this carefully to avoid repeated package installations.
Step 5: Using Roles in Playbooks
📸 Verified Output:
💡 Tip:pre_tasks run before roles, roles run in order, post_tasks run last. Use pre_tasks for validation checks (assert module) and post_tasks for smoke tests. Tags on roles let you run selective parts: ansible-playbook site.yml --tags web.
Step 6: requirements.yml — Install from Galaxy
📸 Verified Output:
💡 Tip: Commit requirements.yml to version control but NOT the installed roles directory. Add roles/ to .gitignore and install with ansible-galaxy install -r requirements.yml in your CI pipeline. This keeps your repo small and versions explicit.
Step 7: Role Tags and Testing
📸 Verified Output:
💡 Tip: Tag individual tasks AND the role in the playbook. --tags configure runs only configure-tagged tasks. --skip-tags deploy runs everything except deploy tasks. Special tags always and never control tasks that always run or only run when explicitly requested.
Step 8: Capstone — Multi-tier Application Role Structure
Scenario: You're architecting a 3-tier application (web/app/db) for your company. Design and validate a complete role hierarchy with proper dependencies, variable defaults, and tags.
📸 Verified Output:
💡 Tip: Notice that common and security ran only once even though both webserver and database depend on them — Ansible deduplicates dependencies by default. This is the primary benefit of using role dependencies over manually repeating tasks.