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 et orientée événements. Utilisés par diverses applications web 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 dans des environnements GitOps.

Comme les webhooks peuvent connecter des sources d'événements à des solutions d'automatisation, ils s'utilisent aussi pour lancer l'automatisation orientée événements afin d'exécuter des actions informatiques lorsqu'un événement spécifique se produit.

Interfaces de programmation d'application (API)

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é par le 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 à d'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 que l'événement voulu se produise.

Différences des webhooks

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 du client dès que l'événement spécifié survient. 

On qualifie souvent les webhooks d'API inversées ou d'API « push », car ils 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 le client qui envoie des requêtes en continu. Malgré leurs surnoms, les webhooks ne sont pas des API. Ces deux systèmes fonctionnent toutefois ensemble. Pour utiliser un webhook, une application doit disposer d'une API. 

Le mot « webhook » est composé des termes « web », qui renvoie à 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 via des 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.

Avantages des webhooks :

• Ils remplacent l'interrogation continue. L'application client économise ainsi des ressources. 
• Ils sont rapides à configurer. S'ils sont pris en charge, les webhooks peuvent être facilement configurés via l'interface utilisateur de l'application du serveur. C'est là que le client ajoute l'URL de son webhook et définit les paramètres de base, comme l'événement qui l'intéresse.   
• Ils automatisent le transfert de données. Les données utiles sont envoyées dès que l'événement recherché se produit. C'est cet événement qui déclenche l'échange, qui s'effectue donc aussi rapidement que tout transfert en temps réel.
• Ils conviennent parfaitement aux données utiles légères et spécifiques. Les webhooks ont besoin du serveur pour déterminer la quantité de données utiles à envoyer. Le client doit ensuite interpréter les informations lui-même et les utiliser à bon escient. Puisque le client ne contrôle ni le moment exact ni la taille du transfert de données, les webhooks transmettent quelques informations entre deux points de terminaison, souvent sous la forme d'une notification.

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

IaC (Infrastructure-as-Code) 

L'IaC (Infrastructure-as-Code, ou infrastructure en tant que code) est une pratique qui 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.

Avec l'automatisation du provisionnement de l'infrastructure selon l'approche IaC, les équipes de développement 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'elles 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 toujours ê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.

GitOps

Souvent considéré comme une évolution de l'IaC, le GitOps est une approche stratégique de gestion de l'infrastructure et des configurations d'applications qui repose sur l'utilisation de Git, un système de contrôle des versions Open Source. En application des pratiques GitOps, les équipes de développement utilisent Git comme source unique de vérité pour la formalisation déclarative de l'infrastructure et des applications, et utilisent les requêtes « pull » Git pour la gestion automatique du provisionnement et du 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. 

Rôle des 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 de l'IaC entiers. Dans un environnement GitOps, avec un référentiel Git comme source de vérité, 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 d'utiliser des webhooks pour notifier le moteur d'états souhaités à chaque fois qu'un changement est effectué dans le référentiel Git. Si un morceau de code est mis à jour et transmis par la commande push au référentiel, 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.

Si le moteur d'états souhaités prend en charge l'automatisation, ces webhooks peuvent également lancer des workflows de l'IaC, transformant alors une modification de code en action automatisée. Par exemple, les équipes d'administration système peuvent mettre en place des processus automatisés qui s'exécutent à chaque fois qu'un webhook reçoit des données utiles, afin d'appliquer automatiquement les modifications de code à leurs hôtes gérés et de rétablir leur état par défaut. Cette méthode d'utilisation des webhooks pour déclencher des processus automatisés peut être étendue afin d'exécuter d'autres actions informatiques sans intervention humaine. On parle alors d'automatisation orientée événements.

La seule différence réside dans la source de vérité. Plutôt que d'être connecté à un référentiel Git (qui nécessite que des utilisateurs publient les mises à jour du code), le moteur d'états souhaités va être connecté par un webhook à un outil tiers qui surveille une source pour détecter des événements spécifiques. Une fois que ces sources d'événements détectent un événement précis et déclenchent le webhook, les données utiles peuvent lancer le processus automatisé qui exécute des mesures immédiates pour traiter l'événement à tout moment, sans aucune intervention de l'équipe informatique.

L'automatisation orientée événements est un processus qui permet de répondre automatiquement aux conditions changeantes d'un environnement informatique, dans l'objectif de résoudre les problèmes plus rapidement et de réduire les tâches courantes et répétitives. Grâce à l'automatisation orientée événements, les équipes informatiques peuvent codifier les réponses à n'importe quel événement (problèmes matériels, attaques collectives par saturation de service, mémoire insuffisante, défaillances d'applications, etc.), afin que l'action requise soit automatiquement exécutée lorsque l'événement se produit.

Les solutions orientées événements s'appuient sur des outils ou des plug-ins tiers, tels que ServiceNow, Kafka, Prometheus, Sensu, Dynatrace et Appdynamics, pour surveiller les événements issus d'une source. Il est possible d'utiliser des webhooks pour connecter ces sources d'événements à une plateforme d'automatisation. Ainsi, lorsqu'une source détecte un événement, le webhook déclenche la réponse automatisée adéquate.

Les équipes informatiques peuvent adopter progressivement l'automatisation orientée événements pour réduire le temps moyen de résolution et exécuter des fonctions qui requièrent toujours une intervention humaine, par exemple la création automatique d'un ticket, avant d'évoluer vers une correction entièrement automatique, afin que l'action appropriée soit automatiquement exécutée lorsqu'un problème particulier se présente.

Red Hat Ansible Automation Platform est une plateforme d'automatisation de bout en bout conçue pour aider les équipes informatiques à créer, gérer et mettre à l'échelle leurs processus automatisés dans toute l'entreprise. Il est possible d'utiliser des webhooks pour associer Ansible Automation Platform à un référentiel Git, via un service tel que GitHub ou GitLab, pour faciliter l'application des pratiques IaC et GitOps. 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, de gérer des inventaires et de réaliser des déploiements.

Les webhooks permettent d'activer automatiquement des processus automatisés lorsque certains événements surviennent dans le 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 le workflow GitOps et l'exploitation. Vous pouvez aussi adapter votre workflow GitOps aux outils et processus de votre choix, car Ansible Automation Platform fonctionne avec un large éventail d'outils de développement et déploiement.

Automatisation essentielle avec Event-Driven Ansible 

Event-Driven Ansible, qui fait partie d'Ansible Automation Platform, offre les fonctionnalités de traitement des événements nécessaires pour automatiser les tâches chronophages afin de s'adapter à l'évolution des conditions dans tous les domaines informatiques. Ce composant peut traiter des événements qui contiennent des informations particulières sur les conditions de l'environnement informatique, déterminer la réponse appropriée à un événement, puis exécuter des actions automatisées pour le traiter ou le corriger.

Event-Driven Ansible permet d'automatiser les tâches de gestion des services informatiques, comme l'amélioration des tickets, la correction et la gestion des utilisateurs, ainsi que divers autres processus informatiques. Il associe les sources d'événements aux actions correspondantes par le biais de règles. Les rulebooks Ansible définissent la source de l'événement et expliquent, sous la forme d'instructions conditionnelles de type « si ceci, alors cela », l'action à entreprendre lorsque l'événement se produit. Selon le rulebook que vous avez conçu, Event-Driven Ansible reconnaît l'événement décrit, l'associe à l'action appropriée et l'exécute automatiquement.

Vous pouvez utiliser des webhooks génériques entièrement pris en charge pour connecter Event-Driven Ansible à des sources d'événements. Event-Driven Ansible propose également une bibliothèque de plug-ins de sources conçus par des partenaires pour leur propre technologie. Ces plug-ins intégralement pris en charge vous permettent de créer des processus automatisés orientés événements sans avoir à écrire du code ni à programmer un webhook pour chaque nouvel événement. Il vous suffit de savoir quel événement vous intéresse et quelle action vous souhaitez exécuter, puis d'écrire ces instructions dans un rulebook Ansible, qui permet à chaque événement d'exécuter automatiquement les playbooks Ansible préexistants ou le workflow d'automatisation de votre choix.