2
votes

We are trying to design an Ansible system for our crew.

We have some open questions that cause us to stop and think and maybe hear other ideas.

The details:

  • 4 development teams.
  • We hold CI servers, DB servers, and a personal virtual machine for each programer.
  • A new programer receives a clean VM and we would like to use Ansible to "prepare" it for him according to team he is about to join.
  • We also want to use Ansible for weekly updates (when needed) on some VMs - it might be for a whole team or for all our VMs.
  • Team A and Team B shares some of their needs (for example, they both use Django) but there are naturally applications that Team A uses and Team B does not.

What we have done:

  • We had old "maintenance" bash scripts that we translate to YAML scripts.
  • We grouped them into Ansible roles
  • We have an inventory file which contains group for each team and our servers:

`

[ALL:children]
Team A
Team B
...

[Team A]
...

[Team B]
...

[CIservers]
...

[DBservers]
...
  • We have large playbook that contains all our roles (with tag to each):

    - hosts: ALL roles: - { role x, tags: 'x' } - { role y, tags: 'y' } ...

  • We invoke Ansible like that:

    ansible-playbook -i inventory -t TAG1,TAG2 -l TeamA play.yml

The Problems:

  • We have a feeling we are not using roles as we should. We ended up with roles like "mercurial" or "eclipse" that install and configure (add aliases, edit PATH, creates symbolic links, etc) and role for apt_packages (using apt module to install the packages we need) and role for pip_packages (using pip module to install the packages we need).
  • Some of our roles depends on other roles (we used the meta folder to declare those dependencies). Because our playbook contains all the roles we have, when we run it without tags (on a new programer VM for example) the roles that other roles depends on are running twice (or more) and it is a waste of time. We taught to remove the roles that other depends on from our playbook, but it is not a good solution because in this way we loose the ability to run that role by itself.

We are not sure how to continue from this point. Whether to yield roles dependencies and create playbooks that implement those dependencies by specify the roles in the right order. Should we change our roles into something like TeamA or DBserver that will unite many of our current roles (in such case, how do we handle the common tasks between TeamA and TeamB and how do we handle the tasks that relevant only for TeamA?)

Well, that is about everything.

Thanks in advance!

2

2 Answers

0
votes

Sorry for the late answer and I guess your team has probably figured out the solution by now. I suspect you'll have the standard ansible structure with group_vars, hosts_vars, a roles folder and a site.yml as outlines below

site.yml
group_vars
host_vars
roles
    common
    dbserver
    ciserver

I suspect your team is attempting to link everything into a single site.yml file. This is fine for the common tasks which operate based on roles and tags. I suggest for those edge cases, you create a second or third playbook at the root level, which can be specific to a team or a weekly deployment. In this case, you can still keep the common tasks in the standard structure, but you are not complicating your tasks with all the meta stuff.

site.yml // the standard ansible way
teamb.yml // we need to do something slightly different  

Again, as you spot better ways of implementing a task, the playbooks can be refactored and tasks moved from the specific files to the standard roles

0
votes

Seems you are still trying to see whats the best way to use ansible when you have multiple teams which will work on the same and don't want to affect others task. Have a look at this boilerplate it might help.

If you look in that repo. You will see there are multiple roles and you can design the playbook as per your requirement.

Example: - common.yml (This will be common between all the team) - Else you can create using by teamname.yml or project.yml

If you use any of the above you just need to define the proper role in the playbook & it should associate with the right host & group vars.