Ansible Roles & Best Practices: — From Copy-Paste Tasks to Reusable Automation

① Why roles — copy-paste tasks don't scale or share

Picture Sneha, an L1 automation engineer at Infosys. She started with one tidy playbook to configure a router: set NTP, push a login banner, enable SNMP. It worked. Then she needed the same on app servers, then db servers, so she copy-pasted the block. Six months later her site.yml is 600 lines, the same three tasks appear in four places, and when the security team changes the SNMP community string she has to find and edit it in every copy — and inevitably misses one. That missed copy is now configuration drift.

This is the wall every beginner hits. A long playbook with repeated blocks has three problems baked in: a single change means editing many places (and missing some), you can't lift the logic into the next project without copy-pasting again, and there's no clean way for someone else to tweak one setting without rewriting your tasks. The fix isn't discipline — it's structure.

A role packages all the moving parts of one job — tasks + handlers + templates + defaults + vars + files + meta — into a single folder with a fixed layout. You write the logic once, then include the role from any playbook in any project. Better still, the community publishes roles on Ansible Galaxy, so for common jobs (NTP, nginx, Docker) you often don't write a role at all — you pull a battle-tested one and just override its knobs.

You don't hand-create those folders. The bundled ansible-galaxy tool scaffolds the whole skeleton for you: ansible-galaxy role init base_net creates roles/base_net/ with tasks/, handlers/, defaults/, vars/, templates/, files/, meta/ and a starter main.yml in each, plus a README.md. From there you fill in only the folders you actually use — empty ones can be deleted. That convention is the whole point: Ansible knows where to look, so you never write file paths for handlers, templates or defaults.

Why a role beats a long playbook — one tap each

Tap each card. These four are the reasons every team eventually moves repeated tasks into roles.

② Inside a role — the folders, defaults vs vars, and precedence

Open any role and you meet the same folders. tasks/main.yml is the entry point — the list of tasks Ansible runs when the role is invoked. handlers/main.yml holds handlers (the restart-style tasks fired by notify). templates/ holds Jinja2 .j2 files that the template module renders; files/ holds static files the copy module ships as-is. meta/main.yml declares the role's dependencies and its Galaxy metadata.

The two folders people confuse are defaults/main.yml and vars/main.yml — and getting them right is the single most useful thing in this lesson. defaults/ holds the role's knobs: sensible default values that any user can override from inventory, a playbook, or the command line, because they sit at the very bottom of the precedence ladder. vars/ holds internal constants the role needs but users shouldn't change — they sit high in precedence, so they're hard to override on purpose.

Ansible resolves a variable by walking a precedence order of about 22 levels. You don't memorise all 22 — you anchor the four that matter for roles. From weakest to strongest: role defaults (the floor) → inventory group_vars / host_vars (how each site overrides) → play vars → role vars (high) → role parameters → extra-vars with -e (always wins). So a value in defaults/main.yml is beaten by almost anything, which is exactly why your overridable knobs go there; a value in vars/main.yml beats inventory, which is why user knobs must not go there.

# Lowest precedence — sensible defaults, overridden per site
ntp_server: 10.0.0.123
snmp_community: techclick-ro
banner_text: "Authorized access only."
syslog_host: 172.16.5.10

# (data file — no output. Confirm Ansible sees it:)
$ ansible -m debug -a "var=ntp_server" localhost
localhost | SUCCESS => {
    "ntp_server": "10.0.0.123"
}

③ Best practices — name, lint, tag, and pin

A role that works is not the same as a role that's good. The habits below are what separate a junior's first role from one a team will actually adopt — and they're exactly the things ansible-lint and the RHCE exam check. Start with the cheapest, highest-value one: name every task. An unnamed task shows up as an opaque TASK [command] line in the output; a named task reads like documentation and is what ansible-lint's name[missing] rule enforces.

Use handlers for restarts. Don't restart a service inline after every change — notify a handler instead, so the restart runs once, at the end of the play, and only if something actually changed. Keep each role single-purpose. A role called base_net sets baseline network config; it shouldn't also deploy your app. Small, focused roles compose; a do-everything role can't be reused. Tag your tasks so an operator can run just one part: ansible-playbook site.yml --tags ntp re-applies only the NTP tasks during a 2 a.m. change window instead of the whole role.

Prefer real modules over command/shell. Modules like ansible.builtin.lineinfile or ansible.builtin.service are idempotent out of the box: they only change things when needed and report ok otherwise. A raw command or shell task can't know whether it changed anything, so Ansible flags it changed every run — which breaks idempotency and trips the no-changed-when lint rule. When you genuinely must use command, tell Ansible the truth with changed_when (and failed_when for what counts as failure).

Lint with ansible-lint. It's a free command-line tool that checks your role against a default ruleset — missing names, non-idempotent commands, deprecated modules, risky shell usage — and you wire it into CI so problems are caught before merge, not in production. Distribute via collections and roles. A collection bundles roles + modules + plugins under a namespace (e.g. cisco.ios); you list both roles and collections in a requirements.yml and install them with ansible-galaxy install -r requirements.yml.

Pin versions in requirements.yml. Installing a role without a version is like running apt install with no version — fine today, broken six months from now when an upstream change lands. Lock the exact version: for every role and collection so your automation is reproducible on any machine at any time. This isn't just stability — it's security, as the next callout shows.

---
- name: Set the NTP server
  ansible.builtin.template:
    src: ntp.conf.j2
    dest: /etc/ntp.conf
  notify: Restart ntp
  tags: [ntp]

- name: Push the login banner
  ansible.builtin.copy:
    src: banner.txt
    dest: /etc/issue.net
  tags: [banner]

- name: Confirm NTP is in sync (read-only check, never a change)
  ansible.builtin.command: ntpq -p
  register: ntp_status
  changed_when: false
  failed_when: "'no association' in ntp_status.stdout"
  tags: [ntp, verify]

TASK [base_net : Set the NTP server] *******************
changed: [br-mumbai-rtr]
TASK [base_net : Push the login banner] ****************
ok: [br-mumbai-rtr]
TASK [base_net : Confirm NTP is in sync ...] ***********
ok: [br-mumbai-rtr]
RUNNING HANDLER [base_net : Restart ntp] ***************
changed: [br-mumbai-rtr]

ram@netauto:~/playbooks$ ansible-lint roles/base_net

WARNING  Listing 1 violation(s) that are fatal
no-changed-when: Commands should not change things if nothing needs doing
roles/base_net/tasks/main.yml:14 Task/Handler: Restart snmpd

Read documentation for instructions on how to ignore specific rule violations.
Failed: 1 failure(s), 0 warning(s) on 12 files.

④ A real role — base network config, overridden per site

Let's build the role Sneha actually needed: a single-purpose base_net role that applies baseline config to every network device — NTP, a login banner, SNMP, and AAA — and that each site can tune via group_vars without forking the role. This is the shape of question the RHCE EX294 puts in front of you, and the pattern you'll use on day one of a support desk.

The role exposes its knobs in defaults/main.yml (NTP server, SNMP community, banner text, syslog host — the file you saw in section 2). The Mumbai site overrides two of them in group_vars/mumbai.yml; the Pune site overrides different ones in group_vars/pune.yml. Same role, two behaviours, zero copy-paste. Each task is named, tagged, uses a module (so it's idempotent), and the one command verify task carries changed_when: false. Restarts go through a handler.

# These beat roles/base_net/defaults/main.yml (inventory > role defaults)
ntp_server: 10.10.1.123
snmp_community: mumbai-ro
syslog_host: 10.10.1.10
# banner_text not set here → role default is used

# (data file — confirm the effective value on a Mumbai host:)
$ ansible br-mumbai-rtr -m debug -a "var=ntp_server"
br-mumbai-rtr | SUCCESS => {
    "ntp_server": "10.10.1.123"
}

---
- name: Apply baseline network config to all edge routers
  hosts: edge_routers
  gather_facts: false
  roles:
    - role: base_net
      tags: [base_net]

PLAY [Apply baseline network config to all edge routers] *
TASK [base_net : Set the NTP server] *********************
changed: [br-mumbai-rtr]
ok: [br-pune-rtr]
TASK [base_net : Configure SNMP] ************************
changed: [br-mumbai-rtr]
changed: [br-pune-rtr]

For the cert path, this lesson maps straight onto the RHCE EX294 blueprint. "Create and use roles" and "Install roles and use them in playbooks" are explicit objectives, and the modern exam expects you to scaffold with ansible-galaxy, override variables cleanly, and write idempotent, named, tagged tasks — exactly what you just did. The 2026 exam also leans on the newer toolset (ansible-navigator and execution environments) for running and inspecting content, but the role structure itself is unchanged. Nail roles and a sizeable chunk of the practical exam is muscle memory.