Red Hat Summit
Überblick
Ein Webhook ist eine HTTP-basierte Rückmeldungsfunktion, die eine schlanke, event-gesteuerte Kommunikation zwischen zwei APIsermö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.
Webhooks für die Anwendungsentwicklung
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 so genannten 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, gibt 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 Anrufe 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 „Web Hooks to revolutionize the web“ aus dem Jahr 2007 bekannt gemacht.
IT-Teams verwenden eine Vielzahl von Methoden, um Anwendungen zu schützen, die über Webhooks kommunizieren. Die meisten Webhook-fä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 Polling. 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 auf 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 zwei Endpunkten, oft in Form einer Benachrichtigung.
Webhooks für die Entwicklung der Infrastruktur
Webhooks werden in der Regel zur Vereinfachung der Kommunikation zwischen zwei 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 diese 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 der 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 alle Ä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 funktioniert ein Webhook genauso wie zwischen zwei 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 mit dem gewünschten Zustand, die den Infrastrukturzustand verwaltet, die Rolle der Client-App übernimmt. Ein Webhook kann eingerichtet werden, um die Kommunikation auszulösen, sobald eine Änderung im Repository vorgenommen wird. Wenn zum Beispiel ein Stück Code aktualisiert und in das Git Repository übertragen wird, löst dieses Event den Webhook aus. Das Repository sendet dann automatisch die Payload an die Webhook-Adresse der Engine im gewünschten Zustand und informiert sie über die Codeänderung.
Die Verwendung von Webhooks auf diese Weise ermöglicht es den Engines mit dem gewünschten Zustand, alle Infrastrukturänderungen zu verfolgen, ohne die Repositories aktiv überwachen zu müssen. Wenn die Engine mit dem gewünschten Zustand außerdem Automatisierung unterstützt, können Webhooks verwendet werden, um IaC-Workflows auszulösen. Beispielsweise können Systemadministrationsteams mit einer unternehmensgerechten Engine für den gewünschten Zustand – wie der Red Hat Ansible Automation Platform – mithilfe von Webhooks automatisch die neuesten Änderungen auf den gemanagten Hosts bereitstellen.
Wie kann Red Hat Sie unterstützen?
Die Red Hat® Ansible® Automation Platform verfügt über integrierte Automatisierungs-Webhooks zur Unterstützung von IaC- und GitOps-Praktiken. Webhooks ermöglichen die native Integration eines Git Repositorys über einen Service wie GitHuboder GitLab in die Ansible Automation Platform. Sobald ein Repository-Link eingerichtet ist, erfasst die 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.
Automatisierungs-Webhooks ermöglichen es Ihnen, Automatisierungs-Workflows automatisch zu aktivieren, wenn Events in Ihrem Versionsverwaltungssystem 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 die Red Hat Ansible Automation Platform mit einer Vielzahl von Entwicklungs- und Deployment-Tools arbeitet, können Sie Ihren GitOps-Workflow Ihren bevorzugten Tools und Prozessen anpassen.
