This is a guest blogpost from Sebastian Gumprich from T-Systems Multimedia Solutions GmbH
—
Our company is using Icinga for quite some time now to monitor our whole infrastructure and its customers infrastructure. We deploy many Icinga instances for different teams and customers (see this video for more information).
To manage the configuration of these instances, we use the Icinga Director module. This gives us an easy way to deploy checks, services and hosts in Icinga. The teams do not have access to the configuration files of Icinga, so every change is done via the Director frontend. Because of the huge number of servers and services we have to monitor, the need to automate these changes arose.
Since we were familiar with Ansible, we quickly wrote some roles that could create hosts, checks and templates in the Director. These worked for our use-cases, however there were some problems with the usage of the roles. They assumed a particular code structure and way of work that was not as flexible as we liked and did not follow the Ansible Way. That’s why we decided to write our own custom Ansible modules. With them we can use simple Ansible tasks to create configurations in the Director. What was before a role with four tasks and over 50 lines of code to create on object, was now 20 lines of code and one single task. Here’s an example of this code to create a new host in Icinga:
- hosts: localhost
collections:
- t_systems_mms.icinga_director
tasks:
- name: create a host in icinga
icinga_host:
state: present
url: "https://myicinga-instance.com"
url_username: "{{ icinga_user }}"
url_password: "{{ icinga_pass }}"
object_name: "linuxhost"
address: "192.168.0.111"
display_name: "linuxhost"
groups:
- "foo"
imports:
- "StandardServer"
vars:
dnscheck: "no"
After writing the first modules, I showed them to my colleagues. One of them, Lars Krahl, started using the modules, enhanced and improved them!
Internally, the modules talk to the REST-API of the Director. They handle the authentication against the Director and allow creating, modifying and deleting objects. This is done by sending the required data in JSON format along with the correct HTTP-request (think GET, POST, PUT, DELETE) to the appropriate API-endpoints. The modules are also capable of detecting when an object has changed and thus making the Ansible playbook-runs idempotent. We support many, but not all Icinga Director objects (Pull Requests welcome!). For a up-to-date list of supported objects, please see the Readme on GitHub.
Once the modules were sufficiently advanced, we decided to publish them on GitHub for the Open Source community to use. Coincidentally, Ansible Collections were new at the time, so we decided to package our modules into this new format for consumption. Next to writing custom modules, creating a collection was a novelty for us as well.
Talking about the present, our collection is now at version 1.8.1. We added a role, provided new parameters to the modules and fixed some bugs. We also have an extensive test-suite consisting of Ansibles sanity tests and integration tests, as well as an automated release-process!
All this happened with the help of my colleagues and the awesome Open Source and Icinga community. I want to especially highlight Lars Krahl, Martin Schurz and Michaela Mattes. These people helped creating and shaping the collection into what it is today.
You can find the collection here:
* Github
* Ansible Galaxy
—
This was a guest blogpost from Sebastian Gumprich from T-Systems Multimedia Solutions GmbH
