We have an cluster of windows machines and there are two types: web and esb
And on these machines we have multiple jboss installations (one for each application). And we want to manipulate the jboss instances with an ansible-playbook.
So I created an inventory but I can not get it right.
There are probably several ways of doing this and it would probably be best if you experiment a bit to find out what makes most sense for you.
Personally I am more familiar with the ‘ini’ style of inventory so I’m not sure what problem you are really facing with the inventory.
It might be easier to understand if you shared a playbook that illustrated the problem.
One trick you can use while you are experimenting with inventory is to use ‘ansible-inventory --list --yaml’ which will dump out the parsed inventory.
Personally I would probably not try to model individual applications as part of inventory - to me, inventory is really about what machines you have.
I might use host_vars or group_vars to record which jboss applications are on which hosts or groups of hosts. If you have long lists of applications though, that might get tedious if you have to loop through lots of them every time you need to update just one or two applications.
One way to get round that might be to make a role which takes a parameter which controls which application is to be updated. I imagine a lot of the steps to deploy a jboss application will be the same regardless of which application is being deployed and which jboss instance it is being deployed to.
So I think it would be worth trying to come up with the playbook(s) you want to use against your jboss instances but be prepared to re-visit your inventory.
Also it might be worth thinking about what you are optimizing for. It sounds like you are attempting to keep the number of windows instances down to a minimum but also maintain a high level of isolation between your web applications (if not you could perhaps run some of them inside the same jboss instance). If you have flexibility to change that (or need to change it so you can run say development or test applications in a different configuration from production), that’s another thing to bear in mind when writing playbooks. Our team was able to consolidate a number of web apps into a single web app which let us reduce start up times massively, which was important for us at the time.