StackStorm

Christoph Glaubitz

2015-03-04 11:23

TL;DR: StackStorm ist ein Automatisierungsframework. Es gibt eine zentrale Stelle an der Events einlaufen und Aktionen veranlasst werden. Es ist relativ einfach eigene Automatisierung darin zu realisieren.: Siehe: http://stackstorm.com/product/
Erstes Fazit:: Sehr "pluggable". Lässt sich mit so gut wie jedem System zusammen stecken. StackStorm hat so viele Anwendungsfälle wie man sich vorstellen kann. Darf nur in einem Vertrauten Netz stehen. Zumindest habe ich keine auth-Möglichkeit gesehen. Fühlt sich aber noch hakelig an.

Zuerst einmal. Worum geht es eigentlich?

Auf der Suche nach eine Orchestrierungslösung bin ich über StackStorm http://stackstorm.com/ gestolpert, die auf den ersten Blick recht vielversprechend aussieht.

Doch einen Schritt zurück. Was meine ich hier mit "Orchestrierung"?: Dinge sollen im besten Fall automatisch auf Computern passieren. Viele Szenarien lassen z.B. sich mittels puppet und mcollective lösen, doch oft stößt man an Grenzen. In solchen Fällen werden häufig Scripte geschrieben, die auf dem kurzen Weg über das Configuation Management ausgerollt werden. Je nach Funktion wird noch ein cronjob ergänzt. Dadurch wächst relativ schnell ein Wildwuchs an Scripten an und man verliert schnell den Überblick wann und wo, was passiert. Im schlimmsten Fall rufen sich Scripte noch gegenseitig über ssh auf.

Oft lassen sich diese Arbeitsanweisungen auf sowas wie "Hier ist X passiert, mache dort Y".

Bsp.: Nach einem git-push wird Jenkins getriggert. Jenkins läuft durch und triggert im Erfolgsfall das Ausrollen auf entsprechenden Nodes.

Technisch ist dies sicherlich lösbar. Hie und da ein Script, vielleicht noch irgendwo ein cronjob, und fertig ist die Laube. Der Nächste wundert sich dann wieder ob der Magie und muss die Kette versuchen zu debuggen. Bei Umzügen brechen dann Ketten, an die niemand mehr gedacht hat.

Ich stelle mir einen zentralen Punkt (bei dem es möglich sein muss, ihn redundant auszulegen) vor, in dem Arbeitsanweisungen definiert werden. Und genau an diesem Punkt bin ich auf StackStorm gestoßen.

StackStorm liefert u.A. sensor, trigger, action und rule. In jede Komponente kann man eigene hinzufügen.

StackStorm selbst besteht aus mehreren Services, die sich je um spezielle Aufgaben kümmern. Die Services kommunizieren über amqp-system wie rabbitmq.

Z.B. führt die action core.remote über ssh (falls gewünscht mit sudo) das übergebene Kommando auf einem entfernten aus. core.http ruft einen entfernten Webhook an. An der Stelle "remote" möchte man vielleicht über eine Queue, statt ssh nachdenken. Die Möglichkeit StackStorm zu erweitern macht das recht einfach.

Sensoren verbinden StackStorm mit externen Systemen und registrieren oft trigger. Webhooks können aber separat als trigger eingerichtet werden.

StackStorm kann Webhooks als trigger zur Verfügung stellen. Angenommen wird jedes beliebige json. Es ist auch möglich cron-Tigger zu definieren.

Rules stecken trigger und action anhand von Kriterien zusammen. Wobei das Kriterium optional ist.: Bsp:

---
    name: "examples.webhook_file"
    description: "Sample rule dumping webhook payload to a file."
    enabled: true

    trigger:
        type: "core.st2.webhook"
        parameters:
            url: "sample"

    criteria:
        trigger.body.name:
            pattern: "st2"
            type: "equals"

    action:
        ref: "core.local" ### passiert auf dem StackStorm-Host
        parameters:
            cmd: "echo \"{{trigger.body}}\" >> /tmp/st2.webhook_sample.out"

Die rule-Engine läuft alle treffenden Regeln durch. So kann man auf ein und den selben trigger verschiedene criteria und actions zusammen stecken.

Zusätzlich lassen sich alle actions auch per command line client aufrufen.

st2 run core.local cmd="uname -a"

Jede Auführung wird von StackStorm in der Datenbank gespeichert und ist über

st2 execution list # (/get)

erreichbar. Und genau hier hatte ich in meinen Tests Probleme.

Mein Setup:

Die Installation habe ich nach http://docs.stackstorm.com/install/sources.html durchgeführt und StackStorm via tools/launchdev.sh gestartet. Meine Installation ist noch eine v0.7

sensu mit einem StackStorm-Handler ausgestattet. Dieser hat falls nötig einen Webhook in StackStorm registriert. Von außen, ohne Auth. ACHTUNG: StackStorm nicht im Netz stehen lassen! Außerdem ruft der Handler den Webhook an und lädt das sensu-JSON dort ab.

Der sensu-Hanlder kommt von StackStorm. Kann aber leider nicht mit stashes umgehen. D.h. selbst wenn es in sensu für einen Check/Host einen stash gibt, ruft der Handler trotzdem den webhook an.

Den trigger habe ich mit einer rule ohne criteria mit der action core.local cmd="echo "{{trigger.client.name}}" >> /tmp/st2.sensu.out" zusammen gesteckt.: Bei jedem sensu-Event wurde also der client.name, bei dem das Problem auftrat in eine Datei geschrieben.

---
    name: "sensu.event.process"
    description: "process incoming sensu events"
    enabled: true

    trigger:
        type: "sensu.event_handler"

    action:
        ref: "core.local"
        parameters:
            cmd: "echo \"{{trigger.client.name}}\" >> /tmp/st2.sensu.out"

Ich habe einfach dafür gesorgt, dass ein sensu-Check (der minütlich geprüft wird) rot anzeigt und somit den Webhook anruft. Als ich nach ca. 2 1/2 Wochen wieder an das Thema ging wollte execution list nicht mehr:

# st2 execution list
MESSAGE: database error: too much data for sort() with no index. add an index or specify a smaller limit

Riecht nach "Datenbank + Entwickler = BOOM".

Mit st2 execution get ID kommt man noch an bekannte Ausführungen.

Hier hätte also auch ein core.remote hosts={{trigger.client.name}} cmd="service XY restart" passieren können.: Denkt man sich später irgendwann aus, dass in einem solchen Fall automatisch ein Ticket aufgemacht werden soll. Kein Problem. "Einfach" eine zusätzliche rule einrichten.

StackStorm hat sich als extrem flexibel erwiesen. Der Phantasie sind kaum Grenzen gesetzt. Es tut weitestegehend das was man erwartet und mit Ausnahme von zu viele executions bin ich in keine großen Probleme gelaufen. Bisher habe ich mich noch nicht im reproduzeirbares Aufsetzen und Pakete gekümmert. StackStorm selber kann debian-Pakete bauen. Es gitb ein puppet-Modul (https://github.com/StackStorm/puppet-st2 ) das Pakete per wget runter lädt und installiert. Hier wäre ein repo sicherlich schöner.

Der Grund warum ich initial mit dem dev-Setup angefangen habe: Es ist einfach besser zu debuggen.