Cos'è un webhook?

Un webhook è una funzione di callback HTTP che consente a due interfacce di programmazione delle applicazioni (API) di comunicare in modo semplice e basato sugli eventi. Funzionali a numerose app web per la ricezione di piccole quantità di dati da altre app, possono anche attivare flussi di lavoro di automazione in ambienti GitOps.

Poiché sono in grado di collegare le sorgenti di eventi alle soluzioni di automazione, i webhook vengono utilizzati per eseguire determinate azioni IT attraverso l'automazione basata sugli eventi al verificarsi di un evento specifico.

Cos'è un'API?

Le API, ovvero interfacce di programmazione delle applicazioni, sono set di definizioni e protocolli con i quali vengono realizzati e integrati software applicativi. Le comunicazioni tra API sono paragonabili al tipo di interazione che lega un fornitore di informazioni e l'utente destinatario di tali dati: l'API stabilisce il contenuto richiesto dal consumatore (la chiamata) e il contenuto richiesto dal produttore (la risposta). Questa relazione è anche descritta come la chiamata dall'app client all'app server, ma i ruoli possono essere invertiti, a seconda di quale app richiede i dati in una determinata situazione.  

In genere, le API web utilizzano il protocollo HTTP per richiedere i dati ad altre app e definire la struttura dei messaggi di risposta, che spesso sono file XML o JSON, due formati diffusi perché presentano i dati in modo da consentire alle altre app di gestirli facilmente. 

Quando un'API client richiede dati a un'API server, esegue una chiamata per controllare il verificarsi di un determinato evento, ovvero se i dati del server sono stati modificati in un modo che può essere utile al client. Durante questo processo, noto come polling, il client invia a intervalli regolari una richiesta HTTP, fino a quando l'API del server invia i dati richiesti, in un processo noto come payload. 

L'app client non conosce lo stato dell'app server, quindi esegue il polling all'API del server per chiedere un aggiornamento, con chiamate regolari fino al verificarsi dell'evento specifico; il server invia i dati richiesti solo quando le informazioni sono disponibili. L'app client continua a richiedere l'aggiornamento e attende fino al verificarsi dell'evento pertinente.

Cosa distingue i webhook?

Per configurare un webhook, il client fornisce un URL univoco all'API server e specifica l'evento su cui richiede informazioni. Una volta configurato il webhook, il client non deve più eseguire il polling al server, poiché sarà quest'ultimo a inviare automaticamente il payload richiesto all'URL del webhook del client, non appena si verifica l'evento specificato. 

I webhook vengono spesso chiamati anche API inverse o API push, perché fanno ricadere la responsabilità della comunicazione sul server e non sul client. Non è il client a inviare le richieste HTTP di dati per poi attendere la risposta del server, ma è il server che invia al client una singola richiesta HTTP POST non appena i dati sono disponibili. Nonostante i nomi con cui vengono definiti, i webhook non sono API, ma vengono utilizzati insieme a queste ultime. Infatti, un'applicazione può utilizzare un webhook solo se dispone di un'API. 

Il nome webhook è la combinazione dei termini web, in riferimento alla comunicazione basata su HTTP, e hooking, in riferimento alla funzione di programmazione che consente alle app di intercettare le chiamate o altri eventi rilevanti. I webhook "agganciano" l'evento che si verifica sull'app server e chiedono al server di inviare il payload al client tramite web. Jeff Lindsay ha contribuito a divulgare il concetto con un articolo del 2007 intitolato: "Web hooks to revolutionize the web".

Per proteggere le app che comunicano tramite webhook, i team IT si avvalgono di numerosi metodi. Quasi tutte le app compatibili con i webhook aggiungono un codice segreto all'intestazione della richiesta di payload, in modo che il client possa confermare l'identità del server. I webhook sono spesso protetti dall'autenticazione mTLS (Mutual Transport Layer Security), che verifica il client e il server prima dell'invio del payload. Per garantire che i dati trasferiti restino privati, spesso le app client utilizzano la crittografia SSL per l'URL del webhook.

I webhook: 

• Eliminano la necessità del polling. Ciò consente di risparmiare le risorse dell'applicazione client. 
• Si configurano rapidamente. In un'app compatibile con i webhook, la configurazione di questi avviene facilmente tramite l'interfaccia utente dell'app server, nella quale il client inserisce l'URL dei webhook della propria app e configura alcuni parametri di base, come l'evento a cui sono interessati.   
• Automatizzano i trasferimenti dei dati. Il payload viene inviato non appena l'evento specificato si verifica sull'app server. Lo scambio è inizializzato dall'evento stesso, pertanto avviene non appena è possibile trasferire i dati dal server al client, sostanzialmente in tempo reale come qualsiasi altro trasferimento di dati.
• Sono una soluzione valida per payload specifici e leggeri. I webhook fanno affidamento sul server per determinare la quantità di dati inviata e lasciano al client il compito di interpretare il payload e di utilizzarlo in modo efficiente. Poiché il client non controlla l'esattezza dei tempi o delle dimensioni del trasferimento dei dati, i webhook gestiscono piccole quantità di dati tra due endpoint, spesso in forma di notifica.

In linea di massima, i webhook vengono utilizzati per semplificare la comunicazione tra due applicazioni, ma sono anche in grado di automatizzare i flussi di lavoro Infrastructure as Code (IaC) e attivare procedure GitOps.

Cosa si intende con Infrastructure as Code (IaC)? 

Infrastructure as Code (IaC) è un approccio alla gestione e al provisioning dell'infrastruttura che avviene tramite codice anziché con processi manuali. Per l'IaC il controllo della versione è un aspetto cruciale e i file di configurazione dovrebbero essere sottoposti al controllo della sorgente come qualsiasi altro file di codice sorgente del software. Distribuire l'infrastruttura in forma di codice permette la suddivisione in componenti modulari che, attraverso l'automazione, possono essere combinati in modi diversi.

Automatizzare il provisioning dell'infrastruttura con l'IaC alleggerisce il carico sugli sviluppatori, che non devono più svolgere manualmente le attività di provisioning e gestione di server, sistemi operativi, storage e altri componenti dell'infrastruttura ogni volta che sviluppano o distribuiscono un'applicazione. Codificare l'infrastruttura permette di creare un modello di provisioning ripetibile, una procedura che può essere eseguita manualmente ma anche automatizzata con un motore per la gestione della condizione target progettato per le aziende, come Red Hat® Ansible® Automation Platform.

Cos'è GitOps?

Spesso considerato un'evoluzione di IaC, GitOps è un approccio strategico alla gestione delle configurazioni di applicazioni e infrastrutture basata su Git, un sistema di controllo delle versioni open source. Seguendo le procedure GitOps, gli sviluppatori utilizzano Git come singola fonte di attendibilità per le applicazioni e l'infrastruttura dichiarativa, e le richieste pull Git per gestire automaticamente il provisioning e il deployment dell'infrastruttura. Il repository Git contiene informazioni complete sulla condizione del sistema, permettendo di visualizzare e controllare la traccia delle modifiche. 

Qual è il ruolo dei webhook?

I webhook riducono i passaggi necessari a implementare e gestire le pipeline di deployment incentrate su Git, e possono avviare automaticamente flussi di lavoro IaC completi. In un ambiente GitOps, con un repository Git come fonte di attendibilità, il webhook funziona come tra due applicazioni: quando è attivato da un evento specifico, un'API invia un payload a un'altra API. La differenza risiede nel tipo di evento che attiva il webhook e nel modo in cui il destinatario utilizza il payload.

In questo contesto, il repository Git svolge il ruolo dell'app server, mentre il motore per la gestione della condizione target, che gestisce lo stato dell'infrastruttura, svolge il ruolo dell'app client. Il webhook può essere utilizzato per comunicare al motore per la gestione della condizione target il verificarsi di una modifica nel repository. Una parte di codice che viene aggiornata e inviata al repository è l'evento che attiva il webhook. Al suo verificarsi, il repository invia automaticamente il payload all'indirizzo del webhook del motore per la gestione della condizione target, comunicando la modifica al codice.

Se il motore per la gestione della condizione target supporta l'automazione, i webhook possono attivare anche i flussi di lavoro IaC, trasformando una modifica del codice in un'azione automatizzata. Ad esempio, gli amministratori di sistema possono fare in modo che l'automazione venga eseguita ogni volta che si riceve il payload di un webhook, così da applicare automaticamente le nuove modifiche al codice sugli host gestiti e ripristinarli alla condizione di default. L'uso dei webhook per avviare l'automazione può essere esteso anche all'esecuzione di altre azioni IT senza interventi manuali: il processo è noto come automazione basata sugli eventi.

La sola differenza è la fonte di attendibilità. Anziché a un repository Git, in cui gli aggiornamenti del codice sono manuali, un webhook può collegare un motore per la gestione della condizione target a uno strumento di terze parti che monitora una sorgente di determinati eventi. Quando la sorgente rileva un evento target e attiva il webhook, il payload può avviare l'automazione; questa agisce immediatamente per risolvere l'evento in qualsiasi momento della giornata, senza che il personale IT debba intervenire.

L'automazione basata sugli eventi è il processo di risposta automatica alle mutate condizioni di un ambiente IT che ha come obiettivo la più rapida risoluzione dei problemi e la riduzione delle attività ordinarie e ripetitive. Grazie a questo approccio, i team IT possono codificare le risposte a qualsiasi evento, tra cui problemi dell'hardware, attacchi DDoS (Distributed Denial of Service), insufficienza di memoria o errori delle applicazioni, in modo che l'azione necessaria venga eseguita in automatico appena l'evento si verifica.

Le soluzioni basate sugli eventi monitorano le sorgenti di eventi utilizzando strumenti o plugin di terze parti, come ServiceNow, Kafka, Prometheus, Sensu, Dynatrace e Appdynamics. I webhook possono essere utilizzati per collegare le sorgenti a una piattaforma di automazione, in modo da innescare la risposta automatizzata necessaria non appena viene rilevato un evento.

I team IT possono integrare l'automazione basata sugli eventi in modo incrementale per ridurre il tempo medio di ripristino ed eseguire funzioni che richiedono ancora l'intervento manuale, come la creazione automatica dei ticket, per poi avanzare gradualmente verso la correzione completamente automatica, che attiva autonomamente la risposta adeguata a un problema specifico.

Red Hat Ansible Automation Platform è una piattaforma di automazione end to end pensata per consentire ai team IT di creare, gestire ed estendere l'automazione in tutta l'azienda. Puoi usare i webhook per integrare Ansible Automation Platform con un repository Git, tramite un servizio come GitHub o GitLab, a supporto delle procedure IaC e GitOps. Una volta configurato il collegamento al repository, Ansible Automation Platform intercetta i commit Git del sistema Git e utilizza tali eventi allo scopo di attivare i processi di automazione per l'aggiornamento dei progetti, la gestione degli inventari e l'esecuzione dei deployment.

Con i webhook puoi innescare automaticamente l'automazione quando gli eventi si verificano nel sistema di controllo della sorgente. Si evita così di dover ricorrere ad altri strumenti CI/CD, come Jenkins, per monitorare i repository e avviare le attività di automazione in presenza di modifiche, semplificando così il flusso di lavoro GitOps e ottimizzando le operazioni. Ansible Automation Platform è compatibile con un'ampia gamma di strumenti di sviluppo e automazione, ed è pertanto possibile personalizzare il flusso di lavoro GitOps con gli strumenti e i processi preferiti.

Usa Event-Driven Ansible per automatizzare attività e processi critici

Integrato in Ansible Automation Platform, Event-Driven Ansible offre le funzionalità di gestione degli eventi necessarie per automatizzare attività che richiedono tempo e per adattarsi ai cambiamenti in qualsiasi ambito IT. Elabora gli eventi contenenti informazioni distinte sulle condizioni dell'ambiente IT, determina la risposta più adeguata e interviene quindi in modo automatico per affrontare e risolvere l'evento.

Event-Driven Ansible può essere utilizzato per automatizzare le attività di gestione dei servizi IT, come il completamento dei ticket, la correzione e la gestione degli utenti, ma anche numerosi processi IT. Collega le sorgenti di eventi con gli interventi corrispondenti tramite regole. Gli Ansible Rulebook definiscono la sorgente degli eventi e spiegano, sotto forma di istruzioni condizionali "if-this-then-that", l'azione da intraprendere quando si verifica un dato evento. In base al rulebook progettato, Event-Driven Ansible riconosce l'evento specificato, lo associa all'azione necessaria e la esegue in modo automatico.

Per collegare Event-Driven Ansible alle sorgenti di eventi puoi utilizzare webhook generici con supporto completo, ma è disponibile anche una libreria di plugin sorgente creati dai partner per le loro tecnologie specifiche. I plugin completamente supportati consentono di creare l'automazione basata sugli eventi senza dover scrivere il codice o programmare webhook per ogni nuovo evento. Basta conoscere l'evento target e l'azione che si vuole attivare, quindi scrivere le istruzioni in un Ansible Rulebook, che consente a ogni evento di eseguire automaticamente qualsiasi Ansible Playbook o flusso di lavoro di automazione già esistente.