> > 18 month later I'm still struggling with > https://groups.google.com/forum/#!topic/ansible-project/VeQUdekccQ4 > issue.
I'd like to come up with another example to make clear what's the problem I'm dealing with. Maybe there's someone who can help and share his own practices to circumvent the weaknesses of my approach Let's imagine I'm a system adminstrator at a large IT company and running a few „internal“ machines for providing internal services like backup (e.g. Bareos) and monitoring (e.g. Icinga2). My customers are coworkers who group together into various project teams. Now I want to use Ansible to automate the following tasks: 1. Manage my internal services (backup, monitoring) 2. Manage the customers' servers in the meaning of installing and configuration platform services and applications 3. Manage the custimers' servers in the meaning of integrating them with my internal services (backup, monitoring) The first thing I do is to create an inventory per customer and a inventory for me: inventories/ - myself - customer-a - customer-b - customer-c I'm using groups inside the inventories to group systems by their technology. For instance: *tomcat-servers, httpd-servers* In my own inventory there are some groups like *icinga2-servers, bareos-servers *which group together my internal services. To provision a server, I'm using a „top down approach“ for designing my playbooks. This means that I've something like „private playbooks“, which are not meant to run directly but imported into „public playbooks“ So a playbook called *icinga2.yml *will import a private role *_base.yml *as the base role will handle common tasks for the way I set up a typical machine. *icinga2.yml *itself will install the role *icinga2-server *for the members of group *icinga2-servers* and install clients for all members of the group *icinga2-clients*. At the moment I'm defining the group *icinga2-clients* multiple times in each of the inventory file. But this leads to following weaknesses: 1. I've no single file which shows up all members of the group 2. When I have to redefine a host because I cannot refer to a group (e.g. *icinga2-clients:children*) I'm not DRY anymore when it comes to defining inventory variables or connection details (like *ansible_user*) 3. This works only as long theres a 1:n membership - but think of multiple postgresql-servers which form several clusters (e.g. 2-3 clusters per customer) - how should this be declared? The problem here is that there a 1:n association from the perspective of the group (group:hosts). But in my opinion it should be the other way around. It should be a 1:n association like host:groups. At the time of writing I'm thinking of a way to build something like this by utilizing inventory vars (e.g. host ansible_groups=group-a,group-b,group-c) Already thought about: Using „a repository per customer“ does not work because of the separated scopes / facts when it comes to integration of systems from the outside (e.g. from another inventory). Using „a repository per technology“ does not work also because it ends up with defining one hosts multiple times in several files. Maybe specific „memberships“ should not be implemented as a group membership. Maybe using host_vars is the better approach. What do you think? What's your best practice to achieve this? Yves -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1798aeb2-6dd2-4390-be5f-c04e2c670907%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
