I'm interested in the best practices for multiple inventories with multiple 'group_vars' also. I've implemented a solution like this and found it cumbersome to have a default set of group_vars that were shared between the inventories.
I guess from what I've written, it would make sense to set the defaults for roles to be what are the default for our group_vars but it does include a lot of information that is particular to the organisation which isn't appropriate for galaxy roles. I guess another other would be constantly including a var_file for each play... This doesn't feel like the right way to do it though. Can anyone share experiences on setting this up in a scalable, manageable way? On 10 May 2016 at 22:27, 'J Hawkesworth' via Ansible Project < ansible-project@googlegroups.com> wrote: > I don't know what other people do - I suspect it varies a lot according to > use and team size - ansible is very flexible after all, but for what its > worth I moved all my playbooks out of root and into dirs a while ago as > they were getting out of control too. > > I have dirs like > > plays/provision (putting the software stack in place for each type of > server) > plays/update (install latest versions of software components) > plays/untested (where I work up new plays) > plays/operations (check things, rolling restarts etc) > > I do however keep all my roles in a single roles dir and so far have > managed not to have any roles which are 'private' to the playbook dirs. To > me this maximizes the re-use I can get out of roles. > I make use of playbook includes to run multiple playbooks where > appropriate in some cases too. > > As far as vars are concerned I have several inventory files and at least 1 > group_vars (directory) per inventory so I can set vars for each environment > independently, where necessary. > > Hope this helps > > Jon > > > On Wednesday, May 11, 2016 at 12:34:28 AM UTC+1, James Pearson Hughes > wrote: >> >> As our company is growing and our use of Ansible grows with it, we're >> starting to struggle a bit with organization of our Ansible configs. The >> primary problem is that while we have things organized according to the >> documented best practices, those docs put all the playbooks at the root >> level, and we're starting to get many of those. >> >> Each playbook is fairly simple - a few chunks of code for provisioning an >> instance, a few chunks for setting up the firewall rules, and a list of >> roles to apply to the servers. However, this is enough stuff that it's a >> bit messy including all of these in one giant file, so we have them split >> out by group, with a top-level file that includes them all. This also >> helps speed things up quite a bit, as we can run only the playbook we've >> changed, rather than check every single piece of configuration on every >> single server in the fleet. >> >> However, since we're getting a lot of different services we're >> supporting, this ends up with a lot of different playbooks hanging out in >> the root. If we put them in a subredirectory, then they can no longer >> access the roles, variables, etc. >> >> So far, the options I've considered are: >> >> 1. Deal with it as-is. >> 2. Move everything into one playbook (less than ideal, for the reasons >> stated above). >> 3. Move them into a directory structure and write a wrapper around >> ansible that adjusts ANSIBLE_CONFIG etc. to point to the correct places. >> 4. Split up our entire ansible directory structure into separate >> components, each with their own roles, vars, etc. and put common shared >> functionality into a separate location that's then pointed to by roles_path. >> 5. Move everything into one playbook and use tags to allow us to >> easily-ish run only certain projects' configuration. >> >> Is there a community consensus on how to handle organization when >> supporting a large number of mostly disparate apps? >> > -- > 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 ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/0a4c65e8-fb72-46a6-b01d-57cc44a918da%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/0a4c65e8-fb72-46a6-b01d-57cc44a918da%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Steve -- 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BemtqsQTNVVKSOuLWK77oMLuwe1LQWLjH_vZnj9x-aOx7kmcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
