Mein letzter Artikel widmete sich Icinga 2 und der neuen Konfigurationsoberfläche Icinga Director. Ich habe beiläufig erwähnt, dass sich der Director auch an bestehende Configuration Management Database-Systeme (CMDB) anbinden lässt, um den Datenimport zu erleichtern. In diesem Artikel werden wir beispielhaft eine kleine MySQL-Datenbank als "Dummy-CMDB" definieren und automatisiert Host-Informationen einlesen und umsetzen.

Mithilfe des Directors können wir folgende Informationen automatisiert einlesen und umsetzen:

• Hosts und Hostgruppen
• Services und Servicegruppen
• Benutzer und Benutzergruppen
• Endpunkte und Zonen
• Kommandos

Datenbank-Vorbereitung

Als Beispiel dient eine simple Tabelle mit Host-Informationen. Essentiell sind hier für Icinga der Hostname sowie eine dazugehörige IP-Adresse - ohne diese Informationen lässt sich ein System nicht überwachen. Aus bestehenden CMDB-Systemen lassen sich diese Informationen in aller Regel ebenso gewinnen - nur ist vermutlich mit bedeutend komplexeren Datenbank-Abfragen zu rechnen (z. B. Abfragen über mehrere Tabellen, etc.). Benötigt wird in jedem Fall ein entsprechender Zugang zur Datenbank - lesender Zugriff reicht hier vollkommen aus. Dieser Punkt ist je nach CMDB-Produkt nicht ganz trivial - macht euch also auf stundenlanges Konsultieren der Datenbank-Dokumentation (sofern vorhanden) und Testen unter Koffein-Einfluss gefasst. 🙂

Als Beispiel wurde hier eine Tabelle mit folgenden Einträgen erstellt:

hosts

Die einzelnen Spalten sind selbsterklärend: neben einer fortlaufenden Nummer werden Hostnames, IP-Adressen und eine optionale Beschreibungen definiert. In MySQL lässt sich eine solche Tabelle samt Datenbank und Benutzer wie folgt definieren:

 1mysql> CREATE DATABASE cmdb CHARACTER SET 'utf8';
 2mysql> GRANT ALL ON cmdb.* TO 'cmdb'@'localhost' IDENTIFIED BY '...';
 3mysql> FLUSH PRIVILEGES;
 4$ mysql -u cmdb cmdb -p
 5mysql> CREATE TABLE hosts(
 6        host_id INTEGER PRIMARY KEY AUTO_INCREMENT,
 7        host_name TEXT NOT NULL,
 8        host_ip TEXT NOT NULL,
 9        host_desc TEXT NULL
10);
11mysql> INSERT INTO hosts (host_name, host_ip) VALUES ("dummyhost", "127.0.0.1");
12mysql> INSERT INTO hosts (host_name, host_ip, host_desc) VALUES ("dummyhost2", "127.0.0.2", "Test host");
13mysql> INSERT INTO hosts (host_name, host_ip, host_desc) VALUES ("dummyhost2", "127.0.0.2", "Test host 2");

Die Abfrage der relevanten Informationen wird über das folgende SQL-Statement erreicht:

1SELECT host_name, host_ip, host_desc from hosts;

Ziel ist es nun, Icinga Director dazu zu bringen, diese Informationen auszulesen und in valide Host-Objekte zu verwandeln - und das natürlich vollautomatisiert. 🙂

Icinga Director-Anpassungen

Der erste Schritt ist es, die externe Datenbank als Ressource anzulegen. Dazu sind Klicks auf Konfiguration > Anwendung > Ressources und Neue Ressource erstellen notwendig. Als Typ wird SQL-Datenbank ausgewählt, das Formular in etwa wie folgt ausgefüllt:

Ein Klick auf Konfiguration validieren stellt eine Test-Verbindung her und speichert die Resource im Idealfall ab.

Der nächste Schritt ist es, die Datenquelle innerhalb Icinga Director zu definieren - es folgen Klicks auf Icinga-Director > Automatisierung > Importquelle und Importquelle hinzufügen. Neben einem sinnvollen Namen wird wieder SQL als Typ ausgewählt. In unserem Beispiel wird der Dialog wie folgt ausgefüllt:

• Schlüsselspaltenname: host_name (Feldname der den Hostname enthält)
• Resource name: Name der zuvor angelegten SQL-Resource
• DB Query: SELECT host_name, host_ip, host_desc from hosts;

Beim Einsatz marktüblicher CMDB-Produkte wird es vermutlich notwendig sein, die Inhalte der Felder zu manipulieren, beispielsweise um die Schreibweise zu ändern oder Domänen-Namen anzuhängen. Anpassungen dieser Art können in der Registerkarte Modifikatoren definiert werden. Wurde die Datenquelle konfiguriert, kann sie im Reiter Importquelle mit einem Klick auf Auf Änderungen prüfen auf Updates geprüft werden. Ein weiterer Klick auf Importlauf anstoßen importiert und verarbeitet Daten - im Reiter Preview können die Informationen anschließend eingesehen werden. In unserem Fall sollte die Tabelle wie folgt aussehen:

Schön - die Daten können wir nun auslesen! Mithilfe eines Synchronisationsjobs können wir dafür sorgen, dass die Hosts in die Icinga Director-Datenbank übernommen werden. Um einen solchen zu erstellen, klicken wir auf den Reiter Synchronisationsregel und anschließend auf Synchronisationsregel hinzufügen. Neben einem sinnvollen Namen wählen wir den Host-Objekttyp aus. Unter Ändere können wir definieren, wie der Director mit den neu gewonnen Daten umgeht - er kann lokal definierte Informationen komplett ersetzen (Ersetzen) oder sie ergänzen (Zusammenführen). Diese Einstellung hängt ganz von der verwendeten CMDB ab - ich habe mich für die Ergänzung entschieden, da ich beispielsweise Services und Notifications nicht über die CMDB abbilde. Bereinigen definiert, ob in der Quelle gelöschte Informationen auch aus der Icinga Director-Datenbank gelöscht werden. Auch hier kommt es wieder drauf an, wie ihr mit den verschiedenen Informationsquellen umgehen wollt. Prinzipiell werden die importierten Informationen meistens mit weiteren Einstellungen kombiniert (z. B. Services, Notifications,...) - in meinem Setup macht es Sinn, entfernte Hosts aus der Director-Datenbank zu entfernen.

Wurde der Job definiert, kann er im ersten Reiter mit Klicks auf Auf Änderungen prüfen und Diese Synchronisation anstoßen getestet und gestartet werden. Wurde er fehlerfrei ausgeführt, ist ein entsprechender Eintrag im Reiter Historie zu sehen:

Klickt man auf den Eintrag, wird sogar ein detailliertes Protokoll angezeigt - beispielsweise:

Schön und gut - wir haben eine Datenquelle samt Synchronisation konfiguriert. Aber richtig praktisch ist es für viele erst dann, wenn das vollautomatisiert ausgeführt wird - und hier kommen Aufträge ins Spiel. Mit beherzten Klicks auf den Reiter Aufträge und Hinzufügen wird ein weiterer Assistent zur Erstellung eines Jobs gestartet. Will man den bereits beschriebenen Vorgang vollständig automatisieren, müssen zwei Jobs erstellt werden:

1. Import der Hosts aus der Datenbank
2. Erstellen und Ausrollen der Konfiguration

Insbesondere bei letzterem werden die Meinungen weit auseinander gehen. In vielen Umgebungen ist das Ausrollen der Konfiguration eine Aufgabe, die nicht automatisiert stattfinden soll - beispielsweise um weitere Anpassungen zu überprüfen. In manchen Entwicklungs- und Testumgebungen kann das aber durchaus sinnvoll sein - hier entscheidet wieder ihr, was für euch am Besten ist. 🙂

Neben einem sinnvollen Namen wird die Art des Jobs gefragt - für den ersten Job wählen wir Import, für den zweiten Config. Beim Importieren der Informationen muss noch die zugehörige Datenquelle angegeben werden. Für jeden Job wird ein Intervall in Sekunden angegeben - beispielsweise 86400 für einen täglichen Durchlauf. Meine Job-Einstellungen sehen wie folgt aus:

Probiert es aus - ihr werdet sehen, dass unterhalb des Menüpunkts Historie etwaige Änderungen an der Konfiguration dokumentiert werden. Mit einem Klick auf den Protokolleintrag seht ihr sogar detaillierte Änderungen des Codes:

Fazit

Ich finde es faszinierend, wie leicht sich Fremdinformationen sinnvoll mithilfe des Icinga Directors importieren und umsetzen lassen. Es erfordert zwar einige Tests, doch insbesondere in größeren Umgebunden kann man so zahlreiche Arbeitsstunden einsparen und auch stetige Anpassungen erleichtern. An der Stelle ein großes Lob an das Icinga-Team, tolle Arbeit! 🙂