Eventarc vous permet de créer des architectures basées sur des événements, sans avoir à mettre en œuvre, à personnaliser ou à gérer l'infrastructure sous-jacente. Eventarc offre une solution standardisée pour gérer le flux des changements d'état, appelés événements, entre les microservices découplés. Lorsqu'il est déclenché, Eventarc achemine ces événements via des abonnements Pub/Sub vers différentes destinations (dans ce document, consultez la section Destinations d'événements) tout en gérant la diffusion, la sécurité, les autorisations, l'observabilité, et la gestion des erreurs à votre place.
Vous pouvez gérer Eventarc à l'aide de Google Cloud Console, de la ligne de commande avec gcloud CLI ou de l'API Eventarc.
Eventarc est conforme à ces certifications et normes.
1 Les événements des fournisseurs Google Cloud sont envoyés directement depuis la source (Cloud Storage, par exemple) ou via des entrées de Cloud Audit Logs, et utilisent Pub/Sub comme couche de transport. Les événements de sources Pub/Sub peuvent utiliser un sujet Pub/Sub existant ou Eventarc crée automatiquement un sujet et le gère pour vous.
2 Les événements pour les destinations GKE utilisent le redirecteur d'événements d'Eventarc pour extraire les nouveaux événements de Pub/Sub et les transférer vers la destination. Ce composant agit en tant que médiateur entre la couche de transport Pub/Sub et le service cible. Il fonctionne avec les services existants et prend en charge les services de signalement (y compris ceux qui ne sont pas exposés en dehors du cluster entièrement géré) tout en simplifiant la configuration et la maintenance. Notez que le cycle de vie du redirecteur d'événements est géré par Eventarc. Si vous supprimez accidentellement le redirecteur d'événement, Eventarc restaurera ce composant.
3 Les événements d'exécution d'un workflow sont transformés et transmis au workflow en tant qu'arguments d'exécution. Les workflows peuvent combiner et orchestrer des services d'API basés sur Google Cloud et HTTP dans un ordre que vous définissez.
Principaux cas d'utilisation
Eventarc est compatible avec de nombreux cas d'utilisation des applications de destination. En voici quelques exemples :
| Configurer et surveiller |
|
| Harmoniser |
|
| Analyse |
|
Events
Un événement est un enregistrement de données exprimant une occurrence et son contexte. Un événement correspond à une unité discrète de communication, indépendante des autres événements. Par exemple, il peut s'agir d'une modification apportée aux données d'une base de données, de l'ajout d'un fichier à un système de stockage ou d'une tâche planifiée.
Consultez la section Types d'événements acceptés par Eventarc.
Fournisseurs d'événements
Les événements sont acheminés d'un fournisseur d'événements (la source) aux consommateurs intéressés. Le routage est effectué en fonction des informations contenues dans l'événement, mais un événement n'identifie pas de destination de routage spécifique. Actuellement, Eventarc accepte les événements provenant des fournisseurs suivants :
- Plus de 90 fournisseurs Google Cloud Ces fournisseurs envoient des événements directement depuis la source (Cloud Storage, par exemple) ou via des entrées de journaux d'audit Cloud.
- Fournisseurs Pub/Sub. Ces fournisseurs envoient des événements à Eventarc à l'aide de messages Pub/Sub.
Destinations des événements
Les événements sont acheminés vers une destination spécifique (la cible) appelée récepteur d'événements (ou consommateur) via des abonnements push Pub/Sub.
Cloud Run
Apprenez à créer un service récepteur d'événements pouvant être déployé sur Cloud Run.
Pour déterminer la meilleure façon d'acheminer les événements vers un service Cloud Run, consultez la page Options de routage des événements.
GKE
Eventarc accepte la création de déclencheurs qui ciblent les services Google Kubernetes Engine (GKE). Cela inclut les services Cloud Run pour Anthos privés et publics s'exécutant dans un cluster GKE.
Pour qu'Eventarc cible et gère les services d'un cluster donné, vous devez accorder au compte de service Eventarc toutes les autorisations nécessaires.
Vous devez activer Workload Identity sur le cluster GKE sur lequel le service de destination s'exécute. Workload Identity est requis pour configurer correctement le redirecteur d'événements. Il s'agit de la méthode recommandée pour accéder aux services Google Cloud à partir d'applications exécutées dans GKE en raison de ses propriétés de sécurité renforcée et de sa facilité de gestion. Pour en savoir plus, consultez la page Utiliser Workload Identity.
Workflows
Une exécution de votre workflow est déclenchée par des messages publiés dans un sujet Pub/Sub, lorsqu'un journal d'audit est créé qui correspond aux critères de filtre du déclencheur, ou en réponse à divers événements à l'intérieur d'un bucket Cloud Storage : création, suppression et archivage d'objets, ainsi que mises à jour de métadonnées.
Workflows nécessite l'adresse e-mail d'un compte de service IAM que votre déclencheur Eventarc utilisera pour appeler les exécutions de workflow. Nous vous recommandons d'utiliser un compte de service ne bénéficiant que des privilèges les plus faibles nécessaires pour accéder aux ressources requises. Pour en savoir plus sur les comptes de service, consultez la page Créer et gérer des comptes de service.
Format des événements et bibliothèques
Eventarc envoie les événements, quelle que soit leur fournisseur, à la destination cible dans un format CloudEvents via une requête HTTP portant sur du contenu binaire. CloudEvents est une spécification décrivant les métadonnées d'événements de manière courante, encouragée par la Cloud Native Computing Foundation et organisée par son groupe de travail axé sur le sans serveur.
Les destinations cibles Cloud Run et GKE consomment des événements au format HTTP. Toutefois, pour les destinations Workflows, le service Workflows convertit l'événement en objet JSON (conformément à la spécification JSON CloudEvents) et transmet l'événement à l'exécution du workflow comme argument d'exécution.
L'utilisation d'une méthode standard pour décrire les métadonnées d'événements garantit la cohérence, l'accessibilité et la portabilité. Les consommateurs d'événements peuvent lire ces événements directement. Vous pouvez également utiliser les SDK et les bibliothèques Google CloudEvents dans différents langages (y compris C#, Go, Java, Node.js et Python) pour lire et analyser les événements :
La structure du corps HTTP de tous les événements est disponible dans le dépôt GitHub Google CloudEvents.
Rétrocompatibilité
Eventarc prend en compte l'ajout des attributs et champs suivants compatibles avec les versions antérieures :
- Attributs de filtrage facultatifs ou attributs de sortie uniquement
- Champs facultatifs dans la charge utile de l'événement
Déclencheurs Eventarc
Des événements se produisent, qu'une destination cible réagisse ou non. Vous pouvez créer une réponse à un événement avec un déclencheur. Un déclencheur vous permet d'indiquer que vous souhaitez surveiller un ou plusieurs événements. Lorsque vous créez un déclencheur, vous spécifiez des filtres qui vous permettent de capturer ces événements spécifiques et de les utiliser, ce qui inclut leur routage d'une source d'événement vers une destination cible. Pour en savoir plus, consultez la représentation REST d'une ressource de déclencheur et découvrez comment créer un déclencheur.
Notez que les abonnements Pub/Sub créés pour Eventarc persistent indifféremment de l'activité et n'expirent pas. Pour modifier les propriétés de l'abonnement, consultez la page Gérer les abonnements.
Eventarc est compatible avec les déclencheurs pour les types d'événements suivants :
| Événements Cloud Audit Logging (CAL) | |
|---|---|
| Description | Cloud Audit Logging fournit des journaux d'audit Cloud pour les activités d'administration et l'accès aux données pour chaque projet, dossier et organisation Cloud.
Les services Google Cloud écrivent des entrées dans ces journaux. Cette liste d'événements compatibles inclut un répertoire de valeurs serviceName et methodName. |
| Type de filtre d'événement | Les déclencheurs Eventarc avec type=google.cloud.audit.log.v1.written envoient des requêtes à votre service ou workflow lorsque vous créez un journal d'audit correspondant aux critères de filtrage du déclencheur. |
| Événements Cloud Pub/Sub | |
| Description | Eventarc peut être déclenché par les messages publiés dans les sujets Pub/Sub. Pub/Sub est un service de messagerie distribué dans le monde entier qui effectue un scaling automatique en fonction des besoins. Eventarc pouvant être appelé par des messages sur un sujet Pub/Sub, vous pouvez facilement l'intégrer à tout autre service acceptant Pub/Sub comme destination. |
| Type de filtre d'événement | Les déclencheurs Eventarc avec type=google.cloud.pubsub.topic.v1.messagePublished envoient des requêtes à votre service ou à votre workflow lorsqu'un message est publié dans le sujet Pub/Sub spécifié. |
| Événements directs | |
| Description | Eventarc peut être déclenché par divers événements directs, tels qu'une mise à jour d'un bucket Cloud Storage ou une mise à jour d'un modèle Firebase Remote Config. |
| Type de filtre d'événement | Les déclencheurs Eventarc avec des types de filtres d'événements spécifiques envoient des requêtes à votre service ou workflow lorsqu'un événement correspondant aux critères de filtre du déclencheur se produit. Exemple : type=google.cloud.storage.object.v1.finalized.
|
Emplacement du déclencheur
Les services Google Cloud, tels que Cloud Storage, peuvent être configurés pour être régionaux ou multirégionaux. Certains services, tels que Cloud Build, peuvent être configurés à l'échelle mondiale.
Eventarc vous permet de créer des déclencheurs régionaux ou, pour certains événements, vous pouvez créer un déclencheur global et recevoir des événements de toutes les régions. Pour en savoir plus, consultez la section Comprendre les emplacements Eventarc.
Vous devez spécifier l'emplacement du déclencheur Eventarc pour qu'il corresponde à celui du service Google Cloud qui génère des événements. Cela évite les problèmes de performances et de résidence des données occasionnés par un déclencheur global.
Vous pouvez spécifier des emplacements de déclencheur en ajoutant une option --location à chaque commande.
Si l'option --destination-run-region n'est pas spécifiée, le service est supposé se trouver dans la même région que le déclencheur. Pour en savoir plus, consultez la documentation de référence de Google Cloud CLI.
Fiabilité et diffusion
Les attentes en termes de diffusion sont les suivantes :
- Les événements utilisant les journaux d'audit Cloud sont diffusés en moins d'une minute.
- Les événements utilisant Pub/Sub sont diffusés en quelques secondes.
Il n'existe pas de fonctionnalité de diffusion prioritaire "premier entré, premier sorti". Notez qu'un ordonnancement strict irait à l'encontre des garanties de disponibilité et d'évolutivité offertes par Eventarc, qui correspondent à celles de sa couche de transport, Cloud Pub/Sub. Pour en savoir plus, consultez la page Trier des messages.
La latence et le débit sont les meilleurs possible. Ils varient en fonction de plusieurs facteurs, y compris si le déclencheur Eventarc est régional, multirégional ou mondial, la configuration d'un service particulier et la charge réseau sur les ressources dans une région Google Cloud.
Notez que des quotas et limites d'utilisation s'appliquent généralement à Eventarc. De plus, certains quotas et limites d'utilisation spécifiques s'appliquent également aux workflows.
Stratégie de nouvelle tentative pour les événements
Les nouvelles caractéristiques d'Eventarc correspondent à celles de sa couche de transport, Cloud Pub/Sub. Pour en savoir plus, consultez la section Réessayer d'exécuter des requêtes. Le paramètre de nouvelle tentative par défaut est de 24 heures avec un intervalle exponentiel entre les tentatives. Vous pouvez mettre à jour la stratégie de nouvelle tentative via l'abonnement Pub/Sub associé au déclencheur Eventarc : Ouvrir la page de détails du déclencheur, cliquez sur le sujet, puis sur Onglet Abonnements. Tout abonnement créé automatiquement par Eventarc aura le format suivant : projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID.
Si Pub/Sub tente d'envoyer un message, mais que la destination ne peut pas en accuser réception, Pub/Sub retente immédiatement l'envoi du message. Si les conditions de la destination qui empêchaient l'envoi d'un accusé de réception n'ont pas changé, le message sera renvoyé en continu sans être reçu au niveau de la destination. Pour résoudre ce problème, vous pouvez configurer une stratégie de nouvelle tentative de l'abonnement Pub/Sub ou transférer les messages non distribués vers un sujet de lettres mortes (également appelé file d'attente de lettres mortes). Pour en savoir plus, consultez la page Gérer les échecs de message. Par exemple, si le service de destination n'accuse pas réception des messages, Pub/Sub conserve les événements pendant sept jours par défaut et tente à nouveau d'envoyer des événements à la destination. Pour en savoir plus, consultez la section Limites de ressources dans Pub/Sub.
Lorsque les applications utilisent Pub/Sub comme source d'événements et que l'événement n'est pas diffusé, l'événement est automatiquement relancé, sauf pour les erreurs qui ne justifient pas de nouvelles tentatives. Notez que Workflows accuse réception des événements dès le début de l'exécution du workflow. Les événements de la destination du workflow, quelle que soit leur source, ne seront pas relancés si le workflow ne s'exécute pas. Si l'exécution du workflow démarre, mais échoue ultérieurement, elle n'est pas relancée. Pour résoudre ces problèmes de service, vous devez gérer les erreurs et les nouvelles tentatives dans le workflow.
Observabilité
Des journaux détaillés pour Eventarc, Cloud Run, Cloud Run for Anthos, Pub/Sub et Workflows sont disponibles via Cloud Audit Logs.
Étape suivante
- Commencez à utiliser Eventarc via les guides de démarrage rapide ou l'atelier de programmation.
- Créez un déclencheur Cloud Run, un déclencheur GKE ou un déclencheur Workflows.
- Résoudre les problèmes