Einfache Server-zu-Server-Kommunikation, Teil 1 Webhooks – viel Macht in einer URL

Anbieter zum Thema

OutSystems

Webhooks tauchen im Netz immer häufiger auf, sei es auf Social-Media-Seiten, in Entwicklerwerkzeugen wie GitHub oder Admin-Tools, zum Beispiel Monitoring-Lösungen. Selbst die universelle Wenn-Dann-Anwendung IFTTT nutzt Webhooks, um noch universeller zu werden.

Webhooks sind universell einsetzbar, für Dutzende unterschiedlichster Szenarien – und das ist genau der springende Punkt. Spannend sind sie im Grunde immer dann, wenn ein Ereignis auf dem einen Server ein Ereignis auf einem anderen Server auslösen soll – wobei Server hier im Software-Sinne gemeint ist, auch ganz normale Desktoprechner dürfen hier mitspielen.

Kurz gesagt: Webhooks sind eine simple Möglichkeit für die Server-zu-Server-Kommunikation. Und auch technisch steckt im Grunde erstmal nicht viel dahinter: Es handelt sich um HTTP-Anfragen mit einer gewissen Payload, zum Beispiel einigen JSON-formatierten Daten.

Wenn eine App auf Ihrem Server auf Ereignisse auf einem entfernten Server reagieren soll, gibt es grundsätzlich zwei Möglichkeiten: Eine Anfrage stellen oder auf eine Mitteilung warten. Ersteres wird meist per API erledigt: Die App wird mit Daten gefüttert und fragt damit zum Beispiel einen definierten Twitter-Account auf neue Beiträge ab. Die zweite Variante ließe sich mit einem Webhook erledigen: Sobald neue Beiträge auf dem Twitter-Account erscheinen, könnte Twitter dies über einen hinterlegten Webhook an die App melden.

Ein typisches Beispiel aus der Praxis: Sie haben ein IT-Monitoringsystem laufen und nutzen ein externes Alarmierungssystem, um Vorfälle im Notfall an zuständige Mitarbeiter ausspielen zu können. Viele Anbieter von webbasierten Alarmierungssystemen unterstützen für diese Anbindung Webhooks. So können Sie zum Beispiel das Monitoringsystem Checkmk an den Push-Dienst Pushover.net binden.

Nach einer Registrierung bei Pushover bekommen Sie einen so genannten Webhook-Endpunkt – eine schlichte URL. Diese konfigurieren Sie in Checkmks Alarmierungsregeln. Wird dann ein Alarm ausgelöst, wird Pushover über die Webhook-URL mit Daten versorgt und führt aus, was auch immer für diesen Vorfall definiert wurde. In der Regel werden also Mitarbeiter über Mail, SMS, Kurznachricht und so weiter über die Geschehnisse informiert.

Natürlich lassen sich allerlei Szenarien alternativ auch über APIs realisieren, aber Webhooks haben durchaus ihre Vorteile. So müssen nicht ständig Abfragen laufen, die unter Umständen noch nicht einmal (neue) Daten liefern. Zudem sind Webhooks im Grunde recht simpel, letztlich läuft es auf ein simples Wenn-Dann hinaus: Wenn Ereignis X auftritt, schicke Daten an meinwebhook.example.com/test?foobar-daten.

IFTTT als Webhook-Empfänger

Apropos „Wenn …, dann …“: If-This-Then-That haben wir Ihnen hier schon näher vorgestellt. Es eignet sich hervorragend für Webhooks – sowohl in der Praxis als auch zum Verstehen.

IFTTT vernetzt zwei Dinge oder Services über das Web und eine simple Wenn-Dann-Logik: Wenn auf Twitter-Account XY ein neuer Tweet kommt (This), dann schreibe eine Mail an foobar@example.com (That). Wenn aber nun nicht ein Tweet, sondern Ihr eigenes Skript auf Ihrem eigenen Server als This dienen und eine beliebige IFTTT-That-Aktion auslösen soll, können Sie wieder die beiden Varianten API und Webhook nutzen.

Eigene Services über APIs zu entwickeln ist aber natürlich nicht ganz trivial. Webhooks hingegen schon:

• Webhooks aktivieren und Endpunkt-URL kopieren (zu finden auf der Doku-Seite)

• „This“ festlegen: Webhooks

• Trigger festlegen: Web-Request empfangen

• Trigger benennen: mein_trigger

• „That“ festlegen: Gmail

• Aktion festlegen: Mail senden

• Mail-Inhalt konfigurieren

Anschließend können Sie den Webhook über die Endpunkt-URL nutzen: https://maker.ifttt.com/trigger/mein_trigger/with/key/ABCDE123456. In der URL finden Sie zum einen den Trigger-Namen und zum anderen Ihren persönlichen Schlüssel (hier ABCDE123456). Der Schlüssel dienst schlicht zur Absicherung, schließlich wäre ein solcher Endpoint ansonsten ein leichtes Ziel für DDOS-Attacken.

Wenn Sie in der Konfiguration des Mail-Inhalts nun beispielsweise die drei Variablen myvar1, myvar2 und myvar3, bei IFTTT „Ingredients“ genannt, angelegt haben, könnten Sie diese URL via curl-Befehl in einem Skript nutzen:

Und hier sehen Sie auch den technischen Part von Webhooks mal ganz konkret: Eine simple HTTP-POST-Abfrage mit ein paar JSON-Daten und einem Schlüssel.

IFTTT als Webhook-Sender

Als „This“ lassen sich also beliebige Skripte und Apps einsetzen. Was aber, wenn die That-Funktionen von IFTTT nicht das Gewünschte bieten? Nun, sie bieten ebenfalls Webhooks. Sobald also ein beliebiges This eintritt, meldet sich nun IFTTT seinerseits mit der That-Aktion beim hinterlegten Webhook-Endpunkt.

Dafür benötigen Sie natürlich auf Ihrem Server einen Webhook-Empfänger – unter Linux wunderbar einfach zu realisieren mit dem gleichnamigen Tool webhook. Webhook macht nichts weiter, als auf eingehende HTTP-POST-Anfragen zu warten und ein darin benanntes lokales Skript zu starten.

Die Konfiguration von webhook beschränkt sich im einfachsten Fall auf die Datei „/home/NUTZERNAME/webhooks/hooks.json“. Hier können Sie mehrere Einträge hinterlegen, die jeweils aus einer beliebigen ID sowie den Pfaden zum auszuführenden Skript und zum Arbeitsverzeichnis. Das Skript, etwa “meinskript.sh”, können Sie im gleichen Ordner ablegen, um dann folgende Konfiguration zu nutzen:

Starten Sie anschließend webhook mit der Config-Datei über ...

..., ist Ihr Server auch schon empfangsbereit und Sie können abermals mit curl testen:

Beachten Sie, dass in diesem Fall keine Autorisierung stattfindet – wer die URL kennt, könnte den Server mit Anfragen überfluten,

Der Rest wäre dann wieder reine IFTTT-Konfiguration: Sie konfigurieren eine Verbindung mit Webhooks als That-Aktion und hinterlegen die Endpunkt-URL Ihrer webhook-Installation. Damit können Sie nun als beliebige Skripte auf beliebigen Servern als sowohl This als auch That in IFTTT-Rezepten verwenden – mit anderen Worten: Beliebige Apps mittels IFTTT miteinander verknüpfen.

Abseits von IFTTT

Vielleicht ist es vor lauter IFTTT-Beispielerei etwas untergegangen: Es geht natürlich auch ohne IFTTT, mit curl als Sender und webhook als Empfänger wird ja bereits direkt kommuniziert. So simpel und funktional das Tools webhook aber auch sein mag, einfach nur Skripte zu starten, ist freilich nicht das Ende vom Lied.

Überdies würde noch eine Autorisierung fehlen, um webhook in freier Wildbahn zu nutzen. Für das eigene LAN, sichere Sub-Netze und dergleichen ist es aber schon eine nette Anwendung – und sei es nur, um sich eine einfache HTML-Seite mit Links zu Skripten auf Rechnern im Netzwerk zu erstellen.

Vor allem aber lohnt ein Blick auf die vielen populären Dienste im Netz, die ihrerseits Webhooks anbieten, beispielsweise Dropbox, Atlassian-Produkte, Facebook, Mattermost, Trello, Uber, Zoho und selbstverständlich auch GitHub. So könnten Sie zum Beispiel jede neue Mitteilung in der Mattermost-Ruby-Gruppe als Android-Benachrichtigung empfangen, ganz ohne Mattermost-App.

Ruby ist das richtige Stichwort: Das Lied geht weiter, und zwar mit GitHub und Sinatra als Ruby-Interpret. Sinatra ist eine erstaunlich einfache Ruby-Lösung, um On-the-fly Webanwendungen zu erstellen, die als Webhook-Empfänger deutlich mehr leisten als das Webhook-CLI-Werkzeug. Hier genügen ein paar Zeilen Code.

Im nächsten Webhook-Artikel zweigen wir ganz praktisch und Schritt für Schritt, wie sich GitHub-Events via Webhook mit einem Sinatra-Server empfangen und auswerten lassen; natürlich mit Autorisierung, damit das Ganze auch alltagstauglich ist.

(ID:46898173)