Eventarc consente di creare architetture basate sugli eventi senza dover implementare, personalizzare o mantenere l'infrastruttura sottostante. Eventarc offre una soluzione standardizzata per gestire il flusso di modifiche dello stato, chiamato eventi, tra microservizi disaccoppiati. Quando viene attivato, Eventarc indirizza questi eventi a varie destinazioni (in questo documento, vedi Destinazioni evento) mentre gestisce per te la distribuzione, la sicurezza, l'autorizzazione, l'osservabilità e la gestione degli errori.
Puoi gestire Eventarc dalla console Google Cloud, dalla riga di comando utilizzando gcloud CLI oppure utilizzando l'API Eventarc.
Eventarc è conforme a questi standard e certificazioni.
1 Gli eventi provenienti dai provider Google vengono inviati direttamente dall'origine (Cloud Storage, ad esempio) o tramite voci di Cloud Audit Logs e utilizzano Pub/Sub come livello di trasporto. Gli eventi provenienti dalle origini Pub/Sub possono utilizzare un argomento Pub/Sub esistente o Eventarc creano automaticamente un argomento e lo gestiranno per te.
2 Gli eventi per le destinazioni Google Kubernetes Engine (GKE), inclusi i servizi Cloud Run for Anthos (CRfA) in esecuzione in un cluster GKE, utilizzano l'inoltro di eventi di Eventarc per eseguire il pull di nuovi eventi da Pub/Sub e inoltrarli alla destinazione. Questo componente funge da mediatore tra il livello di trasporto Pub/Sub e il servizio di destinazione. Funziona sui servizi esistenti e supporta anche i servizi di segnalazione (inclusi quelli non esposti all'esterno del cluster completamente gestito) semplificando la configurazione e la manutenzione. Tieni presente che il ciclo di vita dell'inoltro degli eventi è gestito da Eventarc e, se lo elimini accidentalmente, Eventarc ripristinerà questo componente.
3 Gli eventi per un'esecuzione del flusso di lavoro vengono trasformati e trasmessi al flusso di lavoro come argomenti di runtime. I flussi di lavoro possono combinare e orchestrare Google Cloud e i servizi API basati su HTTP in un ordine da te definito.
Principali casi d'uso
Eventarc supporta molti casi d'uso per le applicazioni di destinazione. Ecco alcuni esempi:
| Configura e monitora |
|
| Armonizza |
|
| Analisi |
|
Eventi
Un evento è un record di dati che esprime un'occorrenza e il relativo contesto. Un evento è un'unità di comunicazione separata, indipendente dagli altri eventi. Ad esempio, un evento potrebbe essere una modifica ai dati in un database, un file aggiunto a un sistema di archiviazione o un job pianificato.
Vedi Tipi di eventi supportati da Eventarc.
Provider di eventi
Gli eventi vengono indirizzati da un provider di eventi (la fonte) ai consumer di eventi interessati. Il routing viene eseguito in base alle informazioni contenute nell'evento, ma un evento non identifica una destinazione di routing specifica. Attualmente, Eventarc supporta gli eventi dei seguenti provider:
- Più di 130 provider Google Cloud. Questi provider inviano eventi (ad esempio un aggiornamento a un oggetto in un bucket Cloud Storage o un messaggio pubblicato in un argomento Pub/Sub) direttamente dall'origine o attraverso le voci di Cloud Audit Logs.
- Fornitori di terze parti. Questi provider inviano eventi direttamente dalla sorgente, ad esempio provider SaaS di terze parti come Datadog o la piattaforma CheckPoint CloudGuard.
Destinazioni evento
Gli eventi vengono indirizzati a una destinazione specifica (la destinazione) nota come destinatario dell'evento (o consumer) tramite abbonamenti push Pub/Sub.
Cloud Functions (2nd gen)
Tutte le funzioni basate su eventi di Cloud Functions (2nd gen) utilizzano i trigger Eventarc per la distribuzione degli eventi. Un trigger Eventarc consente l'attivazione di una funzione da qualsiasi tipo di evento supportato da Eventarc. Puoi configurare i trigger Eventarc quando esegui il deployment di una funzione Cloud Functions utilizzando l'interfaccia di Cloud Functions.
Cloud Run
Scopri come creare un servizio di ricezione di eventi di cui puoi eseguire il deployment in Cloud Run.
Per determinare il modo migliore per eseguire il routing degli eventi a un servizio Cloud Run, consulta Opzioni di routing degli eventi.
GKE
Eventarc supporta la creazione di trigger che abbiano come target i servizi Google Kubernetes Engine (GKE). inclusi gli endpoint pubblici dei servizi privati e pubblici in esecuzione in un cluster GKE.
Affinché Eventarc possa scegliere come target e gestire i servizi in un dato cluster, devi concedere all'account di servizio Eventarc le autorizzazioni necessarie.
Devi abilitare Workload Identity nel cluster GKE su cui è in esecuzione il servizio di destinazione. Workload Identity è necessario per configurare correttamente l'inoltro dell'evento ed è il metodo consigliato per accedere ai servizi Google Cloud dalle applicazioni in esecuzione all'interno di GKE grazie alle sue proprietà di sicurezza e alla gestibilità migliorate. Per saperne di più, consulta Utilizzo di Workload Identity.
Workflows
L'esecuzione del tuo flusso di lavoro viene attivata dai messaggi pubblicati in un argomento Pub/Sub, quando viene creato un audit log che corrisponde ai criteri di filtro dell'attivatore o in risposta a vari eventi di un bucket Cloud Storage: creazione di oggetti, eliminazione, archiviazione e aggiornamenti di metadati.
Workflows richiede un'email dell'account di servizio IAM che il trigger Eventarc utilizzerà per richiamare le esecuzioni del flusso di lavoro. Ti consigliamo di utilizzare un account di servizio con i privilegi minimi necessari per accedere alle risorse richieste. Per scoprire di più sugli account di servizio, consulta la sezione Creare e gestire gli account di servizio.
Formato e librerie degli eventi
Eventarc invia gli eventi, indipendentemente dal provider, alla destinazione target in un formato CloudEvents utilizzando una richiesta HTTP in modalità contenuti binari. CloudEvents è una specifica per la descrizione dei metadati degli eventi in modo comune, ospitata da Cloud Native Computing Foundation e organizzata dal gruppo di lavoro serverless della fondazione.
Le destinazioni target, come Cloud Functions, Cloud Run e GKE, utilizzano eventi nel formato HTTP. Per le destinazioni Workflows, il servizio Workflows converte l'evento in un oggetto JSON e lo trasferisce nell'esecuzione del flusso di lavoro come argomento di runtime.
L'utilizzo di un modo standard per descrivere i metadati degli eventi garantisce coerenza, accessibilità e portabilità. I consumer di eventi possono leggere direttamente questi eventi oppure utilizzare SDK e librerie Google CloudEvents in vari linguaggi (inclusi C#, Go, Java, Node.js e Python) per leggere e analizzare gli eventi:
La struttura del corpo HTTP per tutti gli eventi è disponibile nel repository GitHub Google CloudEvents.
Compatibilità con le versioni precedenti
Eventarc considera l'aggiunta dei seguenti attributi e campi compatibili con le versioni precedenti:
- Attributi di filtro facoltativi o attributi di solo output
- Campi facoltativi per il payload dell'evento
Trigger Eventarc
Gli eventi si verificano indipendentemente dal fatto che una destinazione reagisca a essi. Puoi creare una risposta a un evento utilizzando un trigger. Con il trigger dichiari di essere interessato a un determinato evento o a una serie di eventi. Quando crei un trigger, specifichi i filtri corrispondenti che ti consentono di acquisire e intervenire su determinati eventi, incluso il routing da un'origine evento a una destinazione. Per ulteriori informazioni, consulta la rappresentazione REST di una risorsa trigger e le destinazioni e i provider di eventi.
Tieni presente che le sottoscrizioni Pub/Sub create per Eventarc rimangono valide indipendentemente dall'attività e non scadono. Per modificare le proprietà dell'abbonamento, consulta la sezione Proprietà dell'abbonamento.
Eventarc supporta i trigger per questi tipi di eventi:
| Eventi dell'Cloud Audit Logs (CAL) | |
|---|---|
| Descrizione | Cloud Audit Logs forniscono attività di amministrazione e audit log di accesso ai dati per ogni progetto, cartella e organizzazione Cloud.
I servizi Google Cloud scrivono le voci di questi log. Questo elenco di eventi supportati include una directory di valori serviceName e methodName. |
| Tipo di filtro eventi | I trigger Eventarc con type=google.cloud.audit.log.v1.written inviano richieste al tuo servizio o flusso di lavoro quando viene creato un audit log che corrisponde ai criteri di filtro del trigger. |
| Eventi diretti | |
| Descrizione | Eventarc può essere attivato da
vari eventi diretti come un aggiornamento di un bucket Cloud Storage,
un aggiornamento di un modello Firebase Remote Config o modifiche alle
risorse
dei servizi Google Cloud.
Eventarc può anche essere attivato dai messaggi pubblicati negli argomenti Pub/Sub. Pub/Sub è un bus di messaggi distribuito a livello globale che offre la scalabilità automatica in base alle tue esigenze. Poiché Eventarc può essere richiamato dai messaggi su un argomento Pub/Sub, puoi integrare facilmente Eventarc con qualsiasi altro servizio che supporti Pub/Sub come destinazione. |
| Tipo di filtro eventi | Gli attivatori Eventarc con
tipi specifici di filtri di eventi inviano richieste al tuo servizio o flusso di lavoro quando
si verifica un evento che corrisponde ai criteri di filtro dell'attivatore; ad esempio,
type=google.cloud.storage.object.v1.finalized (quando viene creato un oggetto
in un bucket Cloud Storage) o
type=google.cloud.pubsub.topic.v1.messagePublished (quando
viene pubblicato un messaggio nell'argomento Pub/Sub specificato).
|
Località trigger
I servizi Google Cloud come Cloud Storage possono essere configurati per essere a livello di una o più aree geografiche. Alcuni servizi, come Cloud Build, possono essere configurati a livello globale.
Eventarc consente di creare trigger a livello di regione oppure, per alcuni eventi, puoi creare un trigger globale e ricevere eventi da tutte le regioni. Per ulteriori informazioni, consulta la pagina Informazioni sulle località di Eventarc.
Devi specificare la località del trigger Eventarc in modo che corrisponda alla località del servizio Google Cloud che genera gli eventi ed evitare problemi di prestazioni e localizzazione dei dati causati da un trigger globale.
Puoi specificare le località di attivazione utilizzando un flag --location con ogni comando.
Se non viene specificato un flag --destination-run-region, si presume che il servizio si trovi nella stessa regione del trigger. Per ulteriori informazioni, consulta il riferimento per l'interfaccia a riga di comando di Google Cloud.
Affidabilità e consegna
Le aspettative di consegna sono le seguenti:
- Gli eventi che utilizzano Cloud Audit Logs vengono consegnati in meno di un minuto. Tieni presente che, anche se un trigger di Cloud Audit Logs viene creato immediatamente, la propagazione e il filtro degli eventi possono richiedere fino a due minuti.
- Gli eventi che utilizzano Pub/Sub vengono distribuiti in pochi secondi.
Non è prevista una garanzia di consegna in ordine. Tieni presente che l'ordinamento rigoroso minerebbe la disponibilità e le funzionalità di scalabilità di Eventarc che corrispondono a quelle del suo livello di trasporto, Cloud Pub/Sub. Per ulteriori informazioni, vedi Ordinare i messaggi.
Latenza e velocità effettiva sono i migliori. variano in base a più fattori, tra cui se il trigger Eventarc è a livello di una regione, più regioni o globale, la configurazione di un particolare servizio e il carico di rete sulle risorse in una regione Google Cloud.
Tieni presente che esistono quote e limiti di utilizzo che si applicano in generale a Eventarc. Esistono anche quote e limiti di utilizzo specifici per Workflows.
Criterio per nuovi tentativi di eventi
Le caratteristiche nuovi tentativi di Eventarc corrispondono a quelle del relativo livello di trasporto, Cloud Pub/Sub. Per maggiori informazioni, consulta Richieste di nuovo tentativo e Backoff push.
La durata predefinita di conservazione dei messaggi impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.
Puoi aggiornare il criterio relativo ai nuovi tentativi tramite la sottoscrizione Pub/Sub associata al trigger Eventarc: Apri la pagina Dettagli trigger, fai clic sull'argomento, quindi sulla scheda Abbonamenti. Qualsiasi abbonamento creato automaticamente da Eventarc avrà questo formato: projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Per ulteriori informazioni sui limiti di abbonamento, consulta i limiti delle risorse Pub/Sub.
Se Pub/Sub tenta di consegnare un messaggio ma la destinazione non riesce a riconoscerlo, Pub/Sub invierà di nuovo il messaggio con un backoff esponenziale minimo di 10 secondi. Se la destinazione continua a non riconoscere il messaggio, viene aggiunto più tempo al ritardo in ogni nuovo tentativo (fino a un massimo di 600 secondi) e il messaggio viene inviato nuovamente alla destinazione. Se la destinazione non riceve il messaggio, puoi inoltrare i messaggi non recapitati a un argomento messaggi non recapitabili (noto anche come coda non recapitabile). Per saperne di più, vedi Gestire gli errori relativi ai messaggi.
Quando le applicazioni utilizzano Pub/Sub come origine evento e l'evento non viene pubblicato, l'evento viene ripetuto automaticamente, ad eccezione degli errori che non garantiscono nuovi tentativi. Tieni presente che Workflows riconosce gli eventi all'inizio dell'esecuzione del flusso di lavoro. Se il flusso di lavoro non viene eseguito, gli eventi nella destinazione del flusso di lavoro da qualsiasi origine non verranno ripetuti. Se l'esecuzione del flusso di lavoro inizia ma in seguito non riesce, le esecuzioni non vengono ripetute. Per risolvere questi problemi di servizio, devi gestire gli errori e i nuovi tentativi all'interno del flusso di lavoro.
Duplicare gli eventi
Gli eventi duplicati potrebbero essere inviati ai gestori di eventi. Secondo la specifica di CloudEvents, la combinazione degli attributi source e id è considerata unica e pertanto tutti gli eventi con la stessa combinazione sono considerati duplicati.
Come best practice generale, devi implementare i gestori di eventi idempotenti.
Osservabilità
I log dettagliati di Eventarc, Cloud Run, GKE, Pub/Sub e Workflows sono disponibili in Cloud Audit Logs.
Passaggi successivi
- Inizia a utilizzare Eventarc tramite le guide rapide o il codelab.
- Creare un trigger per un provider, un tipo di evento e una destinazione specifici
- Risolvere i problemi