Introducing Opstools-ansible
Ansible
Ansible is an agentless, declarative configuration management tool. Ansible can be used to install and configure packages on a wide variety of targets. Targets are defined in the inventory file for Ansible to apply the predefined actions. Actions are defined as playbooks or sometime roles in the form of YAML files. Details of Ansible can be found here.
Opstools-ansible
The project opstools-ansible hosted in Github is to use Ansible to configure an environment that provides the support of opstools, namely centralized logging and analysis, availability monitoring, and performance monitoring.
One prerequisite to run opstools-ansible is that the servers have to be running with CentOS 7 or RHEL 7 (or a compatible distribution).
Inventory file
These servers are to be defined in the inventory file with reference structure to this file that defines 3 high level host groups:
am_hosts
pm_hosts
logging_host
There are lower level host groups but documentation stated that they are not tested.
Configuration File
Once the inventory file is defined, the Ansible configuration files can be used to tailor to individual needs. The READM.rst file for opstools-ansible suggests the following as an example:
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—–
If there is no Ansible configuration file to tune the system, the default settings/options are applied.
Playbooks and roles
The playbook specifies what packages are to be installed in for the opstools environment by Ansible. Basically, the packages to be installed are:
ElasticSearch
Fluentd
Kibana
Redis
RabbitMQ
Sensu
Uchiwa
CollectD
Grafana
Besides the above packages, opstools-ansible playbook also applies these additional roles
Firewall – this role manages the firewall rules for the servers.
Prereqs – this role checks and installs all the dependency packages such as python-netaddr or libselinux-python … etc. for the successful installation of opstools.
Repos – this is a collection of roles for configuring additional package repositories.
Chrony – this role installs and configures the NTP client to make sure the time in each server is in sync with each other.
opstools environment
Once these are done, we can simply apply the following command to create the opstools environment:
ansible-playbook playbook.yml -e @config.yml
TripleO Integration
TripleO (OpenStack on OpenStack) has the concept of Undercloud and Overcloud
Undercloud : for deployment, configuration and management of OpenStack nodes.
Overcloud : the actual OpenStack cluster that is consumed by user.
RedHat has an in-depth blog post on TripleO and OpenStack has this document on contributing and installing TripleO
When opstools is installed at the TripleO Undercloud, the OpenStack instances running on the Overcloud can be configured to run the opstools service when it deployed. For example:
openstack overcloud deploy …
-e /usr/share/openstack-tripleo-heat-templates/environments/monitoring-environment.yaml
-e /usr/share/openstack-tripleo-heat-templates/environments/logging-environment.yaml
-e params.yaml
There are only 3 steps to integrate opstools with TripleO with opstools-ansible. Detail of the steps can be found here.
Use opstools-ansible to create the opstools environment at the Undercloud.
Create the params.yaml for TripleO to points to the Sensu and Fluentd agents at the opstools hosts.
Deploy with the “openstack overcloud deploy …” command.
Quelle: RDO
Published by