Inventory file allow to describe your OBM infrastructure.
For more information about inventory files, please refer to [Ansible's dedicated documentation](http://docs.ansible.com/intro_inventory.html "Inventory on docs.ansible.com").
#### Table of contents
- [obmfull-example inventory file](#obmfull-example-inventory-file)
- [Quick introduction](#quick-introduction)
- [First customization steps](#first-customization-steps)
- [More advanced customization](#more-advanced-customization)
- [Nested groups](#nested-groups)
- [Ansible limitation in nested groups](#ansible-limitation-in-nested-groups)
- [Focus on groups](#focus-on-groups)
- [Advanced example](#advanced-example)
obmfull-example inventory file [▲](#top-page "back to top")
This inventory is provided as an example of how to deploy OBM on a single host.
Let's take a look at the first part of the file :
# OBM-Full example inventory file
As you probably know if you've read [Ansible's dedicated documentation](http://docs.ansible.com/intro_inventory.html "Inventory on docs.ansible.com"), inventory files are a kind of INI files where you can find groups between brackets and hosts.
This example inventory allows you to deploy a single OBM host supporting all services by simply replacing obm.example.com by your own hostname in obmfull group.
First customization steps
As you can see, there are other groups with no hosts in this part of the file.
You can use them to split your deployment into more than one remote host.
For example, you can store your database on a separate server as below :
# Customized example inventory file with separated database server
That's all. Pay attention to not update the second part of file. It will be explained later.
*cyrusmupdateservers* and *cyrusfrontendservers* aren't required unless you want to deploy a Cyrus cluster.
You can now launch your deployment as usual :
$ ansible-playbook -i customized-example obm.yml
More advanced customization [▲](#top-page "back to top")
While the first part of the file is provided to simplify your life, the second part is where the magic happens.
The groups in the second part are the most important ones. Only them are associated with roles
In the obmfull-example inventory file, they are composed of nested groups from the first part.
`obmfullservers` group is contained in all of them, this is why you can install all the services on a single host using it.
A `parent` group is identified by the `:children` suffix after its name.
Ansible limitation in nested groups
The problem is you need to choose between groups of hosts or groups of groups.
Indeed, a group can't contain other groups and hosts.
To deploy a fine tuned distributed OBM infrastructure you'll need to rewrite the second part putting host names in all the groups.
Focus on groups
Some of the groups in the second part must contain only one host but in other, you can put more of them.
To see a detailed list of all roles and their corresponding groups, please refer to [roles reference](./roles.mkd "Roles reference").
Here is a common example of distributed installation for large deployments :
# Distributed inventory example