Inventory file allow to describe your OBM infrastructure.
For more information about inventory files, please refer to Ansible's dedicated documentation.
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
#
[obmfullservers]
obm.example.com
[directoryservers]
[certservers]
[nosqlservers]
[dbservers]
[webservers]
[javaservers]
[cyrusmupdateservers]
[cyrusbackservers]
[cyrusfrontservers]
[smtpservers]
As you probably know if you've read Ansible's dedicated documentation, inventory files are a kind of INI files where you can find groups between brackets and hosts.
This sample inventory allows you to deploy a single OBM host supporting all services by simply replacing obm.example.com with your own hostname in the obmfull group.
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
#
[obmfullservers]
[directoryservers]
obm.example.com
[certservers]
obm.example.com
[nosqlservers]
obm.example.com
[dbservers]
database.example.com
[webservers]
obm.example.com
[javaservers]
obm.example.com
[cyrusmupdateservers]
[cyrusbackservers]
obm.example.com
[cyrusfrontservers]
[smtpservers]
obm.example.com
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.
The problem is that 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.
Some of the groups in the second part must contain only one host but in other, you can put more than one.
To see a detailed list of all roles and their corresponding groups, please refer to roles reference.
Here is a common example of distributed installation for large deployments :
# Distributed inventory example
[caservers]
ldap.example.com
[autoconfservers]
java.example.com
[databaseservers]
db.example.com
[ldapservers:children]
ldap.example.com
[uiservers]
obm-ui.example.com
[webmailservers]
obm-ui.example.com
[syncservers]
obm-sync.example.com
[solrservers]
java.example.com
[cassandraservers]
cassandra1.example.com
cassandra2.example.com
cassandra3.example.com
[opushservers]
opush.example.com
[spushnikservers]
java.example.com
[cyrusmurderservers]
cyrus-murder.example.com
[cyrusfrontendservers]
cyrus-front1.example.com
cyrus-front2.example.com
[cyrusbackendservers]
cyrus-back1.example.com
cyrus-back2.example.com
[postfixservers]
smtp1.example.com
smtp2.example.com