CODEWITHSUNDEEP
gitansibleorganization
eatheril
eatheril

Reputation: 1

Ansible role and playbook organization for multiple products/teams

We started with ansible using the ansible best practices text, but now it is becoming unmanageable. For this reason, we are trying to re-organize our ansible structure and to divide it in multiple git repositories.

Our use case is that we have a very complex system, where there are several teams developing solutions in dedicated testing environments, where every solution includes several applications,databases, etc. Until now, everybody was using a single git repo with a single "role" and "playbook" folders. Our structure looks like this:

- group_vars
- host_vars
- inventory
- roles
   - team1_role
       - tasks
            - sqlite.yml
            - app1_1.yml 
            - app1_2.yml 
   - team2_role
       - tasks
            - sqlite.yml
            - app2_1.yml
            - app2_2.yml
   - team3_role
   -...
- playbooks
   - team1_playbook
       - team1.yml --> where this playbook install sqlite in host1, app1_1 and app1_2 in host2
       - team1_action1.yml --> where this playbook perform some maintenance activity, such as update passwords. 
   - team2_role
       - team2.yml --> where this playbook install sqlite in host3, app2_1 and app2_2 in host2
   - all.yml

After reading several webs, I see straight forward that we have to create a repository per "team_role" and a "common_role" with common things such as the sqlite.yml. For us, creating a repository per app would not have any benefit.

But, we dont know what to do with the playbooks. I only see tree options:

- team1
    - roles
    - playbooks
- team1
    - roles
    - playbooks

What would you recomend after your experience?

Solution

We finally agreed to do it using the third option. It is not the ansible best practice, but the solution of defining a colection per role does not seem to work in short term for us. Let's see if the experience does not show us that we are wrong.

Then, we are defining a single repository per team where they will write their roles and playbooks. Then we will have a repository for the common inventory (probably shared for all the teams) and a repository for common roles (in long term we migh change this to have a repository per role).

So, the final structure will be:

 - group_vars
 - host_vars
 - inventory
 - common_roles
    - sqlite.yml
 - teams
    - team1
       - roles
            - app1_1.yml 
            - app1_2.yml 
       - playbooks
            - team1.yml
    - team2
       - roles
            - app2_1.yml
            - app2_2.yml
       - playbooks
            - team2.yml
    - team3
       -...

Upvotes: 0

Views: 834

Answers (1)

HiroCereal
HiroCereal

Reputation: 631

You might benefit from using Ansible Collections

And detach roles from playbooks in two repositories. You would have:

  • Ansible Collections repository, hosting reusable roles across different teams
  • Ansible playbooks repository for each team, making use of the roles defined in the Ansible Collections repository

Everything that can be reused across more than one team and/or application, goes to the Ansible Collections repository. Everything else is stored in the repository of each team/application.

Structure of the Ansible Collections repository could be as follows:

ansible-collection/
└── myorg
    ├── database
    │   └── roles
    │       ├── mysql
    │       ├── postgresql
    │       └── sqlite
    ├── team1
    │   └── roles
    │       ├── appA
    │       └── appB
    └── team2
        └── roles
            ├── appC
            └── appD

And you make use of the roles in a playbook:

---
- hosts: host1
  tasks:
    - include_role:
        name: myorg.database.sqlite
    - include_role:
        name: myorg.team1.appA

This keeps your code DRY and empowers your organization to reuse existing code.

Upvotes: 1

Related Questions