Un webhook, qu'est-ce que c'est ?

Un webhook est une fonction de rappel basée sur le protocole HTTP. Il permet à deux interfaces de programmation d'application (API) d'établir une communication légère orientée événements. Si des applications de toutes sortes les utilisent pour réceptionner de petites quantités de données en provenance d'autres applications, les webhooks peuvent également déclencher les workflows d'automatisation des environnements GitOps.

Une API, qu'est-ce que c'est ?

Une API est un ensemble de définitions et de protocoles qui facilite la création et l'intégration de logiciels d'applications. La communication entre API est parfois considérée comme un contrat entre un utilisateur d'informations et un fournisseur d'informations, qui permet de définir le contenu demandé au consommateur (l'appel) et le contenu demandé au producteur (la réponse). Cette relation peut également se décrire par une demande de l'application client à l'application du serveur, mais il est possible d'inverser les rôles en fonction de la situation et de l'application qui demande les données.  

En général, les API web passent par le protocole HTTP pour demander des données aux autres applications et définir la structure de leurs réponses. Ces dernières se présentent souvent sous forme de messages XML ou JSON. Ces deux formats sont les plus courants, car les données qu'ils contiennent sont faciles à manipuler pour les autres applications. 

Lorsqu'une API client demande des données à une API de serveur, c'est pour déterminer si un certain événement s'est produit, en d'autres termes si les données du serveur ont connu un changement dont pourrait bénéficier le client. Dans ce processus (appelé « interrogation »), le client envoie des demandes HTTP régulières jusqu'à ce que l'API du serveur envoie ce que l'on appelle parfois les « données utiles ». 

L'application client, qui ne connaît pas le statut de celle du serveur, interroge l'API de ce dernier à répétition jusqu'à ce que l'événement recherché survienne. Le serveur, quant à lui, ne peut envoyer ces données qu'une fois qu'elles sont disponibles. L'application client doit donc continuer à demander des mises à jour en attendant l'arrivée de l'événement voulu.

Pourquoi les webhooks sont-ils différents des API ?

Pour configurer un webhook, le client transmet une URL unique à l'API du serveur et lui précise l'événement qui l'intéresse. Ensuite, il n'est plus nécessaire d'interroger le serveur : celui-ci envoie automatiquement les données utiles vers l'URL du webhook client dès que l'événement requis survient. 

On qualifie souvent les webhooks d'API inversées ou d'API « push », car elles confient la communication au serveur au lieu du client. C'est le serveur qui envoie au client une demande HTTP POST unique dès que les données sont disponibles, et non plus le client qui envoie des requêtes en continu. Malgré leurs surnoms, les webhooks ne sont pas des API, mais ces deux systèmes fonctionnent ensemble. Pour utiliser un webhook, une application doit disposer d'une API. 

Le mot « webhook » est composé des termes « web », à savoir la communication basée sur le protocole HTTP, et « hook », qui signifie « script automatique ». Il s'agit de la fonction de programmation qui permet aux applications de réceptionner les demandes et les autres événements intéressants. Les webhooks interceptent l'événement qui survient sur l'application du serveur, puis déclenchent l'envoi des données utiles au client par le Web. C'est en partie grâce à Jeff Lindsay et son article de blog « Web hooks to revolutionize the web », publié en 2007, que ce concept s'est répandu.

Les équipes informatiques utilisent plusieurs méthodes pour protéger les applications qui communiquent par webhooks. La plupart de ces applications ajoutent une clé secrète au titre de la demande de données utiles, ce qui permet au client de vérifier l'identité du serveur. Les webhooks sont souvent protégés par l'authentification mTLS (mutual Transport Layer Security) qui contrôle à la fois le client et le serveur avant l'envoi des données utiles. Il n'est pas rare que les applications client utilisent également le chiffrement SSL sur l'URL des webhooks afin d'assurer la confidentialité du transfert.

La plupart du temps, les webhooks sont utilisés pour simplifier la communication entre deux applications, mais ils peuvent également servir à automatiser des workflows IaC (Infrastructure-as-code) et à appliquer des pratiques GitOps.

L'IaC (Infrastructure-as-Code), qu'est-ce que c'est ? 

L'IaC (Infrastructure-as-Code, ou Infrastructure en tant que code) consiste à gérer et provisionner une infrastructure à l'aide de lignes de code plutôt que de processus manuels. Le contrôle des versions est une partie importante de l'IaC : les fichiers de configuration doivent être gérés par un système de contrôle de source comme n'importe quel autre fichier de code source de logiciel. Le déploiement de type IaC permet également de scinder l'infrastructure en modules qui peuvent ensuite être combinés de différentes façons, de manière automatisée.

Par l'automatisation du provisionnement de l'infrastructure selon l'approche IaC, les développeurs n'ont plus besoin de provisionner ni de gérer manuellement les serveurs, les systèmes d'exploitation, le stockage et les autres composants de l'infrastructure chaque fois qu'ils développent ou déploient une application. La codification de l'infrastructure fournit un modèle à suivre pour le provisionnement. Bien que ces processus puissent être effectués manuellement, il est possible de les automatiser grâce à un moteur d'états souhaités conçu pour les entreprises, tel que Red Hat® Ansible Automation® Platform.

Le GitOps, qu'est-ce que c'est ?

Souvent considéré comme une évolution de l'IaC, le GitOps désigne une approche stratégique de gestion de l'infrastructure et des configurations d'applications qui reposent sur l'utilisation de Git, un système de contrôle des versions Open Source. Les développeurs appliquent les pratiques GitOps, à savoir utiliser Git comme source unique de vérité pour la formalisation déclarative de l'infrastructure et des applications, et utiliser les requêtes « pull » Git pour la gestion automatique du provisionnement et le déploiement de l'infrastructure. Le référentiel Git contient l'état complet du système, ce qui signifie que tous les changements sont visibles et vérifiables. 

Quel est le lien avec les webhooks ?

Les webhooks simplifient la mise en œuvre et la gestion des pipelines de déploiement axés sur Git. Ils peuvent servir à lancer automatiquement des workflows IaC entiers. Dans un environnement GitOps, un webhook a le même rôle qu'entre deux applications : un événement précis déclenche l'envoi de données utiles d'une API à une autre. La différence réside dans le type d'événement déclencheur et dans l'usage qui est fait des données.

Dans ce contexte, le référentiel Git joue le rôle de l'application du serveur, tandis que le moteur d'états souhaités (qui gère l'état de l'infrastructure) correspond à celle du client. Il est possible de configurer un webhook afin de déclencher la communication dès qu'un changement survient dans le référentiel. Par exemple, si un morceau de code est mis à jour et transmis par push au référentiel Git, cet événement déclenche le webhook. Le référentiel envoie alors automatiquement les données utiles à l'adresse du moteur d'états souhaités pour l'informer du changement de code.

Cette utilisation des webhooks permet aux moteurs d'états souhaités de suivre de près tout changement dans l'infrastructure, sans surveillance active des référentiels. Si le moteur prend également en charge l'automatisation, les webhooks peuvent déclencher des workflows IaC. Dans le cas d'un moteur d'états souhaités conçu pour les entreprises, comme Red Hat Ansible Automation Platform, un administrateur système peut utiliser des webhooks pour déployer automatiquement les derniers changements sur ses hôtes gérés.

La solution Red Hat® Ansible® Automation Platform intègre des webhooks d'automatisation compatibles avec les pratiques IaC et GitOps. Les webhooks permettent l'intégration native d'un référentiel Git à Ansible Automation Platform, via un service comme GitHub ou GitLab. Une fois le lien établi, Ansible Automation Platform détecte les validations Git et utilise ces événements pour déclencher des tâches d'automatisation afin de mettre à jour des projets, gérer des inventaires et réaliser des déploiements.

Les webhooks vous permettent d'activer automatiquement des workflows d'automatisation lorsque certains événements surviennent dans votre système de contrôle de source. Ainsi, aucun autre outil de CI/CD (p. ex. Jenkins) n'est requis pour surveiller les référentiels et lancer des tâches d'automatisation en cas de modifications, ce qui simplifie votre workflow GitOps et l'exploitation. Vous pouvez en outre adapter ce workflow aux outils et processus de votre choix, car Red Hat Ansible Automation Platform fonctionne avec un large éventail d'outils de développement et déploiement.