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.

Cos'è un'API?

Le API, acronimo di Application Programming Interface (interfaccia di programmazione delle applicazioni) sono set di definizioni e protocolli con i quali vengono realizzati e integrati software applicativi. Le comunicazioni tra API possono essere considerate come un contratto tra 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 utilizzando il protocollo HTTP per richiedere i dati ad altre app e definire la struttura dei messaggi di risposta, che spesso assumono la forma di 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, cioè 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.

Come funzionano 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 di 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 sarà il client che invia le richieste HTTP chiedendo i dati fino a quando il server risponde, ma è il server che invia al cliente una sola richiesta HTTP POST non appena i dati sono disponibili. Benché abbiano queste denominazioni, i webhook non sono API, ma funzionano insieme a queste. Per utilizzare un webhook, un'applicazione deve disporre 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 di interesse. 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.

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)? 

Con Infrastructure as Code (IaC) intendiamo un approccio alla gestione e al provisioning dell'infrastruttura che avviene tramite codice anziché con processi manuali. Per l'IaC il controllo 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. Implementare 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, un'attività che può essere eseguita manualmente ma anche automatizzata con un motore della condizione target di livello enterprise, come Red Hat® Ansible Automation® Platform.

Che cos'è GitOps?

Spesso considerato un'evoluzione di IaC, GitOps è un approccio strategico per la 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 relative a tale condizione. 

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, il webhook funziona come tra due applicazioni: quando è attivato da un evento specifico, un'API invia un payload a un'altra API. La differenza sta nel tipo di evento che attiva il webhook e dal 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 configurato per attivare la comunicazione al verificarsi di una modifica nel repository. Ad esempio, una parte di codice che viene aggiornata e inviata al repository Git è 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.

Questo impiego dei webhook consente ai motori di gestione della condizione target di mantenere chiuse le schede relative alle modifiche all'infrastruttura, senza dover attivamente monitorare i repository. Se il motore supporta anche l'automazione, i webhook possono attivare anche i flussi di lavoro IaC. Ad esempio, con un motore per la gestione della condizione target di livello enterprise come Red Hat Ansible Automation Platform, un amministratore di sistema può utilizzare i webhook per distribuire automaticamente le modifiche più recenti apportate agli host gestiti.

In Red Hat® Ansible® Automation Platform sono integrati alcuni webhook di automazione, che consentono di supportare le procedure IaC e GitOps. I webhook consentono l'integrazione nativa di un repository Git, tramite un servizio quale GitHub o GitLab, con Ansible Automation Platform. 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 di deployment.

Con i webhook di automazione puoi attivare automaticamente i flussi di lavoro di automazione quando gli eventi si verificano nel sistema di controllo della sorgente. Si evita così di dover ricorrere ad altri strumenti CI/CD per monitorare i repository e lanciare le attività di automazione in presenza di modifiche, semplificando così il flusso di lavoro GitOps e ottimizzando le operazioni. Red Hat Ansible Automation Platform funziona 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.