Overview

The opstools-ansible project is a collection of Ansible roles and playbooks that will configure an environment that provides centralized logging and analysis, availability monitoring, and performance monitoring.

Using opstools-ansible

Before you begin

Before using the opstools-ansible playbook, you will need to deploy one or more servers on which you will install the opstools services. These servers will need to be running either CentOS 7 or RHEL 7 (or a compatible distribution).

These playbooks will install packages from a number of third-party repositories. The opstools-ansible developers are unable to address problems with the third party packaging (other than via working around problems in our playbooks).

Creating an inventory file

Create an Ansible inventory file inventory/hosts that defines your hosts and maps them to host groups declared in inventory/structure. For example:

server1 ansible_host=192.0.2.7 ansible_user=centos ansible_become=true
server2 ansible_host=192.0.2.15 ansible_user=centos ansible_become=true

[am_hosts]
server1

[logging_hosts]
server2

There are two high-level groups that can be used to control service placement:

  • am_hosts: The playbooks will install availability monitoring software (Sensu, Uchiwa, and support services) on these hosts.
  • logging_hosts: The playbooks will install the centralized logging stack (Elasticsearch, Kibana, Fluentd) on these hosts.

While there are more groups defined in the inventory/structure file, use of those for more granular service placement is neither tested nor supported at this time.

You can also run post-install playbook after overcloud deployment to finish server side configuration dependent on the information about the overcloud. For that you will need to add undercloud host to the inventory. So for example, after deploying overcloud via tripleo-quickstart tool, you should add something like following to the inventory file before running the playbook:

undercloud_host ansible_user=stack ansible_host=undercloud ansible_ssh_extra_args=’-F “/root/.quickstart/ssh.config.ansible”’

Create a configuration file

Put any necessary configuration into an Ansible variables file (which is just a YAML document). For example, if you wanted to enable logging via SSL, you would need a configuration file that looked like this:

fluentd_use_ssl: true
fluentd_shared_key: secret
fluentd_ca_cert: |
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
fluentd_private_key: |
  -----BEGIN RSA PRIVATE KEY-----
  ...
  -----END RSA PRIVATE KEY-----

You don’t need a configuration file if you wish to use default options.

Run the playbook

Once you have your inventory and configuration in place, you can run the playbook like this:

ansible-playbook playbook.yml -e @config.yml

Roles

The following documentation is automatically extracted from the roles directory in this distribution.

Integration with TripleO

The TripleO installer for OpenStack includes support for Fluentd and Sensu clients. See Integrating opstools-ansible with a TripleO deployment.

Contributing

If you encounter problems with or have suggestions about opstools-ansible, open an issue on our Github issue tracker.

If you would like to contribute code, documentation, or other changes to the project, please read the Contributing to opstools-ansible.

License

Copyright 2016 Red Hat, Inc.

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.