Einspielen von CheckCommands über die Director-API

 

Generell funktioniert das Einspielen von Konfiguration über den Director ja schon ganz ordentlich. Manchmal stoßen wir dabei jedoch auch an Grenzen, die oft dem aktuellen Entwicklungsstand des Projekts oder den unendlichen Möglichkeiten von icinga geschuldet sind.

icinga configuration is a full-blown DSL, not just a configuration format

 

Wir sind bei Version 1.3 angekommen und ich finde die Möglichkeiten schon beeindruckend. Nach wie vor lassen sich kompliziertere Konstrukte wie Conditionals, Loops etc. nicht oder nur spärlich realisieren, allerdings gibt es für fast alle diese Anwendungsfälle auch andere Lösungen/Workarounds die für die meisten unserer Kunden ausreichen und in diesem immer noch frühen Entwicklungsstadium völlig in Ordnung sind.

Somit nimmt der icinga Director in unserem produktiven Umfeld seine Rolle als Konfigurationshelfer bereits ausreichend wahr und man kann auch Kunden begeistern die mit der Icinga-Sprache nicht ganz so vertraut sind.

Heute möchten wir kurz zeigen, wie man sich trotz einiger (noch)-Schwächen des Directors (fehlende Unterstützung für sämtliche Sprachelemente aus icinga) helfen kann.

Wir wollen ein CheckCommand per Director-API einspielen. Warum?

Im Director gibt es aktuell keine Möglichkeit z.B. die Attribute skip_key oder description eines CheckCommands zu setzen. Nun könnte man diese Objekte klassisch unter conf.d ablegen, allerdings können diese dann nicht im Director verwendet werden. Außerdem möchten wir unseren Kunden gern eine angepasste Installation übergeben, sodass er sich selbst nur noch um seine individuelle Konfiguration kümmern muss.

Gleich vorweg: Über die API wird grundsätzlich alles was icinga an Möglichkeiten bietet auch unterstützt. Aufgrund des erhöhten Programmieraufwands werden allerdings nie alle Möglichkeiten auch so im Director abgebildet werden können.


API Helper Script

 

Die API kann man z.B. mit Curl bedienen. Freundlicherweise wird hier in der Doku schon ein passendes Script mitgeliefert:

Es reicht, die Parameter USERNAME und PASSWORD anzupassen. Eventuell noch die URL zum API-Endpoint.

Wichtig: Hier wird nicht die icinga-API benutzt, sondern die Director-API, welche über die Icingaweb2-Oberfläche anzusprechen ist und deshalb auch die entsprechenden Login-Daten verlangt.

Das Script könnt ihr z.B unter /usr/local/bin/director-api speichern. Somit liegt es dann direkt im Pfad. Nun noch ausführbar machen mit chmod +x /usr/local/bin/director-api und fertig ist unser Helper Script.


Erstellen des CheckCommands

 

Als nächstes erstellen wir unser CheckCommand im JSON-Fomat (vim sansymphony_snmp). Dies legen wir gern als Datei im Ansible-Repository ab und rollen es auf den entsprechenden Maschinen aus.

Wir rufen das API-Script derzeit vom jeweiligen Host aus auf da unsere Ansible-Struktur eher dezentral ist. Durch die Automatisierung passt das so für uns. Man kann sich natürlich auch eine zentrale Stelle für den API-Call vorstellen.

Je nachdem ob ihr ein Objekt neu anlegen oder verändern wollt, müssen unterschiedliche URL-Endpunkte angesprochen werden.

Anlegen:

 

Anpassen:


Rückmeldungen der API:

Bei erfolgreichem Anlegen des Objekts:

 

Bei keiner Änderung:

Bei erfolgreicher Änderung:

 

Erneutes Anlegen eines schon vorhandenen Objekts schlägt fehl:

 

Was haben wir getan?

  • dem Director ein icinga Objekt bekannt gemacht (API)
  • icinga Sprachelemente genutzt die so im Director noch nicht zur Verfügung stehen (z.B default vars, description, skip_key) um kleine Schwächen des Directors zu umgehen
  • das Objekt im Director nutzbar gemacht
  • (noch) KEIN icinga Objekt eingespielt (dazu muss erst der Config Check einmal gelaufen sein)

 

Deploy der Änderungen

Wer den Director kennt, weiß, dass Änderungen niemals ohne weiteres Deployment aktiv sind. Wir müssen noch dafür sorgen, dass ein Config-Check durchgeführt und anschließend die Konfiguration erneut ausgerollt wird.

Das geht entweder über die Web-Oberfläche oder auch bequem über die Director-CLI:

 

Wir rollen seit einiger Zeit auf diese Weise unsere CheckCommands auf den Kundenmaschinen aus. Die CheckCommands sind universell einsetzbar und wiederverwendbar.

Damit ersparen wir uns lästige Klickerei und unseren Kunden Bares 😉

Ergänzung: Es gibt als Ergänzung zum Director-Modul für die Web2 Oberfläche auch noch andere grafische Helfer womit sich Sprachelemente aus icinga über den Director einspielen lassen bzw. sich sogar normale icinga-Config importieren lässt. Man verzichtet bei Anwendung solcher Methoden allerdings meist auf den Syntax-Check des Directors. [Hier](http://github.com/Icinga/icingaweb2-module-fileshipper) findet ihr mehr Informationen dazu.

Icinga Director-API