Was ist ein Webhook?

Ein Webhook ist eine HTTP-basierte Callback-Funktion, die eine schlanke, eventgesteuerte Kommunikation zwischen 2 APIs ermöglicht. Webhooks werden von einer Vielzahl von Webanwendungen verwendet, um kleine Datenmengen von anderen Anwendungen zu empfangen. Sie können aber auch verwendet werden, um Automatisierungs-Workflows in GitOps-Umgebungen auszulösen.

Da Webhooks Event-Quellen mit Automatisierungslösungen verbinden können, stellen sie eine Möglichkeit zum Starten eventgesteuerter Automatisierungsprozesse dar, um beim Eintreten eines bestimmten Events IT-Aktionen auszuführen.

Was ist eine API?

Eine API besteht aus mehreren Tools, Definitionen und Protokollen zur Entwicklung und Integration von Anwendungssoftware. Die Kommunikation zwischen APIs wird manchmal als Vertrag zwischen einem Informationsnutzer und einem Informationsanbieter bezeichnet, in dem der vom Konsumenten benötigte Inhalt (der Aufruf) und der vom Produzenten benötigte Inhalt (die Antwort) festgelegt werden. Diese Beziehung wird auch als die Client-App beschrieben, die die Server-App aufruft. Diese Rollen können aber auch umgekehrt werden, je nachdem, welche App in einer bestimmten Situation Daten anfordert.  

Web-APIs verwenden in der Regel HTTP, um Daten von anderen Anwendungen anzufragen und die Struktur der Antwortnachrichten zu definieren, die in der Regel die Form einer XML- oder JSON-Datei haben. Sowohl XML als auch JSON werden als Format bevorzugt, weil sie Daten auf eine Weise präsentieren, die den Apps die Manipulation erleichtert. 

Wenn eine Client-API Daten von einer Server-API anfragt, so tut sie dies, um festzustellen, ob ein bestimmtes Event eingetreten ist, d. h. ob sich die Daten des Servers in einer Weise geändert haben, die für den Client nützlich sein könnte. Bei diesem Verfahren (dem sogenannten Polling) sendet der Client in regelmäßigen Abständen eine HTTP-Anfrage, bis die API des Servers die entsprechenden Daten sendet, die manchmal auch als Payload bezeichnet werden. 

Da die Client-App den Status der Server-App nicht kennt, fragt sie die API des Servers nach einer Aktualisierung – und zwar so lange, bis das betreffende Event eintritt – aber der Server sendet die angefragten Daten erst, wenn diese Informationen verfügbar sind. Die Client-App muss immer wieder nach der Aktualisierung fragen und warten, bis das entsprechende Event eintritt.

Wie unterscheiden sich Webhooks?

Um einen Webhook einzurichten, übermittelt der Client eine eindeutige URL an die Server-API und gibt an, über welches Event er informiert werden möchte. Sobald der Webhook eingerichtet ist, muss der Client den Server nicht mehr abfragen. Der Server sendet automatisch die entsprechenden Payloads an die Webhook-URL des Clients, wenn das angegebene Event eintritt. 

Webhooks werden oft als Reverse-APIs oder Push-APIs bezeichnet, weil sie die Verantwortung für die Kommunikation auf den Server und nicht auf den Client übertragen. Anstelle des Clients, der HTTP-Anfragen sendet – also Daten anfordert, bis der Server antwortet – sendet der Server dem Client eine einzige HTTP-POST-Anfrage, sobald die Daten verfügbar sind. Ungeachtet des Namens sind Webhooks keine APIs; sie arbeiten zusammen. Eine Anwendung muss über eine API verfügen, um einen Webhook zu verwenden. 

Der Name Webhook ist eine einfache Kombination aus den Worten Web, der HTTP-basierten Kommunikation, und Hooking, einer Programmierfunktion, mit der Anwendungen Aufrufe oder andere Events abfangen können, die von Interesse sein könnten. Webhooks greifen das Event auf, das in der Server-App auftritt, und veranlassen den Server, die Payload über das Web an den Client zu senden. Jeff Lindsay hat das Konzept mit seinem Blogbeitrag aus dem Jahr 2007 bekannt gemacht: „Web Hooks to revolutionize the web“.

IT-Teams verwenden eine Vielzahl von Methoden, um Anwendungen zu schützen, die über Webhooks kommunizieren. Die meisten webhookfähigen Anwendungen fügen einen Secret-Schlüssel in den Anfrage-Header der Payload ein, damit der Client die Identität des Servers bestätigen kann. Webhooks werden häufig mit der mTLS-Authentifizierung (Mutual Transport Layer Security) geschützt, die sowohl den Client als auch den Server verifiziert, bevor die Payload gesendet wird. Außerdem verwenden Client-Apps häufig SSL-Verschlüsselung für die Webhook-URL, um sicherzustellen, dass die übertragenen Daten geheim bleiben.

Webhooks: 

• Eliminieren die Notwendigkeit des Pollings. Dies spart Ressourcen für die Client-App. 
• Sind schnell einzurichten. Wenn eine Anwendung Webhooks unterstützt, lassen sie sich leicht über die Benutzeroberfläche der Server-App einrichten. Hier gibt der Client die Webhook-URL seiner Anwendung ein und legt einige grundlegende Parameter fest, wie beispielsweise das Event, an dem er interessiert ist.   
• Automatisieren die Datenübertragung. Die Payload wird gesendet, sobald das angegebene Event in der Server-App eintritt. Dieser Austausch wird durch das Event initiiert und erfolgt so schnell, wie die Daten vom Server zum Client übertragen werden können – so schnell wie eine Datenübertragung nur sein kann.
• Eignen sich gut für schlanke, spezifische Payloads. Webhooks verlassen sich darauf, dass der Server die Menge der von ihm gesendeten Daten bestimmt, und überlassen es dem Client, die Payload zu interpretieren und sie produktiv zu nutzen. Da der Client weder den genauen Zeitpunkt noch den Umfang der Datenübertragung kontrolliert, befassen sich Webhooks mit kleinen Informationsmengen zwischen 2 Endpunkten, oft in Form einer Benachrichtigung.

Webhooks werden in der Regel zur Vereinfachung der Kommunikation zwischen 2 Anwendungen eingesetzt, können aber auch zur Automatisierung von IaC-Workflows (Infrastructure-as-Code) und für GitOps-Praktiken verwendet werden.

Was ist IaC (Infrastructure as Code)? 

Mit IaC (Infrastructure as Code) wird die Infrastruktur durch Code – und nicht durch manuelle Prozesse – verwaltet und provisioniert. Ein wichtiger Bestandteil von IaC ist die Versionskontrolle. Wie jede andere Software-Quellcodedatei sollten auch die Konfigurationsdateien der Quellkontrolle unterliegen. Die Bereitstellung von IaC bedeutet auch, dass die Infrastruktur in modulare Komponenten aufgeteilt werden kann, die dann durch Automatisierung auf unterschiedliche Weise kombiniert werden können.

Durch eine automatisierte Infrastrukturprovisionierung mit IaC müssen Server, Betriebssysteme, Storage und andere Infrastrukturkomponenten von den Entwicklungsteams nicht jedes Mal, wenn sie eine Anwendung entwickeln oder bereitstellen, manuell provisioniert und verwaltet werden. Die Kodifizierung der Infrastruktur bietet eine Vorlage für die Provisionierung. Prozesse wie dieser können weiterhin manuell durchgeführt werden, lassen sich aber auch mit einer unternehmensgerechten Engine für den gewünschten Zustand automatisieren, etwa mit Red Hat® Ansible® Automation Platform.

Was ist GitOps?

GitOps wird oft als Weiterentwicklung von IaC betrachtet und ist ein strategischer Ansatz für die Verwaltung von Infrastruktur- und Anwendungskonfigurationen mithilfe von Git, einem Open Source-System für die Versionskontrolle. Gemäß den GitOps-Praktiken verwenden Entwicklungsteams Git als zentrale Quelle für deklarative Infrastrukturen und Anwendungen und nutzen Git-Pull-Anfragen zur automatischen Verwaltung der Infrastrukturprovisionierung und -bereitstellung. Da der gesamte Zustand des Systems im Git Repository enthalten ist, können sämtliche Änderungen eingesehen und geprüft werden. 

Was haben Webhooks damit zu tun?

Webhooks reduzieren die Schritte, die für die Implementierung und Verwaltung von Git-zentrierten Deployment-Pipelines erforderlich sind, und können zum automatischen Start ganzer IaC-Workflows verwendet werden. In einer GitOps-Umgebung – mit einem Git Repository als Source of Truth – funktioniert ein Webhook genauso wie zwischen 2 Anwendungen: Wenn er durch ein bestimmtes Event ausgelöst wird, sendet eine API eine Payload an eine andere API. Der Unterschied liegt darin, welche Art von Event den Webhook auslöst und was der Empfänger mit der Payload macht.

In diesem Zusammenhang spielt das Git Repository die Rolle der Server-App, während die Engine für den gewünschten Zustand, die den Zustand der Infrastruktur verwaltet, die Rolle der Client-App übernimmt. Webhooks können zur Benachrichtigung der Engine für den gewünschten Zustand bei Änderungen im Git Repository verwendet werden. Wird ein Teil des Codes aktualisiert und in das Git Repository übertragen, löst dieses Event den Webhook aus. Das Repository sendet dann automatisch die Payload an die Webhook-Adresse der Engine für den gewünschten Zustand und informiert sie über die Codeänderung.

Wenn die Engine für den gewünschten Zustand Automatisierungsprozesse unterstützt, können diese Webhooks auch IaC-Workflows starten und Codeänderungen automatisieren. So können Systemadministrationsteams beispielsweise eine Automatisierung einrichten, die immer bei Empfang der Payload eines Webhooks ausgeführt wird, um auf ihren verwalteten Hosts automatisch neue Codeänderungen anzuwenden und sie in einen Standardzustand zu versetzen. Diese Verwendung von Webhooks zum Auslösen von Automatisierungsvorgängen kann erweitert werden, um andere IT-Abläufe ohne menschliches Eingreifen durchzuführen. Dies ermöglicht einen Prozess, der als eventgesteuerte Automatisierung bezeichnet wird.

Der einzige Unterschied besteht in der Source of Truth: Statt einer Verbindung zwischen einer Engine für den gewünschten Zustand und einem Git Repository, das zum Pushen von Code-Updates auf den Menschen angewiesen ist, kann ein Webhook die Verbindung zu einem Drittanbietertool herstellen, das eine Quelle auf bestimmte Events überwacht. Sobald diese Event-Quellen ein gezieltes Event erkennen und den Webhook auslösen, kann die Payload eine Automatisierung starten. Diese leitet sofortige Schritte zur Bearbeitung des Events zu beliebigen Tageszeiten ein, ohne dass das IT-Personal eingreifen muss.

Der Begriff „eventgesteuerte Automatisierung“ bezeichnet den Prozess der automatischen Reaktion auf sich ändernde Bedingungen in einer IT-Umgebung, um Probleme schneller zu lösen und sich wiederholende Routineaufgaben zu reduzieren. Mit eventgesteuerter Automatisierung können IT-Teams Reaktionen auf Events wie Hardware-Probleme, DDoS-Angriffe (Distributed Denial of Service), Speicherknappheit oder Anwendungsfehler kodifizieren. Bei Eintreten des Events wird die erforderliche Aktion dann automatisch ausgeführt.

Eventgesteuerte Lösungen basieren auf Tools oder Plugins von Drittanbietern wie ServiceNow, Kafka, Prometheus, Sensu, Dynatrace und Appdynamics, um Quellen für Events zu überwachen. Webhooks können diese Event-Quellen mit einer Automatisierungsplattform verbinden, sodass der Webhook die entsprechende automatische Reaktion auslöst, sobald eine Quelle ein Event erkennt.

IT-Teams können eventgesteuerte Automatisierung schrittweise einführen, um die durchschnittliche Zeit bis zur Problemlösung (MTTR) zu verkürzen und Funktionen auszuführen, die nach wie vor menschliches Eingreifen erfordern, wie etwa die automatische Erstellung eines Tickets. So können Teams schrittweise auf eine vollautomatische Problemlösung hinarbeiten, sodass beim Auftreten eines bestimmten Problems automatisch die entsprechenden Aktionen durchgeführt werden.

Red Hat Ansible Automation Platform ist eine End-to-End-Automatisierungsplattform, die IT-Teams bei der Erstellung, Verwaltung und Skalierung von Automatisierungsprozessen im gesamten Unternehmen unterstützt. Mit Webhooks können Sie Ansible Automation Platform über einen Service wie GitHub oder GitLab in ein Git Repository integrieren, um IaC- und GitOps-Praktiken zu unterstützen. Sobald ein Repository-Link eingerichtet ist, erfasst Ansible Automation Platform Git-Commits aus dem Git-System. Mit diesen Events werden Automatisierungsjobs ausgelöst, die Projekte aktualisieren, Inventories managen und Deployments durchführen.

Webhooks ermöglichen Ihnen die automatische Aktivierung von Automatisierungsprozessen, wenn Events in Ihrem Versionskontrollsystem auftreten. Dadurch werden zusätzliche CI/CD-Tools wie Jenkins zur Überwachung von Repositories und zum Starten von Automatisierungsjobs bei Änderungen überflüssig. Außerdem wird Ihr GitOps-Workflow vereinfacht, und die Abläufe werden optimiert. Da Ansible Automation Platform mit einer Vielzahl von Entwicklungs- und Deployment-Tools arbeitet, können Sie Ihren GitOps-Workflow an Ihre bevorzugten Tools und Prozesse anpassen.

Geschäftskritische Automatisierung mit Event-Driven Ansible 

Als Teil von Ansible Automation Platform bietet Event-Driven Ansible die notwendigen Event-Handling-Funktionen, um zeitaufwendige Aufgaben zu automatisieren und auf veränderte Bedingungen in beliebigen IT-Domains zu reagieren. Event-Driven Ansible kann Events, die diskrete Informationen über die Bedingungen in der IT-Umgebung enthalten, verarbeiten, die geeignete Reaktion auf das Event bestimmen und anschließend automatisierte Aktionen zur Lösung oder Problembehebung des Events durchführen.

Mit Event-Driven Ansible lassen sich Aufgaben für das IT-Servicemanagement, wie Ticket-Erweiterung, Problembehebung und Benutzerverwaltung, sowie eine Vielzahl weiterer IT-Prozesse automatisieren. Es verknüpft Event-Quellen über Regeln mit entsprechenden Aktionen. Ansible Rulebooks definieren die Event-Quelle und erklären in Form von bedingten „Wenn-Dann“-Befehlen die Aktion, die beim Auftreten des Events ausgeführt werden soll. Anhand des von Ihnen entworfenen Rulebooks erkennt Event-Driven Ansible das angegebene Event, ordnet es der entsprechenden Aktion zu und führt diese automatisch aus.

Sie können vollständig unterstützte generische Webhooks verwenden, um Event-Driven Ansible mit Event-Quellen zu verbinden. Event-Driven Ansible bietet außerdem eine Library mit Quell-Plugins, die von Partnern für ihre spezifische Technologie entwickelt wurden. Mit diesen vollständig unterstützten Plugins können Sie eventgesteuerte Automatisierung aufbauen, ohne Code entwickeln oder Webhooks für jedes neue Event programmieren zu müssen. Sie müssen nur wissen, an welchem Event Sie interessiert sind und welche Aktion Sie durchführen möchten. Dann schreiben Sie diese Anweisungen in ein Ansible Rulebook, mit dem jedes Event automatisch ein bereits vorhandenes Ansible Playbook oder einen gewünschten Automatisierungs-Workflow ausführen kann.