1

Description

The Ansible content organization documentation only talks about a single project with multiple staging environments.

That is great and all, but I need to manage many projects that will be reusing a lot of the same Ansible roles. Should I build a single roles directory and have all of the project specific playbooks point at a "shared" roles directory. Or should each project have a dedicated roles directory containing only the roles related to the project. Below are some of the pros and cons I have thought of for both:

Shared roles directory

Pros:

  • All roles are in one single location.
  • For roles that are shared across multiple projects, the role version upgrade will be applied to all projects that depends on it.

Cons:

  • For roles that are shared across multiple projects, a role version change will need to be tested in every project, even if it is not the project you are working on.

Dedicated roles directory

Pros:

  • It is clear what roles are needed to run a specific project.
  • A role version upgrade can be applied to specific projects that require the upgrade.

Cons:

  • Common roles are copied/cloned many times. However, using ansible-galaxy with requirements.yml file will handle the managment of roles and role dependencies for us.

Question

Has anyone had success with either of this organization strategies?

aidanmelen
  • 6,194
  • 1
  • 23
  • 24

2 Answers2

1

You've done already a great job with your analysis, outlining most of the elements to take a decision.

Allow me to add a few more considerations.

In general I the right answer has less to do with ansible and more to do with how you're organizing the development of your scripts and roles. Specially in terms what changes when... the different projects and also the different roles.

In an environment where everything evolves disconnected from everything else, you might want to go ansible-galaxy-like (but with your own local repositories). In this scenario you develop the projects' playbooks independently and they reuse the roles defined in the project's requirements.yml. Changes to the roles can be posted to your private galaxy and versioned so that other projects can decide to upgrade or to keep their current version. Roles can be pulled from one or different repositories, but only those required are pulled for each project using the galaxy commands.

In other extreme, if all the projects in your environment evolve in sync, then a central approach will work better as you will have less moving parts. Everything (all roles and playbooks for the different projects) can be stored in a single repository.

jsantander
  • 4,972
  • 16
  • 27
-1

At my previous workplace we implemented different playbooks for each microservice. There were about 30 services in production and another 15 in development. Updating and managing the .yml files was not too much of a problem as yaml files are usually short and easy to read.

I'd say it probably depends on how many services, environments as well as developers you are working with!

HaDoMin
  • 171
  • 4
  • 12
  • I think of playbooks as a mechanism that provides specific configuration to generic roles. My question is about managing the generic roles. If you have 30 sites, you will need ~30 playbooks. I don't think there is a way around that. I am interested in how the roles are managed for many projects. – aidanmelen Sep 10 '18 at 16:49