Inventories

Inventory file allow to describe your OBM infrastructure.

For more information about inventory files, please refer to Ansible's dedicated documentation.

Table of contents


obmfull-example inventory file

This inventory is provided as an example of how to deploy OBM on a single host.

Quick introduction

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 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
#

[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

While the first part of the file is provided to simplify your life, the second part is where the magic happens.

Nested groups

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.

Advanced example

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