Why Roles?
The closing chapter of the previous section built a genuinely comprehensive deployment playbook — directory prep, OS-conditional installation, discovered config files, a templated main config, a surgical tuning tweak, resilient error handling, and a post-restart health check. It’s also exactly the kind of thing that’s crying out to become something more reusable than one long play.
The Problem With One Long Playbook
That playbook works — but every specific detail inside it is hardcoded: the app is always myapp, the config path is always /etc/myapp/app.conf, the service name is always myapp. It solves exactly one deployment, once.
What If You Needed To Deploy Two Different Apps?
Imagine needing that same overall pattern — install a package, template, its config, restart the service, verify it’s healthy — for a second, completely different application. The only option right now would be copying the entire play and manually changing every hardcoded detail by hand. That’s genuinely painful, error-prone the moment you miss updating one of the hardcoded values, and impossible to keep consistent: fix a bug in the pattern later, and you’d have to remember to apply that same fix to every copy separately.
This is exactly the same shape of problem loop: solved for repeated tasks, and handlers solved for repeated notify targets — repeated structure, differing only in the specific data plugged into it. A role is the equivalent solution, scaled up to an entire workflow instead of a single task.
What A Role Actually Is
A role is a predefined directory structure that packages tasks, handlers, templates, files, and default variables together as one reusable, nameable unit. Instead of one giant play with everything hardcoded, a role encapsulates “how to deploy an application of this general shape,” parameterized by variables — and the exact same role can then be applied to as many different applications, hosts, or configurations as needed, just by changing which variables feed into it.
The Promise Of This Section
By the end of this section, you’ll take that exact deployment playbook from the previous section’s close and refactor it into a proper role, piece by piece — the closing chapter here is literally that exercise. Everything between now and then is building toward being able to do that confidently.
Early Guidance
Keep the previous section’s “Full Synthesis” playbook in mind throughout this section — every new piece of role structure covered from here on is something that playbook genuinely needs, and seeing exactly why it needs each piece will make the closing refactor feel like a natural conclusion rather than an abstract exercise.