Organizing different operations within roles

Archives Ansible Project
1

Hi all,

We have been using ansible for a while now and have created a bunch of roles which are working really well. We have been really enjoying the way ansible works, and that it is easily extensible for those bits that are not generic.

Up until now we have been busy with creating things, ec2 instances with disks and an initial install etc. So all our roles for the most part are about creating things. The next step is for the maintenance, i.e. updating and removing/deleting. So, for instance we have a continuous integration chain that creates instances for testing, and now I want to set up a series of tasks that remove these instances when the branch is merged. The question is how best to organize these different operations on the same function or role. So, we are calling our full system a silo. It has a db, web servers (nodejs), nginx dispatching etc. For a bunch of these roles we will now have two separate operations, and will be adding an update to others, how are people handling this, as I cannot believe we are the first by any stretch. :slight_smile:

The roles are ideally a flat set of directories within the roles directory, but what we actually want is something like this.

  • silo create
  • silo remove
  • silo delete

I have thought about resorting to paths in the calls to roles and having a higherarchical directory structure, e.g.

roles/
silo/
create/
remove/
update/

This has some advantages and disadvantages:

  • The update and create roles would be very similar as far as role dependencies but this would have to be duplicated, but it would mean that remove would not be worrying about running extra dependencies.

  • Just calling a silo role by name would no longer work, and specific paths would have to be given, so a bunch of the nice out of the box convention over configuration would break.

I would love some advice, because our needs are only going to get more complicated. Are people using tags for this sort of thing? Are there some hidden features I am missing, or a better way of looking at the setup?

Thanks in advance for any help,

Rohan Nicholls

2

​With this structure, your role name really is e.g. "silo/create"​, which I
use myself often, I don't see any downsides to that.

Also, if update and create are very similar, only differing by a couple of
tasks, you could consider using conditionals on a role parameter, e.g.
when: function == update?

Serge

3

That is good to know. Thanks for the tip.

I have beet trying it out and found that there are some of our roles that have to use templates in other roles which is proving a challenge.

Because of course the other role does not know if it is dealing with a two tiered “role” or a vanilla role, so this does have to be set explicitly. Why am I using something like this? We have a role that handles nginx configuration for a dispatching frontend. It makes sense to keep the nginx template in the role for the particular machine and keep the dispatcher configuration role generic, so it only needs to know that it takes a template and pops it onto the dispatching machine. It is given the name of the role, and some other parameters and needs to know nothing more about what it is doing, and therefore can be used by lots of other roles. Anyway that gives an idea of why we want to keep the specifics in the machine role and keep the other role generic.

A bit of tweaking and this will be fixed. Thanks again for the advice.

Rohan