Hosting di una destinazione di webhook

Questa guida mostra come ospitare una destinazione di webhook in un servizio Knative serving.

Funzioni Cloud Run e pubblicazione Knative

Le funzioni di Cloud Run e Knative serving forniscono entrambe buone soluzioni per ospitare i target dei webhook. In genere, le funzioni di Cloud Run sono rapide da configurare, ideale per la prototipazione e ideale per flussi di lavoro a basso volume. Knative serving offre maggiore flessibilità ed è in grado di gestire volumi più grandi in contemporanea.

Utilizza Knative serving se:

  • Utilizzi linguaggi o runtime non supportati nelle funzioni Cloud Run
  • Vuoi timeout delle richieste più lunghi (fino a 15 minuti)
  • Prevedi un volume elevato e hai bisogno di contemporaneità (80 richieste in parallelo o più per istanza di container)

Creazione di un target webhook in Knative serving

Con Knative serving, puoi definire un target per il webhook in qualsiasi lingua scegliere. Devi solo creare un endpoint HTTP in grado di accettare i dati. In genere, questa operazione viene eseguita con un POST, ad esempio:

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()

Nell'esempio precedente, la pagina di indice dell'URL è configurata per accettare solo POST richiede e si aspetta che i dati vengano consegnati tramite un payload JSON.

Integrazione con il provider webhook

La maggior parte dei servizi che forniscono callback HTTP richiede la verifica della proprietà dell'URL. In genere, questo viene fatto inviando un tipo di token, messaggio o segreto e aspettandosi una risposta valida. Dovrai ottenere questi requisiti dal fornitore di servizi. Utilizzando lo stesso esempio riportato sopra, il codice potrebbe avere il seguente aspetto:

def index():
    data = request.get_json()
    return data['challenge']

Dopo che il fornitore avrà verificato la tua proprietà, dovrai aggiungere l'autorizzazione anche da parte tua.

Autorizzazione delle richieste

Un target webhook è un URL aperto e pubblico. La maggior parte dei servizi fornisce un token o un segreto per garantire che le richieste in arrivo provengano da servizi autorizzati. Poiché l'URL è pubblico, non puoi impedire tentativi malintenzionati di inviare dati al target dell'webhook. Tuttavia, l'utilizzo di token o segreti ti garantisce di elaborare solo i dati provenienti da fonti autorizzate.

Per verificare la richiesta, puoi configurare i secret o memorizzare la copia del secret come variabile di ambiente o utilizzando un qualche tipo di sistema di gestione delle chiavi.

Quando memorizzi la copia del secret come variabile di ambiente, ogni richiesta deve avere un secret o un token negli header della richiesta o nel payload JSON e devi controllarlo per assicurarti che l'origine sia valida.

def index():
    request_secret = request.headers['Secret']
    if request_secret != os.environ['SECRET']:
        return ('Unauthorized', 401)

Se il fornitore di webhook non supporta un segreto o un altro meccanismo di autenticazione, chiunque disponga dell'URL del target dell'webhook potrà inviare messaggi. In questo caso, l'implementazione del webhook deve essere esposta in sicurezza nella rete internet pubblica.

Rispondere alle richieste

La maggior parte dei servizi richiede di rispondere a una richiesta entro un determinato periodo di tempo, come specificato dal servizio. Alcuni webhook hanno metodi di ripetizione integrati se viene generata una risposta di errore, ad esempio un codice di stato HTTP 4xx o 5xx, pertanto dovrai restituire un codice di stato di esito positivo (2xx) per comunicare al servizio che l'evento è stato elaborato correttamente.

def index():
    data = request.get_json()
    return ('', 200)

Timeout

Sia Knative serving che il provider di webhook hanno dei timeout. Il valore più breve dei due verrà applicato alla tua richiesta. Se l'elaborazione dei dati supera il tempo allocato dal servizio Knative o dal provider di webhook, devi utilizzare un prodotto che ti consenta di completare l'elaborazione in modo asincrono, ad esempio Pub/Sub o Cloud Tasks. Questi prodotti ti consentono trasferire rapidamente i dati, restituire immediatamente una risposta positiva al di webhook e continua l'elaborazione senza il problema di timeout. Sono anche ottime opzioni per gestire errori e tentativi di nuovo.

Pattern comuni dei webhook

Tipo Esempi
Trasmissione dati Invio di una notifica tramite Firebase Cloud Messaging ogni volta che viene chiamato l'webhook.
Archiviazione dei dati Archiviazione dei dati in BigQuery per analisi successive.
Azioni di attivazione Eseguire le azioni su Dialogflow, pubblicare risposte su Twitter o eseguire il push nell'ambiente di gestione temporanea ogni volta che viene eseguito il commit di nuovo codice in GitHub.

Passaggi successivi