# Role encapsulation, DRY, and convention over configuration **URL:** \ **Category:** Ansible Project\ **Created:** [October 25, 2014, 9:57am UTC](https://forum.ansible.com/t/role-encapsulation-dry-and-convention-over-configuration/16609 "2014-10-25T09:57:54Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![azaghal](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/azaghal/32/4743_2.png) [@azaghal](https://forum.ansible.com/u/azaghal)\ **Post date:** [October 25, 2014, 9:57am UTC](https://forum.ansible.com/t/role-encapsulation-dry-and-convention-over-configuration/16609/1 "2014-10-25T09:57:54Z")
Hello all, I am still quite new to Ansible (but coming from Puppet background, so my perspective might be a bit skewed to top it off), and I am currently trying to figure out what would be the best way to layout roles while attempting to apply DRY (don't repeat yourself) principles as much as possible. Plus, I'm trying to have somewhat complex deployment with providing as little input as possible (kind of convention over configuration). My current goal is to deploy one or more Django projects on a single host/group of hosts. Currently I have the following roles: - common - Sets-up some basic things on the OS, amongst   other things the OS users and groups. Users and groups are read from   two list variables. - virtualenv - Sets-up Python virtual environments. Virtual   environments are read from a single list variable that includes info   about mode for files/dirs, users that should own the virtual   environment, destination directory etc. - supervisor - Sets-up supervisor for running (in this case) one or   more WSGI applications. List of supervisor configurations (apps to   monitor) is passed via list, with each item containing info about   what user should run the command, command itself etc. Now, the above should be mostly enough to deploy all the things necessary for a project (bits and pieces missing, but I'm sure I can handle those). From here, though, I am finding some issues on how to properly encapsulate this. For start, I do have an idea of a convention I want to apply for my deployments. This includes specific user/group naming based on a project name, destination directory for virtualenv etc. What I'm looking into would be being able to pass in only a couple of values via variables (let's say name, user and group) to my high-level role (or perhaps playbook), and calculate the non-specified parameters (required by roles common, virtualenv, and supervisor) from those. I would also want to deploy multiple Django projects (this is the important part) on the same host/group. 1. Try to create a new role, called django, which would basically iterate over a list of projects. The problem is that I need to pass in some relatively complex (with calculations included) structures to roles common, virtualenv, and supervisor, and variable manipulation is a bit limited within the yml files. I think I would probably be able to use include directive in combination with a custom lookup plugin. I have tried using set\_fact with with\_items to try to append to lists, but that didn't work for me (only the last item from with\_items got appended). 2. Ditch the effort for DRY and separation, and simply have one monolithic django role that'll deploy user/group, virtualenv, supervisor etc. Still, there might be some rather similar set-ups where I'd end-up duplicating all of the tasks and logic. 3. Instead of deploying through a single site.yml, use deployment-specific (one-timish) playbook. I would, however, need to somehow keep track of what Django project gets deployed where. What would be the best way to do this with Ansible? 4. Something else someone suggests from this list 🙂 Any recommendations on what would be the best way to proceed with this? I'm open to all suggestions. If someone has a good link to share, which demonstrates solution for such a deployment, that'd be appreciated as well 🙂 Best regards ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [October 25, 2014, 4:14pm UTC](https://forum.ansible.com/t/role-encapsulation-dry-and-convention-over-configuration/16609/2 "2014-10-25T16:14:38Z")
Depends on what your workplace is doing. The biggest rule about ansible is “don’t overthink it”. Having one role per application (like “appserver” or “dbserver”) is often sufficient. [Galaxy.ansible.com](http://Galaxy.ansible.com) can contain some good starting points.