# How do you structure Playbooks to Handle Managing Many Applications with Many Environments? **URL:** \ **Category:** Ansible Project\ **Created:** [October 17, 2015, 7:25pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536 "2015-10-17T19:25:35Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Corwin\_Brown](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Corwin\_Brown](https://forum.ansible.com/u/Corwin_Brown)\ **Post date:** [October 17, 2015, 7:25pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/1 "2015-10-17T19:25:35Z")
Hey guys, I hope this is the right place to ask for advice! If not, let me know and I’ll mosey along ---
**Author:** ![Markus\_Ellers](https://avatars.discourse-cdn.com/v4/letter/m/35a633/32.png) [@Markus\_Ellers](https://forum.ansible.com/u/Markus_Ellers)\ **Post date:** [October 18, 2015, 7:21pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/2 "2015-10-18T19:21:14Z")
I would recommend having different inventory files for different environments and structure everything else withing those files according to your needs. This way a user always has to specify at least the environment on the cli. Any futher limiting can be done via the --limit parameter and you should structure you groups (and maybe groups of groups) so that your users can easily limit them as needed. ---
**Author:** ![John\_McNulty](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@John\_McNulty](https://forum.ansible.com/u/John_McNulty)\ **Post date:** [October 18, 2015, 11:02pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/3 "2015-10-18T23:02:34Z")
What we do is this: **Playbooks** Each host must contain a list variable called (e.g.) apps\_list in its host\_vars file. This will usually be just one application, but could be more that one if you install multiple apps on one server (e.g. different application DBs on a single DB server). There is one single playbook that acts as the entry point for everything; let’s call it “run.yml”. Hosts (or host groups) are passed in via extra\_vars. The first “hosts” block iterates over each host, then loops over the application name(s) in the apps\_list, and adds that host to a dynamic group of the same name. All application playbooks are then listed and using the include directive. Each application playbook uses a hard coded “hosts” group name that exactly matches the dynamic groups names that (potentially) were created by the opening host block. Each included application playbook only executes if there is a matching host group present, in scope, with any hosts in it. Let me show you what I mean. ` ---
**Author:** ![Javier\_Palacios](https://avatars.discourse-cdn.com/v4/letter/j/67e7ee/32.png) [@Javier\_Palacios](https://forum.ansible.com/u/Javier_Palacios)\ **Post date:** [October 19, 2015, 9:05am UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/4 "2015-10-19T09:05:55Z")
My opinion is that there should be only one inventory. To achieve this we have an inventory with multiple axes, so that every host is member of a few groups (typically for the running app and the environment). This still requires “duplicated” playbooks, because the hosts must be explicit there, but allows you to manage the “real” playbook in an separate file. With this approach, the playbooks look like - hosts: production:&database include: database.yml ---
**Author:** ![Corwin\_Brown](https://avatars.discourse-cdn.com/v4/letter/c/d6d6ee/32.png) [@Corwin\_Brown](https://forum.ansible.com/u/Corwin_Brown)\ **Post date:** [October 19, 2015, 1:42pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/5 "2015-10-19T13:42:50Z")
John McNulty: That is clever, I really dig that! We handle the puppet deployments (Which I’m currently replacing, one by one) in a very similar manner, so just porting that process over makes a lot of sense. Do you just maintain all of that information in flat files on disk, or in a database somewhere? I would fear that as the infrastructure grew it would become difficult to manage – granted that information has to live somewhere. I would need to support multiple instances/installs of an application, but I think that could be doable… You’ve kind of blown my mind, I need to think all that over a bit. As far as sticking my foot in the water, believe me I want to take Puppet out of the picture ASAP – it’s the rest of the team that needs convincing. My plan is to carve away at Puppets responsibilities until I can cut it out entirely. Thanks for the tip about Collins, too! I had actually been checking it out yesterday as a replacement. The teams inclination is to roll our own, but as we have a lot of work to do with limited resources I’m trying to push us away from that. Dammit man, now I have to re-architect all my Ansible code 😛 ---
**Author:** ![Javier\_Palacios](https://avatars.discourse-cdn.com/v4/letter/j/67e7ee/32.png) [@Javier\_Palacios](https://forum.ansible.com/u/Javier_Palacios)\ **Post date:** [October 19, 2015, 3:34pm UTC](https://forum.ansible.com/t/how-do-you-structure-playbooks-to-handle-managing-many-applications-with-many-environments/19536/6 "2015-10-19T15:34:20Z")
For now, it is only on the inventory itself. I use a directory for inventory, so that each individual group has its own file. That implies less management overhead that a single file, and makes very easy add new nodes just by dropping their names in the proper files (although removal is not so straightforward). For large deployments a database (I prefer LDAP) could be good permanent storage, but in our case we are not on that way yet, because the inventory is not too hard to construct from scratch using node names and some EC2 tags that we define. Javier Palacios