Ce guide explique comment héberger une cible de webhook dans un service Knative serving.
Fonctions Cloud Run et Knative serving
Les fonctions Cloud Run et Knative serving fournissent tous deux de bonnes solutions pour héberger vos cibles de webhooks. En règle générale, les fonctions Cloud Run sont rapides à configurer, adaptées au prototypage et idéales pour les workflows de faible volume. Knative serving offre une plus grande flexibilité et permet de gérer des volumes plus importants grâce à la simultanéité.
Utilisez Knative serving dans les cas suivants :
- Vous utilisez des langages ou des environnements d'exécution non compatibles avec les fonctions Cloud Run.
- Vous souhaitez obtenir des délais avant expiration des requêtes plus longs (jusqu'à 15 minutes).
- Vous prévoyez un volume important et vous avez besoin de simultanéité (80 requêtes simultanées ou plus par instance de conteneur).
Créer une cible de webhook dans Knative serving
Knative serving vous permet de définir une cible de webhook dans le langage de votre choix. Il vous suffit de créer un point de terminaison HTTP pouvant accepter les données.
En règle générale, cela se fait avec une requête POST
, par exemple :
@app.route('/', methods=['POST'])
def index():
data = request.get_json()
Dans l'exemple ci-dessus, la page d'index de l'URL est configurée pour n'accepter que des requêtes POST
et s'attend à recevoir des données via une charge utile JSON.
Intégration avec le fournisseur de webhooks
La plupart des services qui fournissent des rappels HTTP vous demandent de valider la propriété de l'URL. Pour ce faire, vous devez généralement envoyer un jeton, un message ou un secret, et attendre une réponse valide. Vous devez obtenir ces exigences auprès du fournisseur de services. En utilisant le même exemple ci-dessus, cela pourrait ressembler à ceci :
def index():
data = request.get_json()
return data['challenge']
Une fois que le fournisseur a validé votre propriété, vous devez également ajouter une autorisation.
Autoriser les requêtes
Une cible de webhook est une URL publique et ouverte. La plupart des services fournissent un jeton ou un secret pour s'assurer que les requêtes entrantes proviennent de services autorisés. Comme l'URL est publique, vous ne pouvez pas empêcher les tentatives malveillantes d'envoi de données à la cible de webhook. Cependant, l'utilisation de jetons ou de secrets garantit que vous ne traitez que les données provenant de sources autorisées.
Pour vérifier la requête, vous pouvez soit configurer les secrets, soit stocker votre copie du secret en tant que variable d'environnement ou en utilisant un système de gestion de clés.
Lorsque vous stockez votre copie du secret en tant que variable d'environnement, chaque requête doit avoir un secret ou un jeton dans son en-tête ou dans la charge utile JSON, et vous devez le vérifier pour vous assurer que la source est valide.
def index():
request_secret = request.headers['Secret']
if request_secret != os.environ['SECRET']:
return ('Unauthorized', 401)
Si le fournisseur de webhooks n'accepte pas de secret ni aucun autre mécanisme d'authentification, toute personne disposant de l'URL de votre cible de webhook pourra envoyer des messages. Dans ce cas, la mise en œuvre de votre webhook doit pouvoir être exposée en toute sécurité sur l'Internet public.
Répondre aux requêtes
La plupart des services nécessitent que vous répondiez à une requête dans un délai défini par le service. Certains webhooks comportent des méthodes intégrées d'exécution de nouvelles tentatives en cas de réponse d'erreur, comme un code d'état HTTP 4xx ou 5xx. Vous devez donc renvoyer un code d'état indiquant le succès de l'opération (2xx) pour informer le service que l'événement a été correctement traité.
def index():
data = request.get_json()
return ('', 200)
Délais avant expiration
Le service Knative serving et le fournisseur de webhooks ont tous deux des délais avant expiration. Le plus court des deux s'appliquera à votre application. Si le traitement de vos données dépasse le temps imparti par Knative serving ou le fournisseur de webhooks, vous devez utiliser un produit qui vous permet de terminer le traitement de manière asynchrone, tel que Pub/Sub ou Cloud Tasks. Ces produits vous permettent de transférer rapidement les données, de renvoyer immédiatement une réponse positive au fournisseur de webhooks et de poursuivre le traitement sans vous préoccuper du délai avant expiration. Ce sont également de bonnes options pour gérer les échecs et les nouvelles tentatives.
Modèles de webhooks courants
Type | Exemples |
---|---|
Relayer des données | Envoi d'une notification via Firebase Cloud Messaging chaque fois que le webhook est appelé |
Stocker des données | Stockage des données dans BigQuery pour analyse ultérieure |
Déclencher des actions | Exécution d'actions sur Dialogflow, publication de réponses sur Twitter ou transfert vers votre environnement de préproduction chaque fois qu'un nouveau code fait l'objet d'un commit dans GitHub. |
Étape suivante
- Apprenez-en plus concernant les webhooks (déclencheurs HTTP) sur les fonctions Cloud Run.
- Configurez des notifications de webhooks sur Google Cloud Observability.
- Envoyez des messages Pub/Sub à un webhook à l'aide d'abonnements push.
- Effectuez des actions sur Dialogflow avec des webhooks.